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 .tmp file 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.json to 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:

  1. Allows all file operations within the project root (including .claude/)
  2. Allows all Bash commands whose targets resolve to within the project root
  3. Prompts for any operation that touches paths outside the project root
  4. Still prompts for truly destructive git operations (force push, reset --hard) as a separate safety layer

View original on GitHub ↗

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