claude-code - 💡(How to fix) Fix sandbox.enabled: false ignored at runtime; allowWrite emits doubled path prefix (2.1.116) [3 comments, 2 participants]

Summary

On 2.1.116, sandbox.enabled: false is accepted by the config parser but the runtime filesystem policy is still enforced, and a separate parser bug in sandbox.filesystem.allowWrite emits paths with a doubled prefix. Together these make it impossible to either opt out of the sandbox or configure a working allowlist.

Filing separately from #35986 because (a) this is a 2.1.116 reproduction with a minimal config, and (b) the allowWrite doubling (Symptom B below) is a distinct parser defect that blocks the workaround path #35986 implies.

Environment

• Claude Code 2.1.116 (native-binary build)
• Linux host
• No MDM (/etc/claude-code/managed-settings.json not present)
• No ANTHROPIC_* or sandbox-relevant CLAUDE_* env vars

Symptom A — sandbox.enabled: false does not disable the sandbox

Minimal config

Both ~/.claude/settings.json and ~/.claude/settings.local.json:

{ "sandbox": { "enabled": false } }

No filesystem sub-block. No other sandbox configuration anywhere.

Expected

Sandbox disabled; arbitrary filesystem writes within the user's own home succeed.

Actual

Runtime policy still carries a populated filesystem.write.allowOnly list, and writes to directories that are in that allowlist nevertheless fail EROFS. Example (directory is explicitly listed in the runtime allowlist):

$ touch ~/.claude/MEMORY/.probe
touch: cannot touch '/home/<USER>/.claude/MEMORY/.probe': Read-only file system

So two things fail together: the enabled: false flag does not short-circuit filesystem policy, and the policy itself does not honor its own allowlist entries.

Symptom B — allowWrite path parser doubles the prefix

When a user configures an explicit allowlist as the workaround, runtime evidence shows the paths are emitted with the .claude segment doubled. Observable fingerprint in the runtime allowlist:

/home/<USER>/.claude/<somedir>           ← correct form
/home/<USER>/.claude/.claude/<somedir>   ← parser-mangled form, no such path on disk

No user configuration contains the doubled form; it is introduced somewhere between config parse and runtime policy assembly.

Repro across versions

Impact

Users hit a closed loop: allowWrite is unusable (Symptom B), and the enabled: false escape hatch doesn't actually escape (Symptom A). The only current options are to Docker-wrap Claude Code or roll back ~115 versions to 2.1.1 (the last-good version named in #18631).

Related

• #35986 — sandbox.enabled: false ignored
• #50781 — user-visible EROFS symptom
• #18631 — last-known-good version (2.1.1)
• #40133 — managed-settings workaround
• #17727 — bwrap flag handling

Ask

1. Confirm whether sandbox.enabled: false is intended to bypass the filesystem policy layer. If yes, this is a runtime-enforcement regression.
2. Fix the allowWrite path-doubling parser so the documented workaround is usable in the interim.
3. If neither is planned for the next release, publish a pinned version that users can target without rolling back 115 releases.