Sandbox stubs break `git add .` and are indistinguishable from real repo state to the agent

Summary

With the sandbox enabled, Claude Code mounts /dev/null over protected paths that don't exist in the project root (.zshrc, .mcp.json, .claude/hooks, …). Two consequences hit the agent, not just the user's git status:

1. git add . fails outright inside the sandbox — it doesn't skip the stubs, it aborts with exit 128 and stages nothing, including legitimate files.
2. git status reports ~19 phantom untracked files that the model has no way to identify as sandbox artifacts, so it reasons about them as real repository state.

The mounting mechanism is tracked in anthropic-experimental/sandbox-runtime#139 (open since February). This issue is about the Claude Code side: the agent is given no signal, and the behaviour is undocumented. Full cross-side measurements are in my comment there: https://github.com/anthropic-experimental/sandbox-runtime/issues/139#issuecomment-5000362125

Not a duplicate of #29316. That one is the worktree variant (.git is a file → 0-byte stubs land in the project root, breaking git rev-list HEAD with "ambiguous argument"), reported fixed in 2.1.78. This reproduces in a regular clone on 2.1.212, and the artifacts are character devices rather than 0-byte files. #29316 is locked, and kosei-w90607's comment there reporting exactly this was told to open a separate issue — this is that issue.

Reproduction

Environment: Claude Code 2.1.212, Linux, bubblewrap, sandbox enabled in auto-allow mode, ordinary git clone (no worktree), no user denyRead rules.

1. Launch Claude Code from a git repository whose root has no .zshrc / .mcp.json / .claude/hooks.
2. Ask Claude to run git status --short. Observe ~19 untracked paths that do not exist outside the sandbox.
3. Ask Claude to run git add -n .:

error: .bash_profile: can only add regular files, symbolic links or git-directories
fatal: adding files failed
(exit 128)

1. Ask Claude to run ls -la .zshrc → crw-rw-rw- 1 nobody nobody 1, 3 (a /dev/null character device).

Scope, measured: the stub set exists in the launch directory only — zero stubs in a permissions.additionalDirectories path (writable, git commit works there) and zero in a nested repo inside the launch tree. A stub appears only where a protected path is missing; existing paths are --ro-binded and leave no artifact.

Expected behaviour

• git add . works in a sandboxed repository.
• The agent can tell an environment artifact from real repository state.

Why this is worth fixing on the Claude Code side

Sandboxing is a good feature and I run it permanently. But its artifacts are invisible as artifacts to the model working inside them. git status is one of the most common things an agent runs, and there is nothing in the environment saying "these 19 paths are mine, ignore them". Observed over a single session:

• The agent's natural "fix" damages the user's repo. Faced with untracked shell config, the obvious suggestion is "shall I add these to .gitignore?" — writing a permanent list of one namespace's mount points into the repo. For public dotfiles repos that publishes noise about a sandbox nobody else can see.
• Every session re-derives the same explanation, at real time and token cost, because nothing carries it across sessions.
• The model documents falsehoods confidently. My own notes accumulated three claims that later measurement refuted ("they don't exist outside the mount namespace", "every writable repo gets stubs", "git add . skips them"). Each was plausible from one vantage point; all were wrong.
• A dangerous inversion in dotfiles repos, where .zshrc / .bashrc / .gitconfig are the tracked product. An agent taught to dismiss those filenames as sandbox noise will wave away real changes to them.
• git add . breaking is a plain functional regression for any agent workflow that stages before committing. The workaround (always stage explicit paths) is only discoverable by hitting the error.

None of it is documented: https://code.claude.com/docs/en/sandboxing never mentions stub files, protected-path artifacts, or the git status noise — so every user and every agent rediscovers it.

Suggested fixes, in order of preference

1. Don't materialize mount targets inside the working tree (the root fix; sandbox-runtime#139).
2. Tell the model. Expose the stub paths to sandboxed commands in a documented, machine-readable form — an env var, or a system-reminder Claude Code already knows how to inject. This is cheap and removes the entire class of surprise even if the mounts stay.
3. Hide them from git inside the namespace — e.g. append the stub paths to .git/info/exclude within the sandbox (local, untracked, vanishes with the mount) rather than leaving users to gitignore mount points. This would also restore git add ..
4. Document the behaviour on the sandboxing page, including that the same stub is a character device inside the sandbox and a 0-byte regular file on the host — the confusion that has kept sandbox-runtime#139's two camps talking past each other for five months.