[BUG] [Cowork] Scheduled-task sandboxes cannot mount Drive folder; Drive writes blocked at canonical AND Library/CloudStorage paths

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?

Cowork research preview — scheduled-task sandboxes fail to mount the user's Google Drive folder via virtiofs and cannot write to the Drive folder. Receipts, alerts, and any persistent output to the user's selected workspace folder fail. Interactive Cowork chat sessions running in the same Cowork session do NOT exhibit this issue — the failure is specific to scheduled-task sandbox spawning.

Reproduces across multiple consecutive scheduled-task fires today (2026-04-28). Survived a full Mac shutdown plus Drive Desktop config cleanup.

The asymmetry between scheduled-task sandboxes (broken) and interactive Cowork chat sandboxes (working) within the same Cowork session strongly suggests this is a scheduled-task sandbox spawning issue, not a Drive Desktop or platform-wide problem. Drive Desktop itself is healthy — uploads complete normally, interactive-session writes succeed, only scheduled-task sandboxes can't reach the mount.

Failure pattern (one or both per scheduled-task spawn):

1. mkdir .../My Drive: file exists plus stale UID carryover (e.g., uid=1223 gid=1223) from a prior sandbox — the bash workspace fails to start.

1. Drive folder writes blocked at both /Users/dv10x/My Drive/... and /Users/dv10x/Library/CloudStorage/... paths even when bash partially works. Receipt writes, alert writes, all fail.

Environment:

• Cowork research preview, latest desktop app
• macOS, Apple Silicon
• Google Drive Desktop, latest, fully synced and healthy (0 upload errors)
• User's workspace folder: /Users/dv10x/My Drive/CDA VENTURES GROUP LLC/
• Active Cowork session: interactive chat sandbox UID 1217 works fine; scheduled-task sandboxes spawn with stale UIDs (e.g., 1223) carried over from prior sessions

What Should Happen?

Scheduled-task sandboxes should mount the user's Drive folder consistently and successfully — same as interactive Cowork chat sandboxes do in the same session. Receipts and alert logs should write to the canonical Drive paths under the user's selected workspace folder. The autonomous-pipeline architecture relies on this working reliably for daily mission-critical use.

Error Messages/Logs

Pulled from today's failing scheduled-task transcripts (2026-04-28).

trm-1-web-collector first failed run (session local_e01cf409-...):
"Run captured to session outputs at outputs/web_collector_run_log_2026-04-28.txt — that is the only place this session is allowed to write."
"web_collector done: 0 of 16 receipts written (infrastructure failure — bash workspace mount RPC error AND Write blocked against connected Drive path)."

trm-1-web-collector second failed run (session local_a4cc3bb7-...):
"web_collector done: 0 of 16 receipts written to _receipts/. bash workspace mount failed (Drive folder unmountable) AND direct receipts-path Writes blocked by sandbox."

trm-1-web-collector most recent run, post-reboot (session local_1d2ca3a3-...):
"Note: bash workspace was unrecoverable this run (virtiofs mount conflict on the Drive path), so STEP 3 (coverage_validator.py) could not execute."

trm-2-chrome-collector most recent run, post-reboot (session local_0a784743-...):
"chrome_collector ABORTED: 0 receipts written. Blocking infra: workspace VM cannot mount the Drive share, and Write to the Briefings folder is blocked at both /Users/dv10x/Library/CloudStorage/... and /Users/dv10x/My Drive/...."

trm-3-email-collector most recent run, post-reboot (session local_a05f4ec8-...):
"email_collector done: 0 receipts written to _receipts/ (write+bash both blocked). imap_cimarisk=FAILED (collector_error: bash workspace mount failure — IMAP script unrunnable)."

Notable: an earlier trm-1 attempt did succeed in writing the 11 deterministic Python receipts at 17:24 UTC. So the issue is intermittent rather than permanent — some sandbox spawns succeed, most fail.

Steps to Reproduce

1. Set up a Cowork scheduled task whose prompt requires the bash sandbox to read from and write to the user's selected Drive workspace folder.
2. Trigger the scheduled task via Run-now from the Cowork sidebar (or wait for its cron to fire).
3. Observe in the resulting session transcript that the bash sandbox cannot mount the Drive folder due to "mkdir .../My Drive: file exists" + stale UID carryover, OR that Drive folder writes are blocked at both /My Drive/... and /Library/CloudStorage/... paths.
4. Open an interactive Cowork chat in the same Cowork session — confirm it CAN mount the same Drive folder and write to it. The asymmetry is the diagnostic signal.
5. Re-trigger the scheduled task multiple times — most attempts fail, occasional attempts succeed (intermittent).

Things tried that did NOT fix it:

• Full Mac shutdown and cold reboot
• Quit Cowork, Chrome, Drive Desktop completely before shutdown
• Removed problematic local folders from Drive Desktop sync (had been triggering chronic Drive upload errors on Electron app symlinks; suspected of contributing to virtiofs instability — Drive Desktop now reports 0 errors)
• Reconnected Chrome MCP

The intermittent success-then-fail pattern across consecutive scheduled-task spawns suggests a race condition during sandbox cleanup-and-spawn.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is a Cowork research preview report, not Claude Code CLI. Cowork is the latest desktop app version available via the in-app updater as of 2026-04-28.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Architectural context:

The user operates a daily mission-critical intelligence pipeline (Cima Risk, Travel Risk Management for Colombia / Andean region). 4-stage scheduled-task pipeline (trm-1-web-collector, trm-2-chrome-collector, trm-3-email-collector, trm-4-renderer) firing at 5:00 / 5:15 / 5:25 / 5:40 AM Mon-Sat El Paso time. 22-source manifest covering Colombian government feeds, ~111 RSS feeds via OPML (Crisis Group, InSight Crime, La Silla Vacía, Substacks, mainstream outlets), 6 Chrome-authenticated sources (X Lists, private Telegram, Feedly AI alerts), IMAP for the Cima Risk Workspace Gmail, Gmail MCP for the operator's personal Gmail. Persistent receipt schema with coverage validator + augmentation-artifact validator + min_items enforcement. Persistent Feedly URL deduplication index. Significant build investment (multiple full days of work) hinges on Cowork scheduled-task reliability.

User working pattern note (per operator's request to include):

In diagnosing this issue today, the operator (the user filing this report) navigated across multiple Cowork chat sessions — opening interactive chats inside Cowork sidebar entries that were originally scheduled-task chats, attempting to fix issues from within those failing sessions, and starting troubleshooting work in one chat then continuing in another. This caused user-side confusion about which session is canonical for diagnostic vs. execution. The user has asked this admission be included so engineering sees the full operating context. From a product perspective, structural improvements that would have helped: clearer guidance about session scope, persistent state more visibly carried across related chats, or a single canonical "this issue affects task X" surface that survives session boundaries.

Related existing issues found:

• #37712 [BUG] [Cowork] present_files cards not rendered + overlayfs shadow blocks write to mounted folder — appears to describe the same underlying failure mode (write-block on mounted folder). Possibly the same root cause.
• #53442 [BUG] Cowork Google Drive MCP cannot see content in any Workspace Shared Drive — same Cowork ↔ Drive integration cluster.
• #53489 [BUG] Claude Code Web interactive sessions lost all claude.ai MCP connectors ~April 23, 2026 while routines retain them — another Cowork-stability incident around the same time window.

What we need investigated:

1. Why scheduled-task sandboxes fail to mount Drive via virtiofs while interactive chat sandboxes in the same Cowork session succeed.
2. Whether "session write-protection" on scheduled-task sandboxes is intentional (and why it differs from interactive sandboxes) or a side-effect of the broken mount.
3. Whether stale UID carryover (uid=1223 gid=1223 in a freshly spawned sandbox while interactive chat is on uid=1217) indicates a sandbox-cleanup race condition in the Cowork supervisor.
4. Workarounds operators can apply now — alternative mount paths, sandbox config knobs, scheduling cadence changes.

Operator availability:

Daniel Villalva — daniel@cimarisk.com. Available for additional reproduction info, transcript exports, screen recordings, or live debugging session if helpful. Pipeline currently down pending platform fix; continuity maintained via manual recovery from interactive Cowork chats, which is not a sustainable mode of operation.