Skip to content

[FEATURE]: Treat permission path patterns as proper glob patterns, with support for both relative and absolute patterns. #22465

Closed as not planned

Description

@CarloWood

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

At the moment, permission path matching does not behave like standard glob matching.
This has several downsides, among which the inability to specify a pattern that only matches everything inside the worktree, but not outside the worktree.

The problem

  1. A * is currently replaced with a .* in regex, matching everything including multiple directories and ../.
  2. It is not possible to specify a pattern that matches an absolute path for the "edit" section, which is only matched against the path relative to the current worktree.
  3. Some permission keyword's patterns are matched against absolute paths, others are matched against relative paths.

Current situation

permission keyword:

  • "read" : matched against the absolute target path.
  • "edit" : matched against a path relative to Instance.worktree.
  • "external_directory" — matched against an absolute directory glob.
  • "list" — matched against the absolute directory being listed.

Proposal

Unify all filepath matching as true globbing, including support for a globstar (**).
This can achieved with the already existing path.matchesGlob in typescript.

For example:

daniel:~/projects/github/ai-cli/globtest>cat test.ts
import path from "node:path";

const patterns = ["*", "*/*", "**/*", "../**/*"];
const filepaths = ["bar/foo", "foo", "../foo", "../../foo"];

for (const pattern of patterns) {
  console.log(`Pattern: ${pattern}`);
  for (const filepath of filepaths) {
    console.log(`  ${JSON.stringify(filepath)}: ${path.matchesGlob(filepath, pattern)}`);
  }
}
daniel:~/projects/github/ai-cli/globtest>node test.ts
Pattern: *
  "bar/foo": false
  "foo": true
  "../foo": false
  "../../foo": false
Pattern: */*
  "bar/foo": true
  "foo": false
  "../foo": false
  "../../foo": false
Pattern: **/*
  "bar/foo": true
  "foo": true
  "../foo": false
  "../../foo": false
Pattern: ../**/*
  "bar/foo": false
  "foo": false
  "../foo": true
  "../../foo": false

If path.matchesGlob is used for "read", "edit", "external_directory" and "list" (all permission keywords that match filepaths) then

  1. A single * matches just one path component as opposed to any number of subdirectories and even ../../etc/passwd, making it much more useful.
  2. "**/*" (or just "**") can be used to match every file inside worktree without running the risk it matches something outside of it.
  3. all of them will support both absolute and relative paths (relative to the current worktree)

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Apr 14, 2026
  2. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Apr 14, 2026
  3. github-actions commented on Apr 14, 2026

    @github-actions
    Contributor

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

  4. CarloWood commented on Apr 14, 2026

    @CarloWood
    ContributorAuthor

    I closed #22336 in favor of this one although it has an orthogonal component that I think we should keep, namely that (glob) patterns that return true when passed to path.isAbsolute should be matched to the absolute filepath, otherwise to the relative filepath. And treat everything the same (read, edit, external_directory, list). Doing that then also addresses #20045 completely.

  5. removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  6. github-actions commented on Jul 4, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

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