Repository navigation
Conversation
…ive patterns
Permission patterns produced by tools are worktree-relative
(path.relative(worktree, filePath)), so config rules written as
absolute paths never match: inside the worktree paths arrive as
relative ("facts/me.md"), outside as traversal ("../../czk/..."),
and without a git context as de-rooted ("czk/...").
Add evaluateCandidates(): alongside the original pattern, evaluate an
absolutized candidate (path.resolve(worktree, pattern)), but only
against rules whose pattern is absolute (leading "/"). Absolute
rules work as users expect, while relative-semantic rules like "*"
keep their original meaning and cannot allow paths outside the
worktree. Deny > allow > ask across candidates.
7 new tests in test/permission/absolute-rules.test.ts; permission
suite passes (92), acp/cli suites unchanged.
github-actions
Bot
added
the
needs:compliance
|
The following comment was made by an LLM, it may be inaccurate: Based on my search, I found a potentially related PR: #40149 - This PR appears to address a similar issue with absolute permission pattern matching. While PR #48194 focuses on matching absolute permission rules against worktree-relative patterns, PR #40149 seems to handle a related aspect of absolute permission pattern matching behavior. However, given that PR #48194 is specifically fixing issue #48193 with a new test suite and a different implementation approach ( No other open PRs appear to be duplicates of the current PR #48194. |
github-actions
Bot
removed
the
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #48193
Type of change
What does this PR do?
Tools send the permission matcher worktree-relative patterns (
path.relative(worktree, filepath)), so a config rule written as an absolute path ({"edit": {"/czk/**": "allow"}}) never competes — inside the worktree the pattern is relative (facts/me.md), outside it is traversal (../../czk/...), without git context it is de-rooted (czk/...). Related: #40149 fixes this at the five tool call sites; this PR fixes it inside the matcher instead, so every caller benefits without changing what patterns look like.evaluateCandidates()evaluates the original pattern as before, plus an absolutized candidate (path.resolve(worktree, pattern)) — but only against rules whose own pattern starts with/. Relative-semantic rules like"*"keep their original meaning and cannot allow a path outside the worktree through the absolutized candidate. Across candidates: deny > allow > ask.How did you verify your code works?
test/permission/absolute-rules.test.ts: the three pattern forms, deny precedence over"*", no leak of"*"via the absolutized candidate, unchanged behavior for relative-only rulesetsbun test test/permission/: 92/92 passbun test test/acp/ test/cli/: 501 tests, only a pre-existing help-text snapshot failure that also fails on cleandev(verified by stashing this change)Screenshots / recordings
Not a UI change.
Checklist