[FEATURE] Support path-scoped Edit/Write permissions with relative path resolution

Resolved 💬 3 comments Opened Jan 28, 2026 by yuong1979 Closed Jan 31, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Problem Statement:
When using local settings to scope Edit/Write permissions to a project directory, the patterns don't match
because Claude Code uses relative paths in tool calls while permission patterns use absolute paths.

Example local settings:
{
"permissions": {
"allow": [
"Edit(/home/user/my-project/)",
"Write(/home/user/my-project/
)"
]
}
}

When Claude creates a file, the tool call is Write(hello.txt), not Write(/home/user/my-project/hello.txt).
The pattern never matches, so permissions aren't scoped.

This makes it impossible to auto-approve edits within a project while requiring approval for edits outside
it.

Proposed Solution

Proposed Solution:
Resolve relative paths to absolute paths before matching against permission patterns.

When Claude calls Write(hello.txt) from /home/user/my-project/, resolve it to
Write(/home/user/my-project/hello.txt), then match against the permission pattern.

This would allow users to define project-scoped permissions that actually work.

---
Alternative Solutions:
I've tried:

  • Using bare Edit/Write allows: Works but allows edits to ANY directory, not just the project
  • Session approval (Shift+Tab): Same issue, just manual trigger
  • Approving every edit manually: Works but breaks autonomous workflows
  • Global deny lists: Can protect specific paths but can't enumerate "all other projects"

None provide true project-scoped containment.

Alternative Solutions

Alternative Solutions:
I've tried:

  • Using bare Edit/Write allows: Works but allows edits to ANY directory, not just the project
  • Session approval (Shift+Tab): Same issue, just manual trigger
  • Approving every edit manually: Works but breaks autonomous workflows
  • Global deny lists: Can protect specific paths but can't enumerate "all other projects"

None provide true project-scoped containment.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Use Case Example:

  1. I'm working on a React app in /home/user/project-a
  2. I run claude-ready which creates local settings with Edit(/home/user/project-a/**)
  3. I ask Claude to refactor multiple files autonomously
  4. With this feature, Claude could edit files in project-a without prompts
  5. If Claude tried to edit /home/user/project-b/file.txt, I'd get a permission prompt
  6. This saves me time while preventing accidental cross-project edits and reducing prompt injection blast

radius

Additional Context

Additional Context:
Security benefit: This enables least-privilege for long-running autonomous sessions. If a prompt injection
attack (e.g., malicious content in a file Claude reads) tries to modify files outside the project, it would
be blocked.

Environment: Claude Code 2.1.17, WSL2 Linux

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗