[BUG] BUG: Cowork Linux sandbox fails to start on Windows — persists after all Hyper-V service fixes

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/56145
2. https://github.com/anthropics/claude-code/issues/55649
3. https://github.com/anthropics/claude-code/issues/55404

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Additional impact — skill-based file generation also broken
I want to clarify that the scope of this bug is broader than just direct bash access.
The Cowork skills for generating Word documents (.docx), PDFs, Excel files (.xlsx), and PowerPoint files (.pptx) all depend on Python scripts running in the Linux sandbox. Since the sandbox fails to start, none of these file generation workflows work either.
Practical impact over the past several days:

docx skill fails → had to use HTML as workaround
pdf skill fails → same
xlsx / pptx skills fail → same

This means the sandbox failure doesn't just block direct bash usage — it breaks the entire file generation pipeline that Cowork's core skills depend on. The HTML fallback works for some cases but is not a viable long-term substitute for professional document output.
Mentioning this in case it helps with diagnosis or prioritization.

Update: All local Windows features confirmed enabled
Following further investigation, all relevant Windows features are now verified as correctly enabled:

✅ Hyper-V (all sub-features: Hyper-V Hypervisor, Hyper-V-tjänster, management tools)
✅ Hyper-V Platform
✅ Virtual Machine Platform
✅ Windows Hypervisor Platform
✅ Windows Subsystem for Linux

All three Hyper-V services (vmms, vmcompute, hvhost) are also confirmed Running + Automatic via PowerShell.
There is nothing left to configure locally. The issue is not on the client side. Please investigate server-side provisioning for Windows/Cowork sessions.

✅ RESOLVED — Solution found (exact cause uncertain)
After ~4–5 days of debugging, the sandbox is now working. Two changes were made simultaneously, so I cannot confirm which one (or whether both combined) resolved the issue:

Virtualization enabled in BIOS — this had not been enabled despite Hyper-V services being fully configured and running in Windows.
Running Claude as Administrator — launched the Cowork desktop app via "Run as administrator" instead of under a standard employee account.

Both changes were applied at the same time and the sandbox started working immediately after. I cannot isolate which was the root cause.
Recommendation for others hitting this: If all Hyper-V services are confirmed Running + Automatic and the issue persists, check BIOS virtualization settings (Intel VT-x / AMD-V) and try running the app as administrator. Either or both may be required in managed Windows environments.

Fix: Bash Sandbox Not Starting for Standard Users on Windows

Problem

The Claude desktop app's bash sandbox (isolated Linux environment) fails to start when the app is launched as a standard (non-administrator) Windows user. The sandbox works correctly when the app is run as Administrator.

Symptoms:

• Sandbox returns "Workspace unavailable. The isolated Linux environment failed to start."
• Everything works fine when right-clicking the app and selecting Run as administrator
• No error is shown in the UI — the sandbox simply never becomes ready

Root Cause

The sandbox runs on WSL2 (Windows Subsystem for Linux 2), which depends on Hyper-V virtualization. On Windows, starting a Hyper-V-backed process requires the user account to either be a local Administrator or be a member of the Hyper-V Administrators group. Standard domain or local user accounts lack this permission by default, which prevents the WSL2 instance from booting.

Solution

Add the affected user account(s) to the local Hyper-V Administrators group. This grants the minimum required permission to start WSL2 without giving full administrator access.

Steps (run on each affected machine)

1. Open Computer Management (compmgmt.msc) as an administrator
2. Navigate to Local Users and Groups → Groups
3. Double-click Hyper-V Administrators
4. Click Add, enter the user's account name, and confirm
5. Click OK
6. Ask the user to sign out and back in for the change to take effect

Via PowerShell (elevated)

Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "DOMAIN\username"

Replace DOMAIN\username with the actual account (e.g. MYCOMPANY\jsmith or just jsmith for local accounts).

Notes

• This change only affects the ability to start WSL2 — no other privileges are elevated.
• If your organisation uses Group Policy to manage local group membership, the IT department may need to push this via GPO instead.
• If WSL2 is not installed or is disabled on the machine, that would need to be resolved first (requires Windows 10 version 2004+ or Windows 11, with the WSL optional feature enabled).

Verified on

• Windows 10 / Windows 11
• Claude desktop app (Cowork mode)

it crashed after a while but i found the problem:

Claude Cowork – Sandbox Failure After App Update
(v1.6608.x)
Date: 2026-05-11
Environment: Windows 11, AzureAD-joined, Claude desktop app (MSIX)
Affected version: Claude 1.6608.0.0 / 1.6608.2.0
Last working version: 1.1.9134.0
Summary
After a Claude desktop app update on May 9, 2026, the Cowork sandbox (isolated Linux
environment) stopped working entirely. The error shown to the user was:
"Workspace unavailable. The isolated Linux environment failed to start."
The user had previously been granted Hyper-V Administrator rights (local group
Hyper-V-Administratörer) as a permanent fix to avoid running Claude as administrator —
this configuration was still correct and was not the cause of the regression.
Root Cause
The app update changed the data directory path for the VM bundle:
Version Bundle path
≤ 1.1.9134.0 AppData\Local\Packages\Claude_pzs
8sxrjxfjjc\LocalCache\Roaming
\Claude\vm_bundles\claudevm.bundl
e\
≥ 1.6608.x AppData\Local\Packages\Claude_pzs
8sxrjxfjjc\LocalCache\Local\C
laude\vm_bundles\claudevm.bundle\
The new path was empty — the app did not migrate or re-download the bundle files
automatically. Additionally, sessiondata.vhdx (the session scratch disk) copied from the old
location was internally read-only and could not be formatted by the Linux daemon (coworkd) at
boot.
Failure chain:

1. CoworkVMService started but found no bundle files at the new path → VM never

booted

1. When bundle files were copied manually, the VM booted but coworkd failed to format

sessiondata.vhdx:
/dev/sdc: Read-only file system while setting up superblock

1. Without a writable session disk, the daemon exited and the workspace remained

unavailable
Fix Applied (Manual)
Step 1 – Copy VM bundle to new path:
$src = "...\LocalCache\Roaming\Claude\vm_bundles"
$dst = "...\LocalCache\Local\Claude\vm_bundles"
Copy-Item -Path $src -Destination $dst -Recurse -Force
Remove-Item "$dst\claudevm.bundle\.auto_reinstall_attempted" -Force
Step 2 – Replace sessiondata.vhdx with a fresh blank disk:
$vhdxPath = "...\LocalCache\Local\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"
Stop-Service CoworkVMService -Force
Remove-Item $vhdxPath -Force
New-VHD -Path $vhdxPath -SizeBytes 1GB -Dynamic
Start-Service CoworkVMService
Step 3 – Verify service start type (already AUTO_START):
sc.exe qc CoworkVMService

START_TYPE : 2 AUTO_START ← correct

After these steps the sandbox boots and runs commands successfully.
Recommended Fix (for Anthropic / GitHub)
The app update should either:

1. Migrate existing bundle files from the old path to the new path on first launch after

update, or

1. Re-download the VM bundle automatically when the expected path is empty

(.auto_reinstall_attempted flag logic exists but did not trigger correctly), or

1. Create a fresh blank sessiondata.vhdx as part of the install/update process, rather

than expecting the file to be copied or pre-existing
The sessiondata.vhdx is a session-scoped scratch disk that coworkd formats with ext4 on
every boot — it should always be provisioned as a new blank VHDX, never reused from a
previous installation.
Diagnostic Files
File Purpose
C:\ProgramData\Claude\Logs\cowork
-service.log
Windows-side VM lifecycle log (HCS, bundle
paths, VM start)
C:\ProgramData\Claude\Logs\cowork
d\user-<SID>.log
Linux daemon console log (mount, format,
network, commands)

sandbox-fix-summary.pdf

Thank you for your post and your subsequent comments. I was having the same issue, the full VM was failing which meant no Bash and many other functions were just wholly unavailable. After doing some digging on my end as well, it was determined that HyperV was enabled in Windows, I had run Claude in both standard and Admin modes, and still had the issue. The full HyperVisor is apparently not included in my edition of Windows (home). The issue was, as you said, tied to a recent update of Claude (in my case, on 05-09-2026), which as Claude describes, "didn't provision the VM bundle correctly on my install; the diagnosis pointed clearly enough to 'the bundle directory tree never made it to disk'" and uninstalling and reinstalling from claude.ai/download fixed it. I might suggest doing the same, to get your functionality back, but Anthropic really needs to fix this.

This is like, the 5th or 6th time the app has become totally broken for me in the 2 months I have had it, beyond just service interruptions or usage limits. I pay $200 a month for this and it breaks constantly. Focus on stability, Anthropic, holy christ.

I'm experiencing the same issue as described here. Every time I try to use Cowork mode on Claude Desktop, I get the error: "Workspace unavailable. The isolated Linux environment failed to start."
Every bash command in Cowork returns the same error immediately. File tools work fine, but I can't create documents or run any tasks that need the Linux environment.

My setup: Windows 11, Claude Desktop (latest version), Cowork mode enabled

What I've tried:

• Restarting Claude Desktop multiple times
• Delete cache folder
• I have WSL2 installed with Ubuntu, but the error persists

Follow the steps in the pdf and see to it that you have ubuntu and the latest version of python. Run the claude-app as an administrator and see to it that you delete the previous sessions (via help-button top left). After this you have to use powershell to really clarify that allt the pathways to your files are correct and that you have enabled autostart for Claude when the computer turns on. Last, see to it that the hyper-v and other programs actually work and are connected and active as a group-affiliate with administrative access. It was hell trying to fix all this but it finally works now. Let me know of i can help you in the process!

Best regards/Chris

I appreciate the help, but unfortunately, the process didn't work. Even after following the steps for Hyper-V and the VHDX replacement, the issue persisted. In a moment of 'brilliance,' I decided to delete the Claude local folder via Windows Apps Reset, assuming my data was synced to the cloud. It wasn't lol. I’ve now lost all my Cowork and Code projects and am currently grieving the loss of my work and my common sense. Thanks anyway !

I appreciate the help, but unfortunately, the process didn't work. Even after following the steps for Hyper-V and the VHDX replacement, the issue persisted. In a moment of 'brilliance,' I decided to delete the Claude local folder via Windows Apps Reset, assuming my data was synced to the cloud. It wasn't lol. I’ve now lost all my Cowork and Code projects and am currently grieving the loss of my work and my common sense. Thanks anyway !

• That sucks! Sorry to hear it. The Windows store download is a massive villain in many of the problems, the directory creates problems for us users and its a simple bus to fix. Maybe microsoft want it that way, it hibits and fucks up the directory and creates false in athways. I tried to give you all a clear path forward with explenations that solved it for me but maybe its more complex then that. Love the fact that i had ti pat for all the troubleshooting myself and anthropic doesnt even answer in the support via mail. NeXT time i download wont be via that appstore, thats for sure.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.