You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Permission read/edit rules with absolute path patterns are silently ignored (matching appears workspace-relative only) #46133
opencode 1.18.21 (npm global, Linux x86_64, headless service + Web UI)
Config: ~/.config/opencode/opencode.json
What happened
Permission rules for read/edit with absolute path patterns are silently ignored — the action is neither enforced nor reported. Relative patterns for paths inside the working directory work as documented.
With the session started in /home/user/project, a read of /home/user/secrets/key.txt is allowed (rule silently skipped). Changing the pattern to a relative form or ~/secrets/* behaves differently, which suggests the matcher's subject is the workspace-relative path (or matching only applies to paths under the working directory), while absolute-path patterns fail to match anything — without any warning at startup or at evaluation time.
Why this matters (security-relevant)
A user who adds what looks like a correct deny rule gets no enforcement and no error — a silent failure mode. We only noticed during a credentials-migration audit when explicit probe reads of a deny-listed absolute path succeeded.
Observed in our setup (evidence chain from 2026-08-29 probes):
deny rules with absolute path patterns: silently not enforced (probe read succeeded)
the same paths denied via other mechanisms (e.g. plugin-level enforcement or agent sandbox denyRead): enforced as expected
after restart, same result — deterministic, not a caching issue
Expected behavior (one of)
Absolute path patterns match against the absolute path, or
At minimum, warn at startup / config validation when a read/edit pattern can never match (absolute path outside workspace), or
Document explicitly that patterns are workspace-relative only.
Option 1 or 2 would have prevented a real security misconfiguration on our side.
Reproduction
Start opencode in any working directory
Add the config above (deny an absolute path that exists outside the working directory)
Restart opencode
Ask the agent (or use any tool) to read the denied absolute path
Read succeeds; no warning is emitted
Happy to provide full config/probe logs if useful. Thanks!
These issues describe the same root cause: path matching uses workspace-relative paths, so absolute-path patterns in permission rules silently fail to match.
Activity
github-actions commentedon Aug 29, 2026
This issue might be a duplicate of existing issues. Please check:
~permission rules never match out-of-worktree files~patterns silently never match (fail-open for deny rules)These issues describe the same root cause: path matching uses workspace-relative paths, so absolute-path patterns in permission rules silently fail to match.
OpeOginni commentedon Aug 29, 2026
Is this a project with git initialized?
thdxr commentedon Oct 11, 2026
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊