Sandbox materializes & persists .git/config.lock in linked worktrees, blocking git config writes

I have the same workflow, WSL2 + multiple worktrees, and running into the same issue where claude will then refuse to go back to sandbox mode because of config.lock issues

This is not limited to linked worktrees — I hit exactly this in an ordinary, non-worktree repository, and the mechanism you describe is the right one.

Environment: Claude Code 2.1.232, Ubuntu on WSL2 (kernel 6.18.33.2-microsoft-standard-WSL2), bubblewrap sandbox enabled via managed settings. The repo is on a dedicated ext4 VHD attached to the WSL2 VM, not a Windows drvfs mount, so these are ordinary Linux filesystem semantics.

The repository has .git/ as a real directory (not a gitdir: pointer file), and .git/worktrees does not exist — no linked worktree has ever been created from it. It still gets both files:

$ ls -la .git/config.lock .git/config.worktree
-r--r--r-- 1 user user 0 Aug 14 15:15 .git/config.lock
-r--r--r-- 1 user user 0 Aug 14 15:15 .git/config.worktree

It broke an ordinary push run by hand in a normal shell, with Claude Code not running:

$ git push --set-upstream origin my-branch
 * [new branch]      my-branch -> my-branch
error: could not lock config file .git/config: File exists
error: unable to write upstream branch configuration

The push succeeded; only the local config write failed.

On why it isn't worktree-specific: config.lock is added to the scrub list conditionally on .git/config existing as a regular file, which is true of every normal repo —

if (ut === "config" && Qt.isFile())
  if (U) t.bareGitRepoScrubPaths.push(resolve(Fe, "config.lock"));
  else   d.push(resolve(Fe, "config.lock"));

Two details that may help narrow the fix:

• Only missing paths get created. .git/config (771 bytes) and .git/info/exclude (541 bytes) were both left intact and unmodified, and .git/config.worktree.lock, .git/commondir, .git/modules, .git/worktrees were never created. So nothing is clobbered — the defect really is just the missing unlink on teardown.
• They regenerate, on the next sandboxed Bash call from a session rooted in that repo, so cleanup only sticks once the session has ended.

Your second proposed fix — when a denied path doesn't exist, deny cleanly rather than creating a persistent placeholder — looks like the right general shape to me, and would cover the repo-root dotfile placeholders in #83497 and #81602 at the same time.

Worth adding for anyone else hunting this: verify with ls, not git status. Several of the placeholder names are commonly gitignored, which hides them completely. That is exactly why this went unnoticed here for two days — a global ignore file had been set up to silence the untracked-file noise, and git status was then used as evidence that nothing was being written to the repo.

Confirmed — reproduced on 2.1.233 (Linux, bubblewrap sandbox), regression since a security hardening in a late-June 2026 release (~v2.1.193).

What we observed, matching your report exactly: in a linked worktree with the sandbox enabled, each sandboxed Bash command creates a 0-byte, read-only .git/config.lock in the shared .git on the host (it's the mount target for the read-only protection of the config file family, and to git its existence means "a config write is in progress"). While it exists, git config writes fail with error: could not lock config file …: File exists — inside the sandbox and in every other shell sharing that .git.

On a clean exit the file is cleaned up, but an unclean exit (crash, kill, WSL shutdown) or a long-running sandboxed command strands it, and it then blocks all config writes in every worktree until removed by hand — and is re-materialized by each sandboxed command.

A fix that stops creating the lock file on Linux while keeping the .git/config write protection is in review. Until it ships, deleting <main-repo>/.git/config.lock is safe whenever no real git config write is in flight.

🤖 Generated with Claude Code

Two measurements from a native Linux box, in case they bear on the scope of the fix in review.

The materialisation is not specific to config.lock. On 2.1.238 (Debian 13, bubblewrap 0.11.0) the sandbox
creates the same 0-byte, mode 444 mount target for every protected path that is missing, at every ancestor of
the working directory. This box carries 60 of them: .claude/settings.json, .mcp.json, .git/config,
.git/worktrees, and home dotfile names such as .bashrc, .gitconfig and .idea sitting at project level.

The clean-exit cleanup breaks a concurrent session. The confirmation above reads the clean exit as the safe
path. The cleanup counter is per process, so process A's tidy exit unlinks a placeholder that process B has
already read into its bwrap argument list. B's next call then dies with
bwrap: Can't find source path <path>, and that Bash command never runs. Cleaning up sooner, or more often,
makes this failure more frequent.

I traced the mechanism, the two code fragments and three measured failures here:
https://github.com/anthropics/claude-code/issues/81602#issuecomment-5365483445

Would you check whether the fix in review reaches the general case? If it drops config.lock from the
protected set alone, both effects above stay.