Sandbox creates 0-byte stub files that pollute git status

Summary

The sandbox denyWithinAllow enforcement creates visible 0-byte read-only stub files in the working directory. These files pollute git status with phantom untracked files and are recreated on every invocation, so deleting them is not a viable workaround.

Reproduction

1. Open Claude Code in a git repository
2. Have sandbox enabled (default)
3. Run git status

Observe untracked files like:

?? .bash_profile
?? .bashrc
?? .gitconfig
?? .gitmodules
?? .mcp.json
?? .profile
?? .ripgreprc
?? .zprofile
?? .zshrc
?? HEAD
?? config
?? hooks
?? objects
?? refs

All are 0 bytes, read-only (-r--r--r--), and share the same creation timestamp.

Details

The sandbox config includes denyWithinAllow rules for paths like:

• ~/.bashrc, ~/.zshrc, ~/.ssh, etc.
• <repo>/HEAD, <repo>/objects, <repo>/refs, <repo>/hooks, <repo>/config
• <repo>/.claude/settings.json, <repo>/.claude/skills, <repo>/.claude/agents, etc.

Instead of silently blocking writes to these paths, the sandbox creates empty read-only files at them. This causes several problems:

1. Pollutes git status with untracked files that aren't part of the project
2. Files are recreated on every session/tool invocation — deleting them is futile
3. Dotfiles created in wrong location — e.g. .bashrc is created in the repo root instead of protecting ~/.bashrc
4. Directories turned into files — .claude/agents/, .claude/commands/, .claude/skills/ become 0-byte files, which could interfere with later use of those features

Expected behavior

The sandbox should silently deny writes to protected paths without creating visible stub files in the working tree.

Environment

• Claude Code CLI
• Linux (Fedora 43, kernel 6.18.6)
• Sandbox enabled with default config