Skip to content

fix(permission): ask should prefer most specific path rule for relative paths #14541

Closed

Description

@ventsislav-georgiev

Problem

PermissionNext.ask evaluated only the raw incoming pattern. When tools passed relative paths, absolute path-scoped rules could lose to broad wildcard rules.

Expected

Path-scoped rules should apply consistently whether the tool path is relative or absolute, and more specific rules should win over generic ones.

Repro

  1. Configure edit: "allow" globally and a scoped deny/allow rule under a specific directory.
  2. Trigger an edit using a relative path inside that directory.
  3. Observe wildcard behavior can override the scoped intent without absolute evaluation + specificity selection.

Proposed fix

In PermissionNext.ask, evaluate both relative and worktree-resolved absolute candidates, then choose the decision from the longest matched rule pattern.

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Feb 21, 2026
  2. github-actions commented on Feb 21, 2026

    @github-actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • No issue template was used. Please resubmit using one of the three required templates: Bug Report, Feature Request, or Question. The current format uses custom headings that don't match any template.
    • If this is a bug report, please use the Bug Report template which requires a Description field and reproduction steps in the expected format.

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.


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

    If you believe this was flagged incorrectly, please let a maintainer know.

  3. ventsislav-georgiev commented on Feb 21, 2026

    @ventsislav-georgiev
    Author

    Closing as duplicate of #13646, which tracks the same core permission-path precedence issue.

    Related references: #11059 (historical, closed) and #13872 (similar edit-pattern behavior).
    Implemented fix is in PR #14540.

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

Metadata

Metadata

Assignees

Labels

coreAnything pertaining to core functionality of the application (opencode server stuff)needs:complianceThis means the issue will auto-close after 2 hours.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions