Skip to content

Permission read/edit rules with absolute path patterns are silently ignored (matching appears workspace-relative only) #46133

Closed as not planned

Description

@ouyangjian28

Environment

  • 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.

Example:

{
  "permission": {
    "read": {
      "*": "allow",
      "/home/user/secrets/*": "deny"
    }
  }
}

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)

  1. Absolute path patterns match against the absolute path, or
  2. At minimum, warn at startup / config validation when a read/edit pattern can never match (absolute path outside workspace), or
  3. Document explicitly that patterns are workspace-relative only.

Option 1 or 2 would have prevented a real security misconfiguration on our side.

Reproduction

  1. Start opencode in any working directory
  2. Add the config above (deny an absolute path that exists outside the working directory)
  3. Restart opencode
  4. Ask the agent (or use any tool) to read the denied absolute path
  5. Read succeeds; no warning is emitted

Happy to provide full config/probe logs if useful. Thanks!

Activity

  1. github-actions commented on Aug 29, 2026

    @github-actions
    Contributor

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

    These issues describe the same root cause: path matching uses workspace-relative paths, so absolute-path patterns in permission rules silently fail to match.

  2. OpeOginni commented on Aug 29, 2026

    @OpeOginni
    Contributor

    Is this a project with git initialized?

  3. thdxr commented on Oct 11, 2026

    @thdxr
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions