write tool permission */tmp/*: allow still prompts despite matching pattern #30551

Activity

1. github-actions

   assigned

   rekram1-node

   on Jun 3, 2026
2. github-actions commented on Jun 3, 2026

   

   github-actionsBot

   on Jun 3, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • edit permission uses relative paths but external_directory uses absolute paths, breaking agent-level path rules #20045: Same root cause — edit/write permission checks pass relative paths to the matcher while patterns are written as absolute-style, causing */tmp/* patterns to fail to match. Your issue appears to be the same bug applied to the write tool specifically.
   • Permission glob matcher doesn't match deep absolute paths; only **/<basename>/** works #25097: Permission glob matcher doesn't match deep absolute paths; overlapping symptom where glob patterns like */tmp/* or **/private/tmp/** fail to match resolved absolute paths.

   If your issue is specifically about the write tool being affected (while #20045 focuses on edit), it may be worth keeping open to track that gap — but please confirm whether #20045 or #25097 already covers your case before proceeding.
3. iceteaSA commented on Aug 2, 2026

   

   iceteaSA

   on Aug 2, 2026

   More actions

   Your diagnosis in the issue body is correct, and I've opened a PR against it: #40149.

   Adding the evidence I gathered, because this has been filed four other times (#20045, #22336, #22465, #25097) and closed unfixed each time. Every one of those reported it as ergonomics — an allow rule that doesn't fire, so you get prompted. There's a second direction nobody filed.

   A deny rule doesn't fire either. Real Permission.evaluate on current dev:

   config { edit: { "*": "allow", "/etc/**": "deny" } }
   
   target                                 : /etc/passwd
   pattern the tool sends (path.relative) : ../../../../etc/passwd
   VERDICT                                : allow      ← matched rule "*"
   
   same target sent as "/etc/passwd":
   VERDICT                                : deny
   

   The deny is loaded, expanded, and sitting in the ruleset. It loses to the catch-all because it never becomes a candidate.

   The documented example doesn't work. This is docs/permissions.mdx verbatim, presented as the supported way to allow reads but block edits in an external directory:

   config: external_directory allow + edit deny on ~/projects/personal/**
   
   edit VERDICT (documented intent: deny) : ask
   external_directory VERDICT             : allow
   

   The external_directory half works, the edit half doesn't, and they're written by the same operator in the same block with the same pattern.

   No relative form works portably. Note the two relativized strings above: ../../../../etc/passwd and ../personal/notes.md. The ../ count depends on where the session was started, so the same rule text produces a different non-matching string per project. There's no relative spelling an operator could use instead.

   The correct model already exists in three places in-tree, which is what makes this a bug rather than a design decision:

   • permission/index.ts:178-184 — expand() deliberately turns ~/... into an absolute pattern on every rule, then that pattern is compared against a relativized target.
   • tool/external-directory.ts:30-37 — passes an absolute glob to the same ctx.ask. That's precisely why external_directory rules work while edit rules don't.
   • project/instance-context.ts:18 — containsPath already solves inside-vs-outside including the non-git worktree === "/" case.

   Scope correction on my own earlier reading, since it matters for anyone auditing their config: this affects only the edit/write/read/apply_patch keys. external_directory and list match absolute paths and are fine. If you have an absolute rule that seems to work, check which key it's declared under before concluding anything — I got that wrong initially and so did two other people looking at the same evidence.

   Field data. An independent OpenCode deployment replayed the fix against its own permission logs: 125,800 evaluated lines → 19,411 distinct (pattern, rule, verdict) triples, re-evaluated with the platform's own Wildcard.match. Zero regressions. 181 verdicts flipped deny→allow, all of them scratch paths the operator had already written an allow rule for.

   Across two deployments, every rule found genuinely inert was an allow — the friction everyone has reported. The deny-direction bypass above is demonstrated from the matcher rather than from a field incident, which I'd argue makes it easier to verify, not weaker: it reproduces in about a minute.

   The PR takes the smallest fix that works — one helper, five call sites, evaluate() and last-match-wins untouched. #22336's broader proposal (specificity ranking, glob semantics) is a real discussion but a separate one, and mixing them is part of why the earlier attempts stalled.
4. github-actions commented on Oct 2, 2026

   

   github-actionsBot

   on Oct 2, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
5. github-actions

   closed this as not plannedon Oct 2, 2026