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

[christianbauhn-maker]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment:

• OS: Windows (company managed)
• App: Claude Cowork mode
• Error: "Workspace unavailable. The isolated Linux environment failed to start."

Steps taken (with IT admin, full admin access):

1. Set vmms (Hyper-V Virtual Machine Management) → Automatic ✅
2. Set vmcompute (Hyper-V Host Compute Service) → Automatic ✅
3. Set hvhost (HV Host Service) → Automatic ✅
4. Verified via PowerShell: all three services Running + Automatic
5. Restarted Claude, started multiple new sessions
6. Sandbox still fails on every attempt

Result: File tools work. Only bash/Linux sandbox is broken — across all sessions and after full restart.

Related issues: #50997, #52359, #55404, #55649, #56145

Request: Local Hyper-V config appears correct. Please investigate server-side provisioning or advise on fix for managed Windows environments.

What Should Happen?

The Linux sandbox should start successfully so Claude can execute bash commands and Python scripts in Cowork mode.

Error Messages/Logs

Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly.

Steps to Reproduce

1. Open Claude Cowork mode on Windows (company managed)
2. Start a new session
3. Ask Claude to run any bash command
4. Error appears every time: "Workspace unavailable"

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

april 30 2026

Claude Code Version

Cowork desktop app (not Claude Code CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This bug occurs in Claude Cowork desktop app (not Claude Code CLI).
The sandbox has never worked on this machine. All Hyper-V services
confirmed Running + Automatic via PowerShell. Bug appears systemic
based on related issues #50997, #52359, #55404, #55649, #56145.

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] Linux sandbox (bash) permanently fails — cloud workspace not provisioning for Windows Cowork sessions (6+ sessions affected) #56145
2. [BUG] Cowork mode - Linux bash sandbox never starts on Windows (Workspace unavailable since first launch) #55649
3. [BUG] Cowork desktop app — bash workspace fails to start repeatedly across sessions #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

[christianbauhn-maker]

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.

[christianbauhn-maker]

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.

[christianbauhn-maker]

✅ 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.

[christianbauhn-maker]

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)

[christianbauhn-maker]

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
2. 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
3. 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
2. Re-download the VM bundle automatically when the expected path is empty
   (.auto_reinstall_attempted flag logic exists but did not trigger correctly), or
3. 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-.log
   Linux daemon console log (mount, format,
   network, commands)

sandbox-fix-summary.pdf

[MikeHazeJr]

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.

[seiferflo]

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

[christianbauhn-maker]

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