Sandbox masking placeholders are created in the project working directory instead of $HOME, appearing as untracked files on every Bash command

Summary

With the Bash sandbox enabled on Linux, every sandboxed command creates nine zero-byte dotfiles at the root of the current working directory, then removes them when the command finishes. When the working directory is a git repository, these appear as untracked files for the duration of each command, so the SCM view and any file watcher see them repeatedly appear and disappear.

The files are the sandbox's masking placeholders for shell-init and config paths. They are being created relative to the working directory instead of $HOME.

Environment

• Claude Code 2.1.220 (VS Code extension anthropic.claude-code)
• Linux (Ubuntu), bubblewrap 0.11.1, @anthropic-ai/sandbox-runtime 0.0.67
• Working directory: a git worktree
• sandbox.enabled: true, allowUnsandboxedCommands: false

Steps to reproduce

1. Enable the Bash sandbox on Linux.
2. Open a git repository as the working directory.
3. Run any sandboxed Bash command.
4. Watch the repository root, or git status, while the command runs.

Observed

Nine files appear at the repository root, all zero bytes and mode 444:

-r--r--r-- 1 glen glen 0  .bash_profile
-r--r--r-- 1 glen glen 0  .bashrc
-r--r--r-- 1 glen glen 0  .gitconfig
-r--r--r-- 1 glen glen 0  .gitmodules
-r--r--r-- 1 glen glen 0  .idea
-r--r--r-- 1 glen glen 0  .profile
-r--r--r-- 1 glen glen 0  .ripgreprc
-r--r--r-- 1 glen glen 0  .zprofile
-r--r--r-- 1 glen glen 0  .zshrc

git status reports them as untracked:

?? .bash_profile
?? .bashrc
?? .gitconfig
?? .gitmodules
?? .idea
?? .profile
?? .ripgreprc
?? .zprofile
?? .zshrc

They are removed when the command completes, so the SCM view flickers between counts as commands run. They are visible to host-side tooling while they exist — this was first noticed via the VS Code Source Control panel, not from inside the sandbox.

Evidence that this is a path-resolution issue

.zshenv and .zlogin are absent from the list above. Those two are declared in user settings as sandbox.filesystem.denyWrite: ["~/.zshenv", "~/.zprofile", "~/.zlogin"], i.e. with a ~/ prefix, and they resolve to $HOME correctly.

The nine that do appear correspond to the built-in shell-init/config protections rather than to anything declared in settings. Per the documented path-prefix rules, a path with no prefix resolves relative to the project root — which matches the observed behavior exactly.

The home-directory paths remain correctly protected, so this is the placeholder creation being misplaced rather than protection being lost:

/home/glen/.zshrc        denied (read-only file system)
/home/glen/.zshenv       denied
/home/glen/.bashrc       denied
/home/glen/.gitconfig    denied

Expected

Masking placeholders should be created outside the project tree — e.g. in the session temp directory — and the built-in deny paths for home dotfiles should resolve against $HOME rather than the working directory. Running a Bash command should not create files inside the user's repository.

Impact

• Files are created inside the user's repository as a side effect of running any Bash command, and are visible to host-side tools while they exist.
• Continuous SCM and file-watcher churn in any repo used with the sandbox enabled.
• A git add -A (or any tooling that stages broadly) issued while a sandboxed command is in flight can pick them up.
• A zero-byte .gitmodules at a repository root can shadow a tracked one. Harmless in a repo with no submodules; in a repo that uses them, git submodule operations would see an empty file for the duration of each command.
• A zero-byte file named .idea conflicts with the JetBrains project directory of the same name.

---

_Drafted by Claude (Anthropic AI assistant)._