Linux sandbox creates sentinel files in working directory, polluting project tree
Resolved 💬 3 comments Opened Mar 12, 2026 by joshheyse Closed Mar 15, 2026
Description
On Linux, the Claude Code sandbox creates zero-byte read-only sentinel files directly in the project's working directory to prevent writes to sensitive paths. These files are bind-mounted and cannot be deleted (rm returns "Device or resource busy").
Files created in project root
.bash_profile .bashrc .gitconfig .gitmodules .idea .mcp.json
.profile .ripgreprc .vscode .zprofile .zshrc
HEAD refs config objects hooks
All are 0 bytes, read-only, timestamped to session start.
Problems
- Pollutes
git status— all files show as untracked, requiring.gitignoreentries in every project - Name collisions —
config,objects,hooksare common project directory/file names. Since the sentinels are bind-mounted,mkdir configor creating a file namedconfigwill fail. This blocks legitimate project use of these names. - Cannot be cleaned up —
rmfails with "Device or resource busy" even after the session ends (until the mount is released) - Not an issue on macOS — the macOS sandbox uses Apple's native
sandbox-exec(Seatbelt) which enforces restrictions at the kernel level without creating any filesystem artifacts
Expected behavior
The sandbox should enforce write restrictions without creating files in the working directory. Options:
- Use a kernel-level approach (namespaces, seccomp, eBPF) similar to how macOS uses Seatbelt
- If sentinel files are necessary, place them in a hidden directory (e.g.,
.claude/sandbox/) rather than the project root
Environment
- Platform: Linux 6.12.75
- Claude Code invoked in a git repository working directory
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗