Ideas for making permission sets portable: env vars in paths, merging CLI flags, path patterns

[johngeorgewright]

I've been converting my tasks over to the experimental permissions config in deno.json (#25651) and really like the direction — a declarative sandbox per task is exactly what I wanted. In practice though, I keep hitting a wall with paths that vary per machine, and I'd love to hear how others are handling this and whether any of the ideas below fit the feature's direction. Observations from Deno 2.9.1.

The core problem: permission set paths are literal, so machine-dependent paths can't be expressed. $HOME, ${HOME}, and ~ don't expand, so grants like ~/.npmrc (npm auth) or the default DENO_DIR cache location can't be written portably in the set.

The natural workaround is to append them via the task string, where the task shell does expand env vars:

"tasks": {
  "build:npm": "deno run --permission-set=build:npm --allow-read=$HOME/.npmrc scripts/build_npm.ts"
}

…but a CLI --allow-read replaces the set's read.allow list rather than merging with it, so every read grant has to migrate out of the set and onto the flag — which mostly defeats the declarative config. (Interestingly, the set's read.ignore list does survive the CLI flag, so there's already a mix of replace and merge semantics.)

A related ergonomic issue: with no glob or name-based patterns, silencing Node-style resolution walk-ups means enumerating every ancestor by hand. From my real config:

"read": {
  "ignore": [
    "../node_modules",
    "../../node_modules",
    "../../../node_modules",
    "../../../../node_modules",
    "../../../../../node_modules",
    "../../../../../../node_modules",
    "../mod.ts",
    "../../mod.ts",
    // … × mod.js / mod.jsx / mod.tsx, six levels each — 30+ lines to say "ignore ancestor probes"
  ]
}

Ideas (any one of which would cover my use case):

1. Env-var interpolation in set paths — e.g. "read": ["$HOME/.npmrc"], resolved when the set is loaded.
2. Merge semantics between CLI flags and the selected set — additive by default, or an explicit opt-in flag, so the set stays the source of truth and the command line only extends it.
3. Minimal pattern support in path lists — e.g. **/node_modules, or a dedicated "in any ancestor directory" form aimed at the walk-up case.

Is any of this on the roadmap for the experimental feature, and is there interest in a PR for any of these directions? Curious how others are structuring their sets around per-machine paths in the meantime.

[bartlomieju]

Thanks for the detailed writeup! Good news: all three of these ideas are already tracked as feature requests, so I'll close this discussion and invite you to continue the conversation on the issues directly — the concrete use cases here (npm auth via ~/.npmrc, the ancestor node_modules walk-up enumeration) are great motivation to bring over there.

1. Env-var interpolation in set paths → Env var interpolation in permission sets #30694 (config-side, including the deno compile runtime-expansion question). Related: Support environment variable interpolation in permission flags #29809 for interpolation in CLI permission flags, and Add more special permission cli variables #16766 which proposes portable special variables like <cache_dir> — an alternative that would cover the $HOME/DENO_DIR case without raw env expansion.

2. Merge semantics between CLI flags and the selected set → Named permissions don't stack: specifying an additional permission value overwrites all values specified in the named permission set #32795, which reports exactly this: CLI permission flags overwrite the named set's list instead of stacking with it.

3. Glob/pattern support in path lists → Allow wildcards in permissions model #30740. The "ignore Node-resolution walk-up probes in any ancestor" case would be a valuable comment there.

Feel free to 👍 and add your use cases on those issues — it helps with prioritization.