Repository navigation
Permission edit patterns #13872
Description
Question
The docs for this are really unhelpful - this example isn't really explained:
"edit": {
"*": "deny",
"packages/web/src/content/docs/*.mdx": "allow"
}
What does the packages/web/src/content/docs/*.mdx pattern mean?
To my understanding of glob patterns, this means *.mdx files in that folder but not in subfolders?
For subfolders, you would need path/**/*.ext correct?
But I had this pattern and it doesn't work:
"$schema": "https://opencode.ai/config.json",
"permission": {
"edit": {
"*": "deny",
"src/**/*": "allow",
"spec/**/*": "allow",
}
},
With this, it was unable to edit anything in src or spec folders.
Assuming this works, and assuming these are reasonably standard glob patterns, that should work, right?
I've pored over the docs, I've tried again and again, I've asked on the discord and no one really seems to know, and I can't get this feature to work. No matter what I put under "edit" it fails to write anything. Only by omitting this section entirely have I been able to get opencode to write anything.
Could we have some useful examples in the docs maybe?
Just a few basic pattern examples with explanations:
- specific files
- specific files in a specific folder
- specific files in a specific folder and all subfolders
This should be enough for most people to intuit the essentials, I think?
(also, side note, but is "yolo" mode really the default? I have opencode on 3 different systems, and on one of them, it asked for permissions in the session - on two other systems, with a totally clean install and no real configuration, it just does whatever it wants. does merely adding the permission section to the project's opencode.jsonc wipe out all the defaults and just permit everything, or how it this supposed to work?)
Activity
github-actions commentedon Feb 16, 2026
This issue might be a duplicate or related to existing issues about permission patterns not working as documented. Please check:
The behavior you're describing (permissions failing to work regardless of pattern) matches the reported bug in #13646. You may want to follow that issue for updates, or check if there's additional context there about workarounds.
diegonix commentedon Mar 19, 2026
Custom subagents configured with nested
editpermission patterns (deny all, allow specific path) receive aPermissionDeniedErroreven when the target path matches the allow rule.Config (opencode.json):
{ "agent": { "my-agent": { "mode": "subagent", "description": "", "model": "openai/gpt-5.3-codex", "permission": { "*": "deny", "edit": { "*": "deny", "/tmp/**": "allow" }, "read": "allow", "bash": "allow", "grep": "allow", "glob": "allow", "list": "allow", "task": "allow", "question": "allow", "todoread": "allow", "todowrite": "allow", "websearch": "allow", "webfetch": "allow", "external_directory": { "/tmp/**": "allow" } }, "prompt": "{file:prompts/my_agent.txt}", "steps": 50 } } }Error output:
When the subagent attempts to write a file under
/tmp/, the following error is returned:Expected behavior:
The ruleset is constructed correctly — the most specific rule (
edit+/tmp/**→allow) should take precedence over the broader rule (edit+*→deny). The agent should be allowed to edit files under/tmp/.Actual behavior:
The permission system evaluates the broad
"*": "deny"rule as the winner, ignoring the more specific/tmp/**allow rule. The edit is denied.Analysis:
The
PermissionNext.askfunction does not appear to implement "longest/most-specific pattern wins" semantics. The broad wildcard*matches the path and itsdenyaction is returned without checking whether a more specific pattern (like/tmp/**) also matches and should take priority.This is likely the same root cause as:
Environment:
rekram1-node commentedon Jun 23, 2026
Automated: closing question issues.
GitHub Issues are for bug reports and feature requests only — questions / support are no longer tracked here.
If this is a bug or feature request, please open a new issue with the appropriate template.