claude-code - 💡(How to fix) Fix Sandbox bind-mounts of nonexistent deny-listed paths appear as untracked files in git status [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54232Fetched 2026-04-29 06:32:45
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
0
Author
Timeline (top)
labeled ×4commented ×2closed ×1mentioned ×1

On Linux, the Claude Code sandbox uses bind mounts to enforce filesystem deny lists. When a deny-listed path (e.g. .gitmodules, .env, .netrc, .npmrc, id_rsa, id_ed25519) does not exist in the user's repository, the sandbox still creates a phantom bind mount at that path. This pollutes git status with untracked entries that did not exist before the session.

Root Cause

On Linux, the Claude Code sandbox uses bind mounts to enforce filesystem deny lists. When a deny-listed path (e.g. .gitmodules, .env, .netrc, .npmrc, id_rsa, id_ed25519) does not exist in the user's repository, the sandbox still creates a phantom bind mount at that path. This pollutes git status with untracked entries that did not exist before the session.

Fix Action

Fix / Workaround

  • git status is no longer clean across sessions, making diff review noisier.
  • git add -A / git add . could accidentally stage these phantom paths.
  • Names like .gitmodules collide with real git semantics, so a repo-global .gitignore entry is risky.
  • The only workaround is per-repo .git/info/exclude, which each user must maintain manually.

Current workaround

Code Example

?? .gitmodules

---

udev /path/to/repo/.gitmodules devtmpfs ro,nosuid,nodev,relatime,...,mode=755 0 0

---

.gitmodules type=character special file mode=666 major=1 minor=3

---

printf '%s\n' '.gitmodules' >> .git/info/exclude
RAW_BUFFERClick to expand / collapse

Summary

On Linux, the Claude Code sandbox uses bind mounts to enforce filesystem deny lists. When a deny-listed path (e.g. .gitmodules, .env, .netrc, .npmrc, id_rsa, id_ed25519) does not exist in the user's repository, the sandbox still creates a phantom bind mount at that path. This pollutes git status with untracked entries that did not exist before the session.

Environment

  • OS: Linux 6.17.0-1014-nvidia
  • Shell: bash
  • Sandbox: enabled (default)

Reproduction

  1. Open a git repository that does not contain a .gitmodules file (no submodules).
  2. Start a Claude Code session with the sandbox enabled.
  3. Run git status.

Expected: clean working tree. Actual:

?? .gitmodules

Inspecting /proc/self/mounts confirms the phantom mount:

udev /path/to/repo/.gitmodules devtmpfs ro,nosuid,nodev,relatime,...,mode=755 0 0

stat shows it as a character device matching /dev/null (major=1, minor=3):

.gitmodules type=character special file mode=666 major=1 minor=3

The same pattern occurs for every entry in read.denyOnly whose path does not exist in the repo (.env, .envrc, .netrc, .npmrc, id_rsa, id_ed25519, etc.).

Impact

  • git status is no longer clean across sessions, making diff review noisier.
  • git add -A / git add . could accidentally stage these phantom paths.
  • Names like .gitmodules collide with real git semantics, so a repo-global .gitignore entry is risky.
  • The only workaround is per-repo .git/info/exclude, which each user must maintain manually.

Current workaround

printf '%s\n' '.gitmodules' >> .git/info/exclude

Documented configuration reviewed

The documented sandbox keys (sandbox.filesystem.allowWrite / denyWrite / allowRead / denyRead) control what Claude Code can access, not which host paths get bind-mounted. There appears to be no documented setting to suppress mounts for nonexistent deny-listed paths.

Feature request

Provide an officially supported way to prevent phantom mounts from polluting the working tree. Possible designs:

  1. Skip-if-missing: only bind-mount deny-listed paths when they already exist on the host. Phantom mounts add no security value when the path is absent — there is nothing to protect.
  2. Settings flag: e.g. sandbox.filesystem.skipMissingMounts: true.
  3. Auto-manage .git/info/exclude: optionally append phantom mount paths to .git/info/exclude on session start.

Option 1 seems cleanest and likely a no-op for security since bind-mounting /dev/null over a nonexistent path adds no protection beyond denyRead enforcement at the syscall layer.

Additional context

This was investigated during a session where .gitmodules consistently appeared in git status despite the repository having no submodules.

extent analysis

TL;DR

The most likely fix is to implement a "skip-if-missing" feature to prevent bind-mounting deny-listed paths that do not exist in the repository.

Guidance

  • Investigate the sandbox configuration to determine if there is an existing setting that can be used to suppress mounts for nonexistent deny-listed paths.
  • Consider implementing a "skip-if-missing" feature that only bind-mounts deny-listed paths when they already exist on the host.
  • As a temporary workaround, use the printf command to append deny-listed paths to .git/info/exclude, as shown in the current workaround.
  • Review the documented sandbox keys (sandbox.filesystem.allowWrite / denyWrite / allowRead / denyRead) to understand their limitations in controlling bind mounts.

Example

printf '%s\n' '.gitmodules' >> .git/info/exclude

This command appends .gitmodules to .git/info/exclude, preventing it from appearing in git status.

Notes

The "skip-if-missing" feature seems to be the cleanest solution, as it would prevent phantom mounts from polluting the working tree without compromising security. However, this would require changes to the sandbox implementation.

Recommendation

Apply the workaround by appending deny-listed paths to .git/info/exclude until a more permanent solution, such as the "skip-if-missing" feature, can be implemented. This is because the workaround is a temporary fix that can mitigate the issue, but a more robust solution is needed to fully address the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Sandbox bind-mounts of nonexistent deny-listed paths appear as untracked files in git status [2 comments, 2 participants]