Feature: Project-scoped trust boundary for simpler permission model
Resolved 💬 3 comments Opened Mar 15, 2026 by morecheesepls Closed Apr 12, 2026
Feature Request: Project-scoped trust boundary
Problem
The current permission model has multiple independent layers (permission modes, settings.local.json patterns, built-in sensitive path protection, security heuristics) that produce inconsistent prompting behavior. Users cannot express a simple, intuitive policy like "allow everything inside my project directory, prompt for everything outside."
Current behavior examples
- Deleting a
.tmpfile inside.claude/prompts because.claude/is a hardcoded sensitive path - A Bash command with
#in a heredoc body prompts due to a security heuristic, even when the command target is a known-safe repo - Claude can edit
.claude/settings.local.jsonto grant itself broader Bash permissions, undermining the layered model - Each prompt gives a different reason (sensitive file, security heuristic, permission pattern miss), making the system feel arbitrary
Desired behavior
A single project-scoped trust boundary:
- Inside project directory → allowed without prompting (file reads, writes, deletes, Bash commands operating on project files)
- Outside project directory → always prompt for approval
This maps to how developers actually think about project safety: "do whatever you want in my repo, but don't touch anything else on my machine."
Why this matters
- The current patchwork creates friction that trains users to click "Yes" without reading — the opposite of the security goal
- Users who want a simple trust model have no way to express it
- The "defense in depth" framing breaks down when Claude can modify its own permission config
Suggested implementation
A permission mode or setting like trust_project_directory: true that:
- Allows all file operations within the project root (including
.claude/) - Allows all Bash commands whose targets resolve to within the project root
- Prompts for any operation that touches paths outside the project root
- Still prompts for truly destructive git operations (force push, reset --hard) as a separate safety layer
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗