anthropics / anthropics/claude-code

[BUG]

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

説明

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Every call to the workspace bash tool in Cowork mode fails to provision the Linux
sandbox. The sandbox user cannot be created, so no shell command can run at all.

The failure is total and immediate — it is not a timeout, a permissions prompt, or
a failed command inside the sandbox. The container never comes up.

Full error text, returned identically on every attempt:

bash failed on resume, create, and re-resume.

resume: RPC error -1: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/sweet-great-hypatia
create: RPC error -1: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/sweet-great-hypatia

Attempted 4 times across ~5 minutes, including a trivial echo alive with no
filesystem access. Identical failure each time.

Scope — the rest of the session was healthy. This is isolated to the bash
sandbox, not to file access generally:


Capability | Result
-- | --
mcp__workspace__bash (any command) | FAILS — every call
Read (connected SharePoint folder) | works
Glob / directory listing | works
Connected-folder writes | works

So the mounted folder itself is fine and readable; only the Linux environment that
mounts it is unavailable.

Impact. This was hit during an automated scheduled task whose whole job is to
run a Python script against files in a connected folder. With bash down the task
cannot do anything at all. The failure surfaced as a tool error I could report,
but a scheduled run is unattended by definition — if the model had retried in a
loop, or treated the failure as "nothing to process", the run would have looked
successful while doing no work. Worth considering whether a sandbox-provisioning
failure should be surfaced to the user as a task-level error rather than a
per-tool-call one.

### What Should Happen?

The workspace sandbox provisions on first use and mcp__workspace__bash executes shell commands against the mounted connected folders.

### Error Messages/Logs

```shell
bash failed on resume, create, and re-resume.
resume: RPC error -1: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/sweet-great-hypatia
create: RPC error -1: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/sweet-great-hypatia
(attempt 4 of 5 since last success)

Note the "since last success" counter, which implies the provisioning step had succeeded earlier in the tool's history and then began failing.
```

### Steps to Reproduce

Open the Claude desktop app in Cowork mode on Windows 11.
Connect a folder (mine is a OneDrive/SharePoint-synced folder).
Ask Claude to run any shell command — e.g. echo alive.
Observe the useradd failed: exit status 12 error instead of command output.
Retry — fails identically every time. File tools (Read, Glob) continue to work normally throughout, confirming the folder connection itself is intact.

I have not yet established whether a specific trigger precedes it or whether the sandbox is simply failing to provision from a cold start.

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

previous version last run 9.30am

### Claude Code Version

Version 1.52386.6 (612f3f) Sep 13, 2026, 10:45 AM

### Platform

Other

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

Connected folder is OneDrive/SharePoint-synced. If the sandbox mount logic treats cloud-synced paths differently, that may be relevant — though the error is in creating the sandbox user's home directory under /sessions/, which looks unrelated to the mount.
The session identifier in the path (sweet-great-hypatia) is the per-session workspace name, included verbatim in case it helps correlate server-side logs.
Restarting the app to obtain a fresh workspace container is the obvious workaround to try; I have not yet confirmed whether it clears the fault.

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

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

評価

この issue はまだ評価されていません。

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

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