anthropics / anthropics/claude-code
Bash tool fails on every command: bwrap can't mkdir /run/containerd/containerd.sock (Permission denied)
- Lingua principale
- Python
- Stelle
- 145k
- Fork
- 23.1k
- Metriche di merge delle PR
- Metriche PR in attesa
Descrizione
## Bug report
**Claude Code version:** 2.1.266 (confirmed up to date via `claude update`)
**OS:** Debian GNU/Linux 13 (trixie), kernel 6.1.0-18-amd64, x86_64
**Description**
Every Bash tool invocation fails, regardless of whether the project/user-level sandbox is enabled or disabled. The underlying `bwrap` (bubblewrap) call attempts to create `/run/containerd/containerd.sock` and fails with a permission error, because `/run/containerd` is owned by `root:root` with mode `drwx--x--x` (no write access for non-root users). This happens even with `dangerouslyDisableSandbox: true` on the tool call, and even with `"sandbox": {"enabled": false}` set in `.claude/settings.local.json`.
**Steps to reproduce**
1. On a Debian (or any Linux) host with `containerd` installed and running as a systemd service (socket at `/run/containerd/containerd.sock`, owned `root:root`, mode `drwx--x--x` on the parent dir).
2. Run any Bash tool command in Claude Code, e.g. `echo test`.
3. Command fails immediately with no stdout, exit code 1.
**Expected behavior**
The Bash tool executes the command normally (either sandboxed per the configured policy, or unsandboxed if `sandbox.enabled` is `false` / `dangerouslyDisableSandbox: true` is passed).
**Actual behavior**
Every command fails with:
```
bwrap: Can't mkdir parents for /run/containerd/containerd.sock: Permission denied
```
This reproduces even when:
- `dangerouslyDisableSandbox: true` is passed on the tool call.
- `.claude/settings.local.json` in the project has:
```json
{ "sandbox": { "enabled": false } }
```
- Global `~/.claude/settings.json` has no sandbox-related configuration at all.
`/sandbox` slash command reports "○ Sandbox disabled", but the underlying Bash execution still shells out through `bwrap` and still attempts the same mount/mkdir, so the failure persists.
**Environment details**
- `uname -a`: `Linux debian 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux`
- `/etc/os-release`: Debian GNU/Linux 13 (trixie)
- User: uid=1000(aldosierra), groups include `docker` (124) but not root.
- `containerd` is installed and running as a systemd service, actively used for Docker on this host (unrelated to Claude Code).
- `/run/containerd` permissions: `drwx--x--x root root`
- `/run/containerd/containerd.sock` permissions: `srw-rw---- root root`
**Hypothesis**
The Bash tool's sandbox launcher appears to unconditionally attempt to bind-mount or create `/run/containerd/containerd.sock` inside the bwrap sandbox namespace (likely so sandboxed processes can reach a container runtime), without first checking write permissions on the socket's parent directory, and without honoring the `sandbox.enabled: false` setting or `dangerouslyDisableSandbox: true` to skip this step entirely.
**Impact**
Every Bash tool call fails on this machine — Claude Code is unable to run any shell command at all.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Start by reproducing the failure with the Bash tool on Debian using the reported /run/containerd/containerd.sock permissions, then compare behavior with sandbox.enabled false and dangerouslyDisableSandbox true. Trace the bwrap launch path and the settings handling; done means Bash commands run successfully and disabled sandbox settings no longer trigger the failing socket setup.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- bash, debian, docker, linux
- Ambito
- cli, operating-systems, security
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Attiva
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 48/100