[Bug] Linux sandbox (bash) permanently fails — cloud workspace not provisioning for Windows Cowork sessions (6+ sessions affected)
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?
The isolated Linux sandbox fails to start in every Cowork session on Windows. Every bash call returns immediately: "Workspace unavailable. The isolated Linux environment failed to start." This has persisted across 6+ consecutive sessions over multiple weeks with no recovery.
What Should Happen?
The Linux sandbox should start successfully when a Cowork session begins, allowing Claude to execute bash commands, run Python scripts, and perform shell operations. Sessions should have cwd set to /sessions/<name>/mnt/ as was the case before the April 2026 app update.
Error Messages/Logs
Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly.Steps to Reproduce
- Open Claude Cowork desktop app on Windows (Microsoft Store version)
- Start any new conversation session
- Ask Claude to perform any task requiring bash/shell/Python execution
- Observe Claude calls mcp__workspace__bash
- Result: immediate failure — "Workspace unavailable. The isolated Linux environment failed to start."
- Failure is instant with no retry, no startup delay, sandbox never becomes available
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Version before Claude_1.5354.0.0_x64 (last working sessions before 29 April 2026)
Claude Code Version
Claude Cowork 1.5354.0.0 (Microsoft Store, not Claude Code CLI)
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
IMPORTANT: This bug is in Claude Cowork (desktop app), not Claude Code CLI.
KEY FINDINGS:
- Session cwd format changed after app update:
- BEFORE (working): /sessions/<name>/mnt/
- AFTER (broken): C:\Users\NKB.PRBNS.2111.0025\AppData\Roaming\Claude\local-agent-mode-sessions\...
- No local sandbox exists — installation inspection confirms:
Path: C:\Program Files\WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
Contents: app/ and assets/ folders only
NO WSL, Docker, container runtime, or sandbox binary found
%AppData%\Claude does not exist on this machine
Windows Event Viewer shows ZERO Claude entries
Conclusion: Linux workspace is a REMOTE/CLOUD service.
The failure is server-side — nothing to fix locally.
- Affected sessions (6 confirmed):
local_7922f495, local_b8a680cb, local_83d21f4b,
local_b2a16a18, local_b98a6bbc, local_b5a3f165
- Working sessions (before update):
local_749d8921, local_b55ec58e, local_9f5155d2, local_95848dc1
- Anthropic Support Conversation ID: 215474175581735
- App update date: 29 April 2026 — correlates exactly with regression start
12 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This issue has been automatically closed as a duplicate of #55649.
If this is incorrect, please re-open this issue or create a new one.
🤖 Generated with Claude Code
« +1 same symptom on Surface Book 3 / Windows 11 Pro / i7-1065G7. Identified root cause as 5-second timeout race between Claude Desktop and CoworkVMService startup. Detailed trace and PowerShell workaround posted in #48661 ([link to your comment]). Sharing in case it helps others land on the right fix faster than nuking their install. »
+1 — same bug on Windows Cowork v1.6608.2.0 (newer than reported v1.5354.0.0, so the regression persists across updates). Confirmed clean local environment via diagnostic: backend reachable (api.anthropic.com → 404, claude.ai → 403), DNS resolves correctly, no VPN/proxy/3rd-party AV. Sandbox still fails to provision on every session. Please prioritize.
Confirming this on a second affected account — same error, same window of dates.
Account context
Failure timeline on my account
Workspace unavailable. The isolated Linux environment failed to start.Operational impact
A daily scheduled task ("daily-bakery-order") that places my bakery's wholesale order before a 13:59 deadline has been broken for four scheduled runs in a row. I had to manually intervene today to get the order placed via a SKILL rewrite that avoids
mcp__workspace__bashentirely. That works but loses several pipeline features (xlsx archive output, source-of-truth product mapping, AI optimiser warmup data).Confirming OP's diagnosis
mcp__workspace__bashreturns the failure string instantly on every call — no retry recovery, no startup delay.echo,date,true,python3 --version— all fail identically.Adding my voice to push priority on this — six straight days of total bash unavailability is well past "transient." Happy to provide additional session IDs / logs if it helps the engineering team narrow it down.
Absolutely agree with rossassenheim, I can't get any of my most important work done while bash is failing. This should have been fixed days ago.
same problem, tried everything Claude suggested me to do, after failed attempts, full reinstall of Claude worked... for few sessions.
Since some time, it doesn't start workspace again, at all.
same problem... no answer from help menü:)
This solution worked for me: https://github.com/anthropics/claude-code/issues/48661
I've tried this twice and it isn't working for me.
Distinct case — bash NOT restored after May 13 server-side fix: Intel RST VMD Controller 467F ELOOP on VHDX rename
My bash workspace is still broken after the server-side fix that resolved the issue for most users (confirmed still broken as of 2026-05-23). This is a separate, hardware-specific root cause — not the cloud provisioning outage.
Hardware: HP OMEN, Intel RST VMD Controller 467F, Windows 11 24H2, BIOS F.55, Intel RST driver v19.5.8.1059
Anthropic support ticket: ID 215474175581735
Root cause confirmed: Intel RST VMD Controller 467F rejects POSIX atomic rename (fs.rename()) for cross-directory operations on NTFS. Node.js/Electron reports this as:
ELOOP: too many symbolic links encountered, rename 'claudevm.bundle\.wvm-tmp-xxx\rootfs.vhdx' -> 'claudevm.bundle\rootfs.vhdx'
Evidence this is hardware-specific, not cloud-side:
Bash worked on this machine before v1.8089.1 — the VMD controller is not fundamentally incompatible with HCS/WSL2
Bash did NOT recover after the May 13 server-side fix that resolved the issue for most users
Every "reinstall workspace" attempt hits ELOOP on the rename step and leaves vm_bundles in a broken state
CoworkVMService starts correctly, Hyper-V is functional (True) — the VM is never attempted because the app never calls configure after ELOOP fires
The ELOOP failure completes and the temp dir is deleted before the error card appears in the Cowork UI — no manual interception is possible
All workarounds attempted and failed:
Watcher script to intercept VHDX before rename — zero-window problem, temp dir deleted before error appears in UI
Manually placing rootfs.vhdx in claudevm.bundle\ — app detects inconsistency, deletes file, restarts download
Python zstandard decompression + manual placement — app rejected (size mismatch: Python produces 8.8 GB vs app's expected 5.27 GB)
BIOS update (F.41→F.55) — no effect
Intel RST driver update (v19.5.0.1037→v19.5.8.1059) — no effect
D: drive junction — caused 15-minute kernel hang, Ctrl+Alt+Del unresponsive ⚠️ do not suggest for VMD hardware
Related: This appears to be the same class of bug as #38457 (EXDEV on CldFlt/Dropbox). Different driver, same failure pattern: a filesystem filter rejecting the atomic rename used for VHDX placement.
Required fix: Change VHDX placement logic from fs.rename() to a copy-then-delete pattern. The atomic cross-directory rename is rejected by Intel RST VMD on NTFS; a copy operation does not have this restriction. This is the only fix that will work for this hardware class.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.