[FEATURE] Permission mode: trust CWD & promp for any actions ouside CWD

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

A coherent, intuitive security model for solo developers — "inside the working directory: no prompts; outside the working directory: prompt for every read, write, bash command, or Read-tool call; grow the allowlist on-demand via Yes-always" — cannot be expressed with current primitives. Every available configuration forces an unwanted trade-off.

default / acceptEdits modes: correctly gate reads outside CWD, but command-pattern analysis produces false-positive prompts inside CWD for benign patterns. Common trigger: compound commands with command substitution, e.g. git add X && git commit -m "$(cat <<'HEREDOC' ... HEREDOC)". The workflow is constant in-CWD interruptions for commands that only touch CWD.

bypassPermissions + sandbox.enabled: skips the command-analysis false positives and kernel-blocks bash writes outside CWD. But it leaves two silent leaks:

• Sandbox default read behavior is "entire computer except denied dirs," so cat ~/.ssh/id_rsa via bash runs with no prompt.
• The sandbox does not cover Claude's Read tool. bypassPermissions skips the permission system that would otherwise gate it. So Read("~/.ssh/id_rsa") runs with no prompt.
• Worsened by #34315: dangerouslyDisableSandbox already fails to prompt when the docs say it should.

Permission rules cannot express the policy: evaluation order is deny → ask → allow, first match wins. ask: ["Read(/**)"] matches before allow: ["Read(./**)"] can exempt CWD, so you can't say "allow CWD reads, ask for everything else."

Sandbox filesystem rules don't compose globally: sandbox.filesystem.allowRead: ["."] resolves . relative to the config file's location. A global ~/.claude/settings.json cannot express "current session CWD" — it would mean ~/.claude. The policy is only expressible per-project, requiring scaffolding in every repo.

Current choices are: (a) tolerate false-positive prompts inside CWD, (b) accept silent reads of credentials outside CWD, (c) enumerate and maintain a blacklist of sensitive paths (fragile — new sensitive paths appear over time), or (d) move entirely into a devcontainer. None of these match the stated mental model, and (c) is what the docs and community guides lean on despite being the worst long-term choice.

Proposed Solution

A permission mode (or composable option set) that applies to bash and Claude's Read/Edit tools:

1. No prompts for any operation whose effects are confined to the session's working directory — including compound/substitution bash commands, reads, writes, edits.
2. A prompt for any operation touching paths outside CWD, with the standard Yes / Yes-for-session / Yes-always choices, so the allowlist grows on-demand.
3. "CWD" resolved per-session at runtime, not from config file location, so the mode is usable from a single global ~/.claude/settings.json across all projects.

Conceptually: treat the working directory as a trust boundary. Inside = trusted, skip analysis. Outside = untrusted, ask. The sandbox already does this for bash writes; extending it to cover bash reads and the Read/Edit tools uniformly, and exposing it as a first-class mode, would close the gap.

Alternative Solutions

• Per-project sandbox.filesystem: { denyRead: ["/"], allowRead: ["."] }. Works structurally for bash reads because . resolves to project root in project settings. Doesn't gate Read tool (sandbox doesn't cover it). Requires scaffolding every project.
• Devcontainer with CWD-only mount + --dangerously-skip-permissions. Strongest isolation, matches the mental model by construction. Significant per-project setup cost, breaks some IDE integrations, and is overkill for solo work on trusted repos.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. I launch claude in ~/code/myproject to work on a TypeScript refactor.
2. Claude makes changes and wants to commit: git add src/foo.ts src/bar.ts && git commit -m "$(cat <<'HEREDOC' ... HEREDOC)". Today this prompts because of the && compound and the $(...) substitution, even though every path is inside CWD. I want it to run with no prompt.
3. Claude decides it needs to read ~/.zshrc to check my aliases. Today, under bypassPermissions + sandbox, this succeeds silently. I want a prompt with Yes / Yes-for-session / Yes-always.
4. I click Yes-always for ~/.zshrc. Future reads of that file don't prompt. Reads of other outside-CWD paths still do.
5. I move to a different project (cd ~/code/otherproject && claude). The mode still works — CWD resolves to the new project dir. No per-project config required.

This matches how I reason about trust: the directory I chose to launch in is my working boundary. Everything else is "elsewhere" and should be gated.

Additional Context

_No response_