[BUG] Scheduled tasks — recurring sandbox provisioning failure

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?

Summary: My scheduled Cowork task (a daily Instagram posting automation, "basic-banter-daily-post") failed at startup because the bash sandbox never finished provisioning. This is the second occurrence of the identical failure signature — first logged 2026-08-20, again today (2026-09-10).

Exact error text from today's run:
"bash failed on resume, create, and re-resume. resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/.../uploads as uploads: source path is under Plan9 share 'c' which is not mounted; create: RPC error -1: ensure user: user eager-wonderful-dirac already exists unexpectedly: uid=1257 gid=1257"

What I observed: Every bash tool call failed identically across 3 consecutive attempts within the same session — not a permission issue on a specific path, but a full boot-level failure (mount + duplicate-user error together). This suggests the sandbox environment itself was left partially initialized rather than freshly provisioned. No shell command of any kind could execute, so the task's core logic (a mandatory programmatic duplicate-check step) could never run.

Impact: The task correctly detected this as a hard blocker, stopped after 3 retries rather than looping indefinitely or falling back to a manual/unsafe workaround, and sent me a failure notification email with full diagnostics. Nothing was posted, staged, or modified — the failure was handled safely. I'm reporting this because it's an infra-level issue, not something fixable from my end (I confirmed the scheduled task's own configuration/instructions weren't the cause).

Frequency: 2 occurrences so far with the same error signature, both on scheduled (not live/interactive) task runs.

Ask: Please look into why sandbox provisioning intermittently fails to mount connected folders and leaves a stale/duplicate user on scheduled task startup. Happy to share full session logs if useful.

What Should Happen?

When a scheduled task starts, the sandbox provisioning step should either (a) succeed cleanly with all connected folders mounted before any tool calls are attempted, or (b) if provisioning itself fails, retry with a genuinely fresh environment (not reuse a partially-initialized one that already has a stale user/uid and a broken mount) before handing control to the task. Ideally this retry-with-fresh-environment logic would happen at the infrastructure level, invisibly, rather than surfacing as a hard failure the task has to detect and report on its own. If a clean boot still can't be achieved after automatic retries, the task should fail fast with a clear, structured error (as it did here) rather than partially execute in a broken environment.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce (note: failure is intermittent, not deterministic — these are the exact steps that triggered it in this session; the same steps may succeed on a clean provision):

Have an existing scheduled Cowork task configured (a recurring automation with local folder connections — in my case, three connected working directories: two Google Drive–synced folders and one automation folder containing a credentials.json file).
Let the scheduled task fire automatically at its configured time (mine runs daily). Note: I did not manually start this session — it was triggered by the scheduler, which is relevant since manually-started chat sessions appear to provision differently/more reliably.
As the very first action in the session, issue any bash tool call — even a no-op is sufficient. Minimal example used:
mcp__workspace__bash({ command: "echo test" })
Observe the response. Expected: command executes, returns "test". Actual (what occurred): the call fails immediately with a compound RPC error before any command logic runs:
"bash failed on resume, create, and re-resume. resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/.../uploads as uploads: source path is under Plan9 share 'c' which is not mounted; create: RPC error -1: ensure user: user eager-wonderful-dirac already exists unexpectedly: uid=1257 gid=1257"
Retry the identical no-op command (echo test) 2 more times in the same session, roughly 10-20 seconds apart, with no other action in between.
Observe: all 3 attempts return the identical error text, with only the sandbox-internal identifiers (uid/gid, sandbox name) staying constant and no change in failure mode between attempts — confirming this isn't a transient race that resolves with a short wait.

Minimal reproducible unit: There's no user-controlled code that reproduces this — it fails before any script, file read, or task logic executes. The smallest possible trigger is any Cowork session (chat or scheduled) whose first tool call is a bash/shell invocation; the failure originates in Anthropic's sandbox provisioning layer, not in anything the user's task, prompt, or connected files contain. This can't be isolated further from the user's side since there's no visibility into the provisioning step itself.

Environment details for the report:

Surface: Claude Desktop for Windows, Cowork mode, scheduled task (not a live/manual chat session)
Connected folders: 3 working directories (2 Google Drive–mirrored local folders, 1 local automation folder)
Model: claude-sonnet-5
Session type: cloud-run scheduled task, no device/app needing to stay open

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.267

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_