Description
Summary
A project-level permission.read deny rule in opencode.json appears in opencode debug config, but an exact file path rule does not block reading the file.
A wildcard filename rule like *ExampleController.java does work.
This seems to be an issue in how OpenCode matches or evaluates the project config path rule, rather than anything related to OS-level file permissions.
Environment
- OS: Windows
- OpenCode CLI: latest
- Project config file:
opencode.json
Reproduction
I configured this in my project root opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"read": {
"*": "allow",
"src/main/java/com/example/app/controller/ExampleController.java": "deny"
}
}
}
Then I ran:
The deny rule appears in the resolved config output.
However, when I ask OpenCode to read or show the contents of:
src/main/java/com/example/app/controller/ExampleController.java
it still reads and shows the file content.
Expected behavior
If the exact path is present in permission.read and is visible in opencode debug config, OpenCode should deny reading that file.
Project-level permission behavior should also be consistent across environments, so users do not need to write different path rules depending on the OS.
Actual behavior
OpenCode still reads the file even though the project-level deny rule is loaded and visible in the resolved config.
On Windows, an exact permission.read path using forward slashes (/) does not appear to match reliably.
In my testing, the exact path rule:
src/main/java/com/example/app/controller/ExampleController.java
did not block reads, while a broader wildcard rule like:
*ExampleController.java
did work.
This suggests OpenCode may be evaluating file paths differently on Windows, possibly using backslash-separated paths (\\) internally without normalizing them before permission matching.
As a result, users may need to write path rules differently depending on the OS, which makes project-level permission behavior inconsistent across environments.
Workaround
This works:
{
"permission": {
"read": {
"*": "allow",
"*ExampleController.java": "deny"
}
}
}
So the deny logic is working in general, but the exact path rule does not appear to match in this case.
Notes
I observed this on Windows, but the issue seems to be about project config path matching rather than OS-level permission handling.
The main concern is that users may have to account for path separator differences such as / vs \\ when writing project-level permission rules.
It would be helpful if OpenCode normalized file paths consistently before evaluating permission.read rules.
Plugins
none
OpenCode version
1.4.7
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
Windows11
Terminal
Windows powerShell
Description
Summary
A project-level
permission.readdeny rule inopencode.jsonappears inopencode debug config, but an exact file path rule does not block reading the file.A wildcard filename rule like
*ExampleController.javadoes work.This seems to be an issue in how OpenCode matches or evaluates the project config path rule, rather than anything related to OS-level file permissions.
Environment
opencode.jsonReproduction
I configured this in my project root
opencode.json:{ "$schema": "https://opencode.ai/config.json", "permission": { "read": { "*": "allow", "src/main/java/com/example/app/controller/ExampleController.java": "deny" } } }Then I ran:
The deny rule appears in the resolved config output.
However, when I ask OpenCode to read or show the contents of:
src/main/java/com/example/app/controller/ExampleController.javait still reads and shows the file content.
Expected behavior
If the exact path is present in
permission.readand is visible inopencode debug config, OpenCode should deny reading that file.Project-level permission behavior should also be consistent across environments, so users do not need to write different path rules depending on the OS.
Actual behavior
OpenCode still reads the file even though the project-level deny rule is loaded and visible in the resolved config.
On Windows, an exact
permission.readpath using forward slashes (/) does not appear to match reliably.In my testing, the exact path rule:
src/main/java/com/example/app/controller/ExampleController.javadid not block reads, while a broader wildcard rule like:
*ExampleController.javadid work.
This suggests OpenCode may be evaluating file paths differently on Windows, possibly using backslash-separated paths (
\\) internally without normalizing them before permission matching.As a result, users may need to write path rules differently depending on the OS, which makes project-level permission behavior inconsistent across environments.
Workaround
This works:
{ "permission": { "read": { "*": "allow", "*ExampleController.java": "deny" } } }So the deny logic is working in general, but the exact path rule does not appear to match in this case.
Notes
I observed this on Windows, but the issue seems to be about project config path matching rather than OS-level permission handling.
The main concern is that users may have to account for path separator differences such as
/vs\\when writing project-level permission rules.It would be helpful if OpenCode normalized file paths consistently before evaluating
permission.readrules.Plugins
none
OpenCode version
1.4.7
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
Windows11
Terminal
Windows powerShell