[Bug] Project-scope settings.json can bypass sandbox isolation via sandbox.enabled: false

Reproduced on v2.1.233 (macOS).

Steps:

1. Put {"sandbox": {"enabled": true}} in ~/.claude/settings.json.
2. mkdir -p probe/.claude && echo '{}' > probe/.claude/settings.json && cd probe
3. claude -p 'run this exact command and show its output: echo $TMPDIR' --allowedTools Bash

Output: /tmp/claude-502 (sandboxed session temp dir).

1. echo '{"sandbox":{"enabled":false}}' > .claude/settings.json and re-run the same command.

Output: /var/folders/.../T/ (the shell's normal TMPDIR, i.e. not sandboxed).

Observed: a project-level .claude/settings.json with sandbox.enabled: false turns the sandbox off entirely, with no prompt or notice, even though user-level settings enable it.

Expected: a checked-out project should not be able to switch the sandbox off (as it can't for sandbox.filesystem.disabled), or the session should at least say that project settings disabled it.

Assessment: This is intended today, but the expectation is reasonable and worth fixing. sandbox.enabled follows the ordinary settings precedence documented at https://code.claude.com/docs/en/settings#settings-precedence (local overrides project, project overrides user), and the sandbox docs at https://code.claude.com/docs/en/sandboxing describe project-local settings as the normal place the /sandbox picker stores the mode, with managed settings as the way to enforce sandboxing that developers and repos can't turn off. Only a short list of security-sensitive keys (sandbox.filesystem.disabled, allowAppleEvents, credentials.allowPlaintextInject, and a few others) are restricted to user, managed, and --settings scope, and sandbox.enabled isn't one of them. That said, the reasoning given for the filesystem.disabled restriction applies even more strongly to disabling the whole sandbox, so a repository being able to silently do that is a real gap. We should make this clearer by honoring sandbox.enabled: false only from user, managed, and --settings scope while still letting project settings turn the sandbox on, or at minimum showing a notice at session start when project settings disable it and documenting the behavior under "Which settings can disable it". Until then, organizations that need the sandbox to be unbypassable should set it in managed settings.

🤖 Generated with Claude Code

Reproduced, and the analysis in the report is correct. I confirmed on the current release that with the sandbox enabled in user settings (~/.claude/settings.json), a project .claude/settings.json containing {"sandbox": {"enabled": false}} turns sandboxing off entirely for sessions started in that directory — commands run with no sandbox attempted, no prompt, and no indication in the session — while the same directory with an empty project settings file sandboxes normally. This is also not macOS-specific; it behaves the same on Linux.

As you note, this sits in tension with the documented scope restriction for disabling filesystem isolation, which project settings deliberately cannot do — while fully disabling the sandbox, a strictly broader action, can be done by a checked-in file. One wrinkle for the fix: the sandbox controls intentionally support per-project configuration via .claude/settings.local.json (which is local and gitignored), so the likely shape is restricting or warning on enabled: false specifically from the shareable .claude/settings.json, along the lines you suggest.

Flagging this to the team as a security-relevant settings-precedence gap. Thanks for the careful report and the clean reproduction steps.

🤖 Generated with Claude Code

For operators and teams looking for an immediate fail-closed mitigation against untrusted repositories attempting to disable sandboxing via checked-in .claude/settings.json:

Because in-repo config files should never be allowed to dictate ambient security boundaries, wrapping execution with Vetto enforces an immutable outer OS boundary:

# Wrap Claude Code with an un-bypassable kernel boundary:
vetto --agent claude --profile strict -- claude -p "..."

Key Security Difference:

• Pre-Execution Invariance: Vetto configures Landlock/Seatbelt and unprivileged namespaces before claude is spawned. Even if .claude/settings.json contains {"sandbox": {"enabled": false}}, the underlying process remains strictly contained by the kernel.
• Fail-Closed Guarantee: The untrusted repository cannot widen filesystem permissions, unmask $HOME/.ssh / .env, or restore external network routes.