UX: defaultMode: bypassPermissions does not imply sandbox-off — easy to miss, breaks every in-project build

UX: permissions.defaultMode: bypassPermissions does not imply sandbox-off — please document or merge

TL;DR

permissions.defaultMode: bypassPermissions and sandbox.enabled are orthogonal settings, but most users (myself included) assumed the first implied the second. Result: I set bypassPermissions, restarted CC, and was still hit with Read-only file system errors on every in-project write because the sandbox was still mounting hooks/, config/, ~/.claude/, even ~/.bashrc as RO. The fix (add "sandbox": {"enabled": false} as a separate top-level key) is documented but very easy to miss, and the per-call dangerouslyDisableSandbox: true cannot reach the mount layer once the namespace is built.

This is a UX request, not a "the sandbox is broken" report — the sandbox works as designed, but the "I want maximum permissiveness" mental model maps badly to the current setting layout.

Repro of the confusion

// ~/.claude/settings.json — what I had
{
  "permissions": { "defaultMode": "bypassPermissions" }
  // (no `sandbox` key — defaults to enabled in 2.1.x)
}

Fresh terminal, fresh claude session:

$ mount | grep myproject
/dev/sda1 on /root/myproject/hooks  type ext4 (ro,nosuid,nodev,...)
/dev/sda1 on /root/myproject/config type ext4 (ro,nosuid,nodev,...)
/dev/sda1 on /root/.claude          type ext4 (ro,nosuid,nodev,...)

$ touch /root/myproject/hooks/test
touch: cannot touch '/root/myproject/hooks/test': Read-only file system

$ cd /root/myproject/hooks/go && go build -o bin/x ./cmd/x
go build: copying /tmp/.../a.out: open bin/x: read-only file system

dangerouslyDisableSandbox: true on the Bash call doesn't help — the mount namespace was set up at CC startup, before per-call flags exist.

Working config:

{
  "permissions": { "defaultMode": "bypassPermissions" },
  "sandbox":     { "enabled": false }
}

Why this is confusing

1. The names suggest hierarchy. "bypassPermissions" sounds maximally permissive. A new user reasonably expects it to bypass the sandbox too — sandbox IS a permission, conceptually.
2. The error message (Read-only file system) gives no hint that there's a separate sandbox.enabled setting to flip. It looks like a perms / disk problem.
3. dangerouslyDisableSandbox: true exists per-Bash-call but doesn't actually work for in-project writes (mount NS is already set up). Its existence implies "this is enough to bypass" when it isn't.
4. The settings docs put sandbox under "Advanced" — but for any user who installs CC and tries to do real work in a project (go build, npm install, cargo build), the sandbox is in the critical path on day one.

Suggested fix (any one of these)

• Option A — make bypassPermissions imply sandbox-off. Simplest mental model. If the user wants to keep the sandbox, they explicitly set sandbox.enabled: true alongside bypassPermissions. Backwards-incompatible but probably the right default.
• Option B — better error message. When a write fails inside an RO bind mount, surface: This path is RO-mounted by the CC sandbox. To allow writes, add it to sandbox.filesystem.allowWrite, or set sandbox.enabled: false. See <link>. Even one line in the failure path would save users from bisecting /proc/mounts.
• Option C — sane default allowWrite list. Auto-include common build dirs (./bin, ./build, ./dist, ./target, ./node_modules, ./.cache) in the default sandbox config. They're never sensitive and breaking them breaks every standard build system.
• Option D — UX in /config. The interactive Settings TUI could show a banner: "Sandbox: ON. defaultMode: bypassPermissions. These are orthogonal — bypassPermissions does not disable the sandbox."

Environment

• CC version: 2.1.104
• OS: Linux 5.15.0-174 (Ubuntu)
• Sandbox driver: bwrap

Related issues

• #17727 — Linux sandbox bwrap allow rules ignored
• #18631 — bwrap regression with symlinked dotfiles in 2.1.2+
• #15789 — /sandbox partially useless (Glob/Read/Write bypass it)
• #46165 — empty 0-byte files in CWD on startup since ~2.1.98
• #20119 — Bash tool tries to create .claude in project, denied by sandbox
• #29048 — sandbox.filesystem.allowWrite not enforced for Write/Edit in bypassPermissions mode