[BUG] Linux: sandboxed Bash permanently dies after EnterWorktree into .claude/worktrees/ (bwrap: Read-only file system)

Environment

• Claude Code: 2.1.263 (primary), reproduced on 2.1.278
• OS: Ubuntu 24.04.4 LTS (x86_64), kernel 6.8.0-137-generic
• Sandbox engine: the CLI's bundled bubblewrap (bwrap --version →

bubblewrap built for Codex), engaged via
CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 in the launch environment

• Sessions run headless (claude -p ... --output-format stream-json)

Summary

When the bwrap sandbox is engaged via the CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1
environment variable, a session that runs Bash in the repo root (sandbox warms
and builds its mount plan) and then enters a worktree nested under the
protected .claude/ directory loses all Bash execution for the rest of the
session. The mount plan built at warm-up marks the (later-created) worktree
read-only, so bwrap cannot create its .gitconfig mountpoint inside it and
refuses to start.

Steps to reproduce

export CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1

git init demo && cd demo
mkdir -p .claude/worktrees
echo '# demo' > README.md
git add README.md .claude && git commit -qm init
git worktree add -q -b old1 .claude/worktrees/old1   # pre-existing sibling

claude -p "Do these three steps in order. \
Step 1: run this bash command exactly: echo warm. \
Step 2: use the EnterWorktree tool to create and enter a worktree named wt1. \
Step 3: run this exact bash command and include its full output verbatim in your final answer: \
pwd; echo START; (touch probe.txt && echo WRITE_OK) || echo WRITE_FAIL; \
(git add probe.txt && git commit -qm probe && echo COMMIT_OK) || echo COMMIT_FAIL; echo END" \
  --model haiku --allowedTools EnterWorktree,Bash --output-format stream-json --verbose

Observed

2.1.263 — steps 1–2 succeed; from step 3 onward every Bash tool call
fails with:

bwrap: Can't create file at <repo>/.claude/worktrees/wt1/.gitconfig: Read-only file system

The session never recovers — all later Bash calls die with the same error.
The worktree itself was created fine; only post-entry Bash is dead.

2.1.278 — the failure moves earlier: EnterWorktree creation itself is
blocked (.git/worktrees/<name> lands in the read-only set) and the session
is left with a poisoned GIT_DIR pointing at the not-created worktree.

Both behaviors are 100% reproducible in a scripted harness (multiple runs per
config, fresh throwaway repos).

Expected

Entering a worktree mid-session must not permanently break the Bash sandbox.
Either the mount plan should treat worktrees created after warm-up as
writable (the session's own working area), or the plan should be rebuilt when
the session's working directory changes.

Mitigation found

Launching the same sessions with the settings-based sandbox instead of
the env var — --settings '{"sandbox":{"enabled":true,"allowUnsandboxedCommands":false,"failIfUnavailable":true}}'
— passes the identical sequence on both versions: worktree writes and git
commits succeed, while out-of-session writes (.gitconfig dotfile at the
worktree root, parent .claude/settings.json, sibling worktree directories)
stay denied, with zero lingering bwrap mounts. The defect therefore appears
specific to the env-var (scrub) engine's mount plan, not to the settings
engine.