Skip to content

Windows: permission.read exact path rules fail with / and require \ to match #23048

@deokju

Description

@deokju

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:

opencode debug config

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

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingcoreAnything pertaining to core functionality of the application (opencode server stuff)windows

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions