anthropics / anthropics/claude-code

Bash tool fails on every command: bwrap can't mkdir /run/containerd/containerd.sock (Permission denied)

オープン
#93,144 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る
area:bash area:sandbox bug has repro platform:linux
主要言語
Python
スター
145k
フォーク
23.1k
PR マージ指標
PR 指標を取得中

説明

## 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.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
bash, debian, docker, linux
領域
cli, operating-systems, security
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。