Bug: bwrap sandbox binds protected paths snapshotted at session start; deleting one mid-session breaks all later Bash

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 2 comments · opened Sep 19, 2026

Version

Claude Code 2.1.260, Linux (bubblewrap sandbox)

Steps

  1. Start a session in a directory where a protected path exists (e.g. <project>/.claude/launch.json, or a credentials file under $HOME that the sandbox deny-lists).
  2. Run any sandboxed Bash command — works.
  3. Delete or rotate that file from another process (credential rotation, config move).
  4. Run any sandboxed Bash command.

Observed

Every subsequent sandboxed command fails at setup:

bwrap: Can't get type of source /path/to/deleted-file: No such file or directory

until the file is recreated or the session is restarted. The only workaround is running unsandboxed.

Analysis

Paths that are missing at session start are tolerated (a session with several nonexistent deny-listed paths works fine), so the set of protected paths appears to be snapshotted at startup and bound on each command with a non-try bind. A path removed after the snapshot then fails hard.

Ask

Re-check existence per command, or use --ro-bind-try / equivalent for deny-listed paths so a rotated or removed file degrades to "not bound" instead of failing every command.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗