Permission Wildcard * Overwriting Lower Permissions

Description

According to the docs https://opencode.ai/docs/permissions/:

Rules are evaluated by pattern match, with the last matching rule winning. A common pattern is to put the catch-all "*" rule first, and more specific rules after it.

Therefore the below opencode.json should result in a behavior allowing writing to the specified directory but no others, regardless of the root project directory location.

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
	"external_directory": {
	  "~/Documents/Programming/AI/**": "allow"
	},
    "edit": {
	  "*": "deny",
	  "~/Documents/Programming/AI/**": "allow"
	},
    "bash": {
	  "*": "deny",
	  "cd ~/Documents/Programming/AI/*": "allow",
	  "ls ~/Documents/Programming/AI/*": "allow",
	  "touch ~/Documents/Programming/AI/*": "allow",
	  "pwd": "allow"
	}
  }
}

However this results in no write access in any directory.

Similarly, based on my interpretation of the docs, this altercation to the opencode.json should also allow for the same expected behavior:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
	"external_directory": {
	  "~/Documents/Programming/AI/**": "allow"
	},
	"edit": "deny",
    "edit": {
	  "~/Documents/Programming/AI/**": "allow"
	},
    "bash": {
	  "*": "deny",
	  "cd ~/Documents/Programming/AI/*": "allow",
	  "ls ~/Documents/Programming/AI/*": "allow",
	  "touch ~/Documents/Programming/AI/*": "allow",
	  "pwd": "allow"
	}
  }
}

This results in having write access to all directories. The documentation is worded to imply that this might only work when restricting access?

Add explicit rules when a tool should be restricted in these paths, such as blocking edits while keeping reads:

Plugins

None

OpenCode version

1.14.25

Steps to reproduce

Use the provided opencode.json configurations.
Ask OpenCode to write to a file within your specified directory

Screenshot and/or share link

No response

Operating System

Fedora 43

Terminal

Foot

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

Granular permissions not working (or documentation bad?) #20307: Granular permissions not working (or documentation bad?) — same confusion about wildcard * + specific path allow rules not behaving as expected, same docs section referenced
Permission edit patterns #13872: Permission edit patterns — same symptom: "*": "deny" with a specific allow pattern results in no write access anywhere
New permission system issues with wildcards and glob patterns #7029: New permission system issues with wildcards and glob patterns — same root issue: specific patterns should take precedence over wildcard denies, but don't

If your issue is distinct from the above, feel free to clarify the differences.

Took a look at this on the latest dev. The primary symptom you're describing — "*": "deny" followed by "~/Documents/Programming/AI/**": "allow" denying everything — appears to be already fixed by #24308 (fix(config): preserve permission order with Effect decode), merged ~1.5 hours after this issue was filed.

Before #24308, the Effect Schema decode could canonicalise known keys (like *, edit) ahead of the user-written order, so the wildcard *: deny could end up after the specific allow rule in the resulting ruleset, causing it to win. After #24308, decode uses propertyOrder: "original", so the user's key order is preserved at every nesting level.

I reproduced your opencode.json end-to-end on dev (load via Config.Service → Permission.fromConfig → Permission.evaluate) and the actions come out as expected:

evaluate("edit", "<home>/Documents/Programming/AI/file.md") → allow
evaluate("edit", "/some/other/dir/file.md") → deny
evaluate("bash", "cd ~/Documents/Programming/AI/x") → allow
evaluate("bash", "rm -rf /") → deny

You were on 1.14.25, which predates #24308 — please retest on the next release once it ships.

I opened #24361 with a regression test that mirrors your exact config end-to-end (the existing permission config preserves user key order test only covered the outer keys; #24361 also asserts the nested rule key order, which is where this issue reproduces).

Two notes on your second config in the issue body:

"edit": "deny",
"edit": {
  "~/Documents/Programming/AI/**": "allow"
}

That has a duplicate edit key in JSON. Per the JSON spec the second occurrence wins, so the resulting config is edit: { "~/Docs/...": "allow" } with no wildcard deny — which is why you saw "write access to all directories". That's a JSON-level thing, not opencode behavior.

Closing thoughts: if behavior on the next release still doesn't match expectations, please reopen with a small repro and the version, and we can dig in further.

The first opencode.json still prevents writing to the specified directory on 1.14.27

Confirming that the first config above still behaves in this incorrect way as of v1.14.45

Encountering this issue as well. Definitely a regression. I reported a similar bug weeks ago and it was fixed, but now it's happening again.

Confirming that the first config above still behaves in this incorrect way as of v1.15.12

Ran into the same thing on v1.17.4. As a workaround, I removed the "*": "deny" wildcard and only kept the allow rules in my sub-agent config:

permission:
  external_directory:
    "/tmp/**": allow
  edit:
    "/tmp/**": allow

For context, I also have global permission rules set — but they weren't the issue here. My global config has edit set to allow, yet the sub-agent was still prompting me for edit permission, which confirms it was the agent-level rules (specifically the "*": "deny" wildcard) overriding things. Once I dropped the deny wildcard from the agent config, paths outside the allow list default to asking for permission instead of flat-out denying.

Not a fix, but gets things unblocked.

I can confirm this is still an issue, and I'm pretty shocked it's been around for so long - permissions not working as documented is a fairly critical security issue, especially if it's failing to block tool calls that the user has intended as denied.

still broken on 1.18.14.
Denies to edit/write in projects directory with this config:

"permission": {
  "edit": {
    "*": "deny",  
    "/Users/enduro/stuff/Neuro/projects/**": "allow"
}

Yeah, same issue here - this wont work:

"edit": {
  	      "*": "allow",
  	      "/home/ubuntu/.config/opencode/opencode.json": "deny",
  	},

This will (for the OC editor only!):

"edit": {
  	 	  ".config/opencode/opencode.json": "deny",
  	},

Now AI will bypass this by using bash cmds to work around above editors block, so bash needs to be denied as well:

"edit": {
  	      ".config/opencode/opencode.json": "deny",
  	},

"bash": {
  	      "* .config/opencode/opencode.json*": "deny",
  	      "*opencode.json*": "deny",
    },

Additionally, filesystem permissions need to be tightened too:

sudo chown root:root .config/opencode/opencode.json
sudo chmod 0444 .config/opencode/opencode.json
sudo chown root:root .config/opencode
sudo chmod 0755 .config/opencode

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Navigation Menu

Repository navigation

Permission Wildcard * Overwriting Lower Permissions #24335

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Permission Wildcard * Overwriting Lower Permissions #24335

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Apr 25, 2026

tiffanychum commented on Apr 25, 2026

matthew-j-hooper commented on Apr 27, 2026

matthew-j-hooper commented on May 10, 2026

RisaKirisu commented on May 10, 2026

matthew-j-hooper commented on May 29, 2026

socrabytes commented on Jun 12, 2026

tamasys commented on Jul 16, 2026

enduro commented on Aug 6, 2026

fidodido48 commented on Sep 7, 2026

thdxr commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions