Permission Wildcard * Overwriting Lower Permissions

[matthew-j-hooper]

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

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

Screenshot and/or share link

No response

Operating System

Fedora 43

Terminal

Foot

[github-actions]

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.

[tiffanychum]

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.

[matthew-j-hooper]

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

[matthew-j-hooper]

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

[RisaKirisu]

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.

[matthew-j-hooper]

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

[socrabytes]

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.

[tamasys]

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.