No way to remove inherited deny entries when extending a template

[yimsk]

When a config extends a template (e.g. code), all deny* entries are merged additively. There is no way to remove a deny entry inherited from the parent.

Example: The code template includes "~/.docker/**" in denyRead to protect registry credentials. If a user needs Docker config access (e.g. for proxy settings or credential helper references), there's no way to remove that entry while still inheriting the rest of the template.

The only workaround today is to stop using extends and duplicate the entire template with the entry removed.

Proposal: Support a negation prefix (e.g. !) in deny fields to remove inherited entries:

{
  "extends": "code",
  "filesystem": {
    "denyRead": ["!~/.docker/**"]
  }
}

This would apply consistently to all deny fields: denyRead, denyWrite, command.deny, and deniedDomains.

[dwt]

I was thinking about a different format for the config file to make this easier and haven't come up with something yet. I like this idea for that reason. Keeps the existing config format but gives the ability to undo specific configs that you do not want to inherit.

Still needs some more thinking I guess, but this is a good start.

[yimsk]

Thanks! Yeah, the ! prefix felt like the lowest-friction approach since it works within the existing format. Happy to help flesh out edge cases if needed.

[jy-tan]

Thanks for the writeup, agree with the gap here.

I'd push back on !-prefix as the mechanism though: it overloads existing glob/gitignore semantics, and because it's string-matched against the parent, if code later refactors ~/.docker/** into multiple entries your "!~/.docker/**" silently becomes a no-op and you quietly lose access. It also collapses two different intents into one shape: "don't inherit this rule at all" vs "keep the rule but allow this one path through."

Thinking about two separate primitives to cover both cleanly:

1. A remove block - "drop this inherited rule entirely":

{
  "extends": "code",
  "command":    { "remove": { "deny": ["sudo"] } },
  "network":    { "remove": { "deniedDomains": ["*.sentry.io"] } },
  "filesystem": { "remove": { "denyRead": ["~/.docker/**"] } }
}

With a warning if a remove entry doesn't match anything in the resolved parent, so template drift surfaces instead of silently widening access.

2. An explicit allowReadException field - "keep the deny, but allow this one path":

{
  "extends": "code",
  "filesystem": {
    "allowReadException": ["~/.docker/config.json"]
  }
}

This covers the case remove can't: the whole ~/.docker/** subtree stays denied, one file carved out. We explicitly keep it a separate field from ordinary allowRead so the intention is clear here.

Let me know what you think @yimsk @dwt

[yimsk]

@jy-tan Agree on both points. The silent no-op issue with !, and splitting remove vs exception.

One thought on shape. Piling remove, allowReadException, allowWriteException, commandDenyException... as siblings is going to get messy as deny fields grow. What if we nested them under an override key per section?

{
  "extends": "code",
  "filesystem": {
    "denyRead": ["./secrets/**"],
    "override": {
      "remove": { "denyRead": ["~/.docker/**"] },
      "except": { "denyRead": ["~/.aws/config"] }
    }
  }
}

remove drops the whole ~/.docker/** rule so Docker config is fully accessible. except keeps ~/.aws/** denied but carves out read access to ~/.aws/config for region/profile lookup.

Existing fields stay additive so no breakage, except becomes one word instead of N, and you never see override at all unless you're using extends.

The warning on unmatched remove is essential either way.

[jy-tan]

@yimsk I like this shape - override as a named block reads better than scattered sibling fields, and except.denyRead mirroring the field it carves out of is cleaner than allowReadException.

Two small things I'd also call out upfront:

1. Restrict except to fields without an existing carve-out. command.deny is already paired with command.allow, and deniedDomains with allowedDomains. If override.except covered those too you'd have two ways to express the same thing. Keeping it to denyRead / denyWrite (the fields that actually lack a companion today) avoids that drift.

2. Let except work in flat configs too, not only under extends. It's a general "carve a hole in a deny rule", useful when you wrote denyRead: ["~/.aws/**"] five lines up and want to except ~/.aws/config in the same file.

If this makes sense, I'll go ahead and implement this!

[yimsk]

@jy-tan Two things I noticed while looking at the implementation:

1. The allow/deny precedence differs by field:

   • command → allow wins (checkSingleCommand)
   • deniedDomains / denyRead / denyWrite → deny wins

   So "an allow/deny pair already exists → except unnecessary" only holds for command. allowedDomains does not carve a hole in deniedDomains. The case where a template denies *.sentry.io and I want to let just a.sentry.io through is the same shape as denyRead, so except probably needs to cover denyRead / denyWrite / deniedDomains.

2. I'm the one who proposed both remove and except, but thinking about it again: if except is defined as "carve a hole inside the parent's deny range", then writing the same value as the parent makes it equivalent to remove:

   Parent	except	Effect
   *.sentry.io	a.sentry.io	only a allowed
   *.sentry.io	*.sentry.io	all allowed (= remove)