Bug: workspace bash fails with ENOSPC on `/etc/passwd` during session-user provisioning

Preflight Checklist

• [x] I have searched existing issues 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?

Bug: workspace bash fails with ENOSPC on /etc/passwd during session-user provisioning

Summary

The Cowork-mode workspace bash tool (mcp__workspace__bash) fails on every
invocation with a host-side useradd: No space left on device error when
attempting to provision the per-session Linux user. The failure is
deterministic, persists across days, and blocks all Python execution while
leaving file tools and other MCP connectors functional.

Environment

• Client: Claude Desktop, Cowork mode
• Platform: Windows host calling into managed Linux workspace VM
• Affected tool: mcp__workspace__bash
• Unaffected tools: file Read/Write/Edit, Drive MCP, WebFetch, WebSearch,

all other connectors

Steps to reproduce

1. Open a Cowork chat session.
2. Invoke any bash command, e.g. mcp__workspace__bash(command="echo test").
3. Observe failure before the command executes.

Expected behavior

Bash returns the command's stdout/stderr, or Workspace still starting (a
known transient that clears on retry within a few seconds).

Actual behavior

Every invocation returns the following error immediately, before any user
command is executed:
bash failed on resume, create, and re-resume.
resume: RPC error -1: ensure user: useradd failed: exit status 1:
useradd: /etc/passwd.<NNNNN>: No space left on device
useradd: cannot lock /etc/passwd; try again later.
create: RPC error -1: ensure user: useradd failed: exit status 1:
useradd: /etc/passwd.<NNNNN>: No space left on device
useradd: cannot lock /etc/passwd; try again later.

The <NNNNN> suffix on /etc/passwd.<NNNNN> increments across attempts
(observed range spans thousands of consecutive integers across the failure
window), suggesting useradd is iterating PID/serial suffixes trying to
create a sibling temp file and ENOSPC'ing every time.

Frequency and duration

• First observed: ~4 days before reporting.
• Failure pattern: deterministic on every invocation since first observation.
• Total affected sessions: 6+ consecutive across the window.
• Retry intervals tested: seconds, minutes, hours, full days — no change in

error.

• Prior to first observation: bash worked normally; intermittent failures (if

any) returned Workspace still starting and cleared on retry.

Diagnostic hypothesis

The error signature is characteristic of root-filesystem ENOSPC on the
multi-tenant workspace VM. useradd rewrites /etc/passwd atomically by
writing a temp file in the same directory (/etc/passwd.<pid>) and renaming
into place; that temp-write ENOSPCs when the partition holding /etc is
full.

Plausible contributors (any combination):

1. Accumulated stale session users. Each Cowork bash session provisions a

Linux user; if cleanup hooks aren't running (or are running but failing),
/etc/passwd and /home/<user>/ directories grow unbounded over time.

1. Inode exhaustion rather than byte-space (df -h clean / df -i full)

if the cleanup misses small home-dir contents.

1. Log accumulation in /var/log or /var/crash filling the root

partition.

1. Undersized root partition that crossed a threshold around the first

observation date.

The deterministic, multi-day persistence rules out a transient. The
incrementing suffix rules out a stale lock (which would loop on a fixed name).

Diagnostic asks for whoever can access the workspace VM

df -h                              # confirm which partition is at 100%
df -i                              # inode exhaustion check
du -sh /etc /var/log /home /tmp    # locate the space consumer
wc -l /etc/passwd                  # session-user accumulation check
ls -la /etc/passwd.* 2>/dev/null | wc -l  # stale temp files
systemctl status <session-cleanup-service>  # whatever cleans sessions

Suggested remediation paths

Any one of the following, whichever is fastest:

• (a) Reclaim space on the workspace VM root partition: clear stale

session users, rotate/prune logs, prune crash dumps, GC home directories.

• (b) Resize/expand the workspace VM root partition.
• (c) Rebuild the VM from scratch. The Cowork workspace appears to hold

no user-persistent state — user data lives in mounted folders and the
scratchpad, both of which are external. A fresh VM should restore service
without data loss to any tenant.

• (d) Fix the underlying session-cleanup process if root cause is

accumulation of stale tenants — to prevent recurrence.

Workarounds tried (client-side)

• Retry on multiple cadences (seconds → days): no effect, deterministic

failure.

• Starting fresh Cowork chat sessions: same error (bash backend appears

shared/persistent across the user's sessions, not per-chat).

• Operations on other tools between bash attempts: no effect.

Impact

Any Cowork workflow that requires Python or shell execution (data analysis,
package installs, script runs, anything pandas/numpy/scipy/pyarrow) is
fully blocked. File-tool-only workflows (document editing, Drive operations,
research via WebFetch) continue to function. Multi-day workstreams that
mix design with execution can continue on the design side but accumulate
queued execution tasks.

Additional context

The failure is at the host's session-user provisioning layer, occurring
before any user command runs. Client-side variables — cwd, env, command
text, package state, command timeout — are all irrelevant.

This report has been refined across multiple support exchanges and contains
the full diagnostic detail accumulated to date. Happy to provide additional
logs or run any client-side diagnostic that would help.

What Should Happen?

Claude cowork should execute without error

Error Messages/Logs

Every invocation returns the following error immediately, before any user
command is executed:
bash failed on resume, create, and re-resume.
resume: RPC error -1: ensure user: useradd failed: exit status 1:
useradd: /etc/passwd.<NNNNN>: No space left on device
useradd: cannot lock /etc/passwd; try again later.
create: RPC error -1: ensure user: useradd failed: exit status 1:
useradd: /etc/passwd.<NNNNN>: No space left on device
useradd: cannot lock /etc/passwd; try again later.

Steps to Reproduce

I have retested and rerun per above multiple times using different steps

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

unknown... using claude cowork

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_