Linux sandbox leaves a read-only .git/config.lock on the host, breaking git config writes in sibling worktrees

Environment

• Claude Code 2.1.296, Linux (Ubuntu, kernel 6.8), sandbox.enabled: true (bubblewrap)
• Several Claude Code sessions run at once in different git worktree checkouts of one repository (orchestrated by T3 Code)

What happens

For each sandboxed Bash command, bubblewrap gets a deny mount for <repo>/.git/config.lock. To create the mount target, an empty read-only file (-r--r--r--, 0 bytes) is created on the host at <common-git-dir>/config.lock, and it stays there for the whole duration of the command.

All worktrees share the common git dir, so while any session runs a sandboxed command, every git config write in the repository fails, including those from processes outside any sandbox:

error: could not lock config file .git/config
warning: update of config-file failed

Long commands make it constant. In our case a command waiting minutes on a flock build queue kept the lock the whole time, and other sessions start new commands all the time.

Impact

• git worktree add -b <branch> followed by git config branch.<branch>.* fails, so tools that provision worktrees fail. Retrying then fails with "branch already exists".
• git branch -D cannot remove the branch config section.

Expected

Protecting .git/config from writes inside the sandbox should not create a lock file visible to processes outside it. For example, the placeholder could live outside the repository, or config.lock could be protected without a host-side mount target. Otherwise sibling worktrees and other tools see the repository config as permanently locked.

Workaround

sandbox.enabled: false.