## Bug Description All Bash tool calls fail when sandbox is enabled, with the error: ``` bwrap: execvp /bin/bash: No such file or directory ``` ## Environment - **Claude Code**: 2.1.89 - **OS**: Ubuntu 24.04.4 LTS (Noble Numbat) - **Kernel**: 6.8.0-106-generic x86_64 - **bubblewrap**: 0.9.0 - **bash**: `/bin/bash` exists, ELF 64-bit LSB pie executable ## Sandbox config (settings.json) ```json "sandbox": { "enabled": true, "filesystem": { "denyRead": ["/"], "allowRead": [".", "~

Sandbox fails with "bwrap: execvp /bin/bash: No such file or directory" on Ubuntu 24.04

Status Closed — not planned

Reported on v2.1.89

Maintainer reply None cached

Activity 8 comments · opened Apr 1, 2026 · closed Jun 4, 2026

Bug Description

All Bash tool calls fail when sandbox is enabled, with the error:

bwrap: execvp /bin/bash: No such file or directory

Environment

Claude Code: 2.1.89
OS: Ubuntu 24.04.4 LTS (Noble Numbat)
Kernel: 6.8.0-106-generic x86_64
bubblewrap: 0.9.0
bash: /bin/bash exists, ELF 64-bit LSB pie executable

Sandbox config (settings.json)

"sandbox": {
  "enabled": true,
  "filesystem": {
    "denyRead": ["/"],
    "allowRead": [".", "~/.claude", "$TMPDIR", "/tmp/build", "~/go/pkg/mod", "/usr", "/lib", "/lib64", "/etc", "/bin", "/sbin", "/proc", "/dev"]
  }
}

Reproduction

Enable sandbox with the config above on Ubuntu 24.04 with bubblewrap 0.9.0
Any Bash tool call fails with bwrap: execvp /bin/bash: No such file or directory

Observations

/bin/bash exists and is a valid binary (file /bin/bash → ELF 64-bit LSB pie executable)
Running bwrap manually with --ro-bind /bin /bin works fine: bwrap --ro-bind /bin /bin --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --proc /proc --dev /dev /bin/bash -c "echo works" → success
Disabling sandbox ("enabled": false) or using dangerouslyDisableSandbox: true works around the issue

Workaround

Disable sandbox in settings or approve dangerouslyDisableSandbox per command.

View original on GitHub ↗

8 Comments

xbzzoo · 5 months ago

So frustrated with lack of support on claude app code I'll join anything. 🙂

qiuchuy · 4 months ago

I’m running into the same issue when trying to restrict Claude Code so it can only read from certain directories in this way. I don’t think simply disabling the sandbox is the right solution, since that defeats the purpose of the restriction. Are there any updates on this issue, or has anyone found a workaround for implementing this properly?

Lyshc-cgc · 4 months ago

same issue! although i use zsh.

arkadiuszlewicki · 4 months ago

@claude
The issue occurs on systems using a merged /usr layout (e.g. Ubuntu 24.04+), where /bin, /lib, /lib64, and /sbin are symlinks pointing to their /usr counterparts:

/bin -> usr/bin
/lib -> usr/lib
/lib64 -> usr/lib64
/sbin -> usr/sbin

Claude Code builds the sandbox in two steps:

Mounts the entire host filesystem into the sandbox:

--ro-bind / /

Blinds specific directories by overlaying them with empty tmpfs:

--tmpfs /usr
--tmpfs /bin
--tmpfs /lib64

The problem is that --tmpfs /usr wipes out /usr/bin, /usr/lib, etc. inside the sandbox. Since /bin is a symlink to usr/bin, it now points to an empty directory. When bwrap then tries to execute /bin/bash inside the sandbox, it fails with:
bwrap: execvp /bin/bash: No such file or directory

Claude Code assumes these paths are real directories that can be independently overlaid. This assumption breaks on merged /usr systems - wiping /usr silently breaks all of them.

The fix should be on Claude Code's side: before issuing --tmpfs for a path, check whether it is a symlink or whether any top-level symlinks resolve through it, and handle those cases accordingly.

Workaround which worked for me but I don't recommend: intercept bwrap calls using a wrapper script placed at /usr/bin/bwrap (with the original binary moved aside). The wrapper inspects each argument before passing it to the real bwrap, and skips --tmpfs for paths that are symlinks or known merged-/usr paths (/usr, /bin, /lib, /lib64, /sbin and their .usr-is-merged variants). This prevents Claude Code from wiping out directories that are critical for bash to run inside the sandbox. This is not an ideal solution as it may cause issues when updating bwrap via apt.

vks · 4 months ago

Same root cause on CachyOS (Arch, /usr-merged) with Claude Code 2.1.119 and bubblewrap 0.11.2. The surface is just a bit earlier than the OP: failure at mount setup, not execvp:

bwrap: Can't mount tmpfs on /newroot/bin: No such file or directory

bwrap argv (captured via wrapper) shows --tmpfs /usr running before --tmpfs /bin. Once /usr is wiped, /bin (symlink → /usr/bin) has no target, so bwrap can't even create the mount point.

Only workaround is disabling the sandbox. A fix that skips --tmpfs for symlinked paths (or detects merged-/usr) would cover such distros.

alexismanin · 3 months ago

Same root cause on CachyOS (Arch, /usr-merged) with Claude Code 2.1.119 and bubblewrap 0.11.2. The surface is just a bit earlier than the OP: failure at mount setup, not execvp: `` bwrap: Can't mount tmpfs on /newroot/bin: No such file or directory ` bwrap argv (captured via wrapper) shows --tmpfs /usr running before --tmpfs /bin. Once /usr is wiped, /bin (symlink → /usr/bin) has no target, so bwrap can't even create the mount point. Only workaround is disabling the sandbox. A fix that skips --tmpfs for symlinked paths (or detects merged-/usr`) would cover such distros.

Reproduced the exact same error on Fedora 43, trying to setup sandboxing for Claude code. Disabled sandboxing for now.

github-actions[bot] · 2 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

c-seeger · 2 months ago

wtf closed by bot?