[BUG] Cowork desktop app — bash workspace fails to start repeatedly across sessions

[rickettspaige-eng]

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?

I am using the Cowork desktop app (not the Claude Code CLI). The bash/Linux workspace has been failing to start repeatedly across at least 4 separate sessions. I have had to restart the app and create multiple new chats just to get basic work done.

What Should Happen?

The bash/Linux workspace should initialize successfully and remain stable across sessions, allowing me to use the Cowork desktop app without having to restart or create new chats.

Error Messages/Logs

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

Steps to Reproduce

Restarting the app multiple times
Creating new chat sessions
Checking for duplicate Claude/Cowork installations in Windows — none found

What I have NOT been able to try:

/bug, /doctor, /feedback commands — these do not exist in the Cowork desktop app. Support kept directing me to Claude Code CLI troubleshooting steps, which do not apply.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Windows: Cowork fails to start - “VM service not running” (app hang / stuck) #48001
2. [BUG] Cowork not working on Windows 11 Pro - VM service errors, all troubleshooting exhausted #45577
3. Cowork workspace broken since update - VM service not running #48381

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

[deyjayprakash123-cloud]

Title: [BUG] Cowork Desktop: "Workspace unavailable" - Isolated Linux environment fails to start

Description:
I'm seeing a recurring failure where the bash/Linux workspace in the Cowork desktop app (Windows) refuses to initialize. I've had this happen across 4+ sessions, and the only "fix" is to nuke the session and start a new chat, which is a major context killer.

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

Context for Devs:
I’m on Claude 1.5354.0. Troubleshooting is difficult because the GUI version doesn’t support the /bug or /doctor commands found in the CLI.

Environment:

OS: Windows 11

Version: 1.5354.0 (9a9e3d)

Note: No duplicate installations found. Virtualization is enabled in BIOS

[seniortiger16]

+1 reproducing on my account. Adding more detailed evidence than the original report — note this is a REGRESSION for me (bash worked before the latest update), which differs from OP's "never worked" answer.

Note re: auto-closure as duplicate of #48001 / #45577 / #48381: Those three issues all reference "VM service not running" — a different error string. My failure (and the failure described in the OP here) is "Workspace unavailable. The isolated Linux environment failed to start." — which surfaces after the VM service appears to be up. May share root cause but should not be auto-merged without engineer review.

Environment

• Cowork desktop version: 1.5354.0.0 (latest, per Settings → Apps → Installed apps; auto-update reports "latest installed")
• OS: Windows 11
• Account/Plan: Max

Regression timing

• Before the update: bash via mcp__workspace__bash worked normally. Late April 2026 plugin audit log shows successful bash invocations through approximately April 28.
• Sunday April 26 evening: updated Cowork desktop to 1.5354.0.0.
• Immediately after the update: intermittent bash workspace failures began.
• April 29 onward: failures escalated from intermittent to persistent total-failure mode — every bash invocation fails, no in-session recovery, no cross-session recovery.
• As of this comment: persistent total-failure has continued without interruption.
• This pattern (worked → intermittent after update → persistent after April 29) appears to be a regression introduced by the 1.5354.0.0 release on this Windows 11 environment.

Symptoms

• mcp__workspace__bash returns "Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly." within ~1 second
• Affects ALL bash commands invoked via mcp__workspace__bash, including trivial echo test
• 100% within a failed session (no in-session recovery)
• Persistent across full Cowork app quit/restart from system tray
• Persistent across full laptop reboot
• A non-bash "echo test" surface (appears to be a Cowork built-in diagnostic, separate from mcp__workspace__bash) does succeed — suggesting the failure is specific to the bash workspace MCP, not a global Cowork-infrastructure problem. Engineering can confirm which surface that is.

What works (verified throughout the failure window)

• All file tools: Read, Write, Edit, Grep, Glob
• Folder mount via request_cowork_directory
• Plugin loading and skill dispatch via the Skill tool
• Both Cowork-mode and Code-mode in the same desktop app
• Only the workspace bash MCP fails to provision

Things ruled out

• NOT plugin-caused — fails in fresh chat with no plugin loaded
• NOT OneDrive-caused — file tools reading OneDrive paths work fine
• NOT session-state corruption — fails on fresh-chat baseline
• NOT a global Anthropic outage — status.anthropic.com clean during failure window
• NOT a Cowork install issue — file tools, plugin install, and non-bash echo all function

UI diagnostics attempted

• /mcp in Cowork mode → "Unknown skill: mcp" (Cowork uses / as skill prefix)
• /mcp in Code mode → opens Connectors page, empty (workspace bash is built-in MCP, not an add-on)
• No UI in either mode exposes workspace bash server status or offers a reconnect action
• /bug, /doctor, /feedback commands do not exist in Cowork desktop (per OP)

For Anthropic engineering

• Support ticket conversation ID: 215474156404848 (filed 2026-05-02 — no response yet)
• This is a regression — bash worked on previous Cowork desktop builds for me, broke after updating to 1.5354.0.0 on Sunday evening April 26. Whatever changed between the prior build and 1.5354.0.0 in the workspace MCP provisioning path is the most likely culprit.
• The escalation pattern (intermittent for a few days, then persistent total failure starting April 29) may correlate with a server-side change rolled out around that date, OR with my local state crossing some threshold. Server-side logs for my account should distinguish.
• Server-side logs for my account during 2026-04-28 through report date should show the workspace MCP provisioning attempts and their failure mode (timeout vs refused vs container-init error vs resource exhaustion vs auth)
• Happy to provide screen recordings, additional session IDs, or coordinate a debug session

What I need from engineering

Primary (the actual bug fix):

1. Make mcp__workspace__bash work correctly. The bash workspace MCP needs to provision reliably and stay up. Bash is core functionality — without it, batched mechanical work and any pipeline that depends on shell commands cannot run. This is the main ask.

Secondary (defensive UX while the root cause is being investigated):
2. Add a Cowork desktop UI control to (a) inspect the workspace MCP server's status (running/failed/initializing) and (b) trigger a reconnect/retry. Right now users have zero visibility and zero recovery actions when the sandbox fails to provision — even if the underlying bug remains, this would let users self-diagnose and self-recover from transient failures.

[jskrzypek]

I'm seeing this error on Linux (NixOS) as well. I am running the FHS flavor of claude desktop from this repo.

[WimO908]

Bug report comment — issue #55404
URL to post on: #55404

Same issue here on Windows, Cowork desktop app. Sandbox / bash workspace has been completely unavailable for over 2 days (May 3 to May 5, 2026).
Error message (every bash call, no exceptions):
Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly.
What I tried:

Multiple full restarts of the Claude Desktop app (via Task Manager, not just close)
Multiple new sessions
Checked for updates: no update available
Waited several minutes between retries

Impact:
This blocks any work that needs Python, openpyxl, python-docx, or any CLI tool. File tools (Read/Write/Edit) still work, but anything involving binary files (xlsx, docx, pdf creation) is impossible without bash.
Setup:

OS: Windows
Claude Desktop: latest version (no update offered)
Sessions affected: every single one across two days

Happy to provide additional logs if someone tells me where to find them.

[690937427]

found the solution here: https://linux.do/t/topic/2072551/10

[seniortiger16]

For engineers

TL;DR: I tried the solution suggested. Cowork's bash sandbox fails to provision after all host-level preconditions are confirmed working. Failure is fast (~1s), no error code, no logs, and the user has no UI to inspect or reconnect the failing MCP server. This account is reproducible.

Actionable signals

1. Failure is sub-second, not on a 60s timeout. Whatever's failing isn't a slow VM boot — it's a pre-flight check rejecting before VM startup. Support's earlier "MCP SDK 60s timeout" theory doesn't fit my data.
2. Generic error message blocks all diagnosis. Users see only:

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

No error code. No log path. No failure category. No way to tell whether it's BIOS virt, missing files, corrupt bundle, scanned-by-AV, or a Cowork-internal config issue. This message needs to expose at least: which subsystem failed, and whether logs exist on disk for users to share.

3. No user-facing UI to inspect or reconnect the workspace MCP server.
   • /mcp in Cowork mode → "Unknown skill: mcp" (Cowork uses / for skill invocation)
   • /mcp in Code mode → opens Connectors page (workspace bash is a built-in MCP server, not listed there)
   • No menu entry, settings panel, or developer-tools route exposes built-in MCP server state
4. .auto_reinstall_attempted flag in the VM bundle directory. Cowork has internal logic to detect bundle problems and try a reinstall, but the recovery code path apparently can leave users stuck — this flag persists indefinitely once set. Either the auto-reinstall isn't actually re-attempting, or it's silently failing and never clearing the flag.
5. At least two install layouts exist in the wild for the VM bundle path. The fix earlier in this thread targets one layout; my install uses a different one:
   • Layout A (per @Momo520, this thread): ~\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\
   • Layout B (mine): ~\AppData\Local\Packages\Claude_<package-id>\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\
   Note Layout B uses Roaming\Claude\ not Roaming\Claude-3p\. Whatever code path checks "is the bundle present" needs to handle both layouts (or the install needs to converge on one).
6. VM bundle contents observed (Layout B):

   .auto_reinstall_attempted
   .initrd.origin           initrd       initrd.zst
   .initrd.zst.origin
   .rootfs.vhdx.origin      rootfs.vhdx  rootfs.vhdx.zst
   .rootfs.vhdx.zst.origin
   .vmlinuz.origin          vmlinuz      vmlinuz.zst
   .vmlinuz.zst.origin
   sessiondata.vhdx
   smol-bin.vhdx

The .origin + .zst pattern suggests a verify-and-decompress flow. Worth checking if any of these are partial/checksum-mismatched — there's currently no user-facing way to validate bundle integrity.

7. Confirmed working baseline (the things engineering can take off the table):
   Subsystem | Test | Result -- | -- | -- CPU virtualization | Get-CimInstance Win32_Processor after BIOS enable + Hyper-V running | HypervisorPresent: True Hyper-V | Windows feature state | Enabled for VirtualMachinePlatform and HypervisorPlatform WSL2 | wsl --status | Default version 2, Ubuntu installed WSL kernel functional | wsl -e echo "hello from wsl" | Returns expected output Defender | Get-MpPreference after Add-MpPreference -ExclusionPath | Exclusions registered File-tool MCP server | Read/Write/Edit/Grep/Glob calls | Working throughout VM bundle files on disk | Get-ChildItem against bundle path | All present
   Yet mcp__workspace__bash still fails. Conclusion: the failing component is downstream of WSL2/Hyper-V/Defender/file-tools and inside Cowork's own VM-provisioning stack.

Suggested investigation paths

• Server-side logs for this account during a failed mcp__workspace__bash call — what does the workspace MCP server log when it returns "failed to start"? That's the signal Cowork has but isn't surfacing.
• Bundle integrity check — verify .origin checksums against actual file content for this user's bundle. Partial/corrupt downloads with the .auto_reinstall_attempted flag set seem to be a stuck state.
• .auto_reinstall_attempted semantics — what exactly clears this flag? If Cowork sets it on first failure but never clears it, every subsequent launch enters a degraded state.
• Consolidate install layouts — having Local\Claude-3p\ vs Packages\Claude_*\LocalCache\Roaming\Claude\ paths in the wild creates exactly the support burden visible in this thread.
• Surface diagnostic info — at minimum expose the workspace MCP server stderr in a Cowork developer-tools panel, similar to how Claude Code CLI has claude --debug mcp.

Bash Workspace Failure — Diagnostic Update

I tried @Momo520's Gemini-suggested hard-link fix from earlier in this thread plus several other steps. Posting the full record in case it helps anyone else hitting this.

---

Environment

• Product: Cowork desktop (not Claude Code CLI)
• OS: Windows 11
• CPU: Intel Celeron N5095 @ 2.00 GHz
• Status page: clean throughout
• Symptom: every bash call returns

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

File tools (Read/Write/Edit/Grep/Glob) work consistently. Only the bash sandbox fails.

---

What I tried, in order

1. The hard-link script from this thread

Ran @Momo520's Gemini PowerShell script as-is. Result:

[WARN] Source file does not exist: C:\Users\<me>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx
[WARN] Source file does not exist: ...\vmlinuz
[WARN] Source file does not exist: ...\initrd
[WARN] Source file does not exist: ...\smol-bin.vhdx

The original script's source path doesn't exist on my install. My VM files live somewhere different.

2. Found my actual VM bundle path

Searched AppData:

powershell

Get-ChildItem -Path "C:\Users\$env:USERNAME\AppData" -Recurse `
  -Include "*.vhdx","vmlinuz","initrd","claudevm*" `
  -ErrorAction SilentlyContinue | Select-Object FullName

VM files were at:

C:\Users\<me>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\

Note: my path uses Roaming\Claude\vm_bundles — not Roaming\Claude-3p\vm_bundles like @Momo520's case. Different install layout.

Files actually present in that folder (richer than the original script expected):

.auto_reinstall_attempted
.initrd.origin
.initrd.zst.origin
.rootfs.vhdx.origin
.rootfs.vhdx.zst.origin
.vmlinuz.origin
.vmlinuz.zst.origin
initrd
initrd.zst
rootfs.vhdx
rootfs.vhdx.zst
sessiondata.vhdx
smol-bin.vhdx
vmlinuz
vmlinuz.zst

That .auto_reinstall_attempted flag file is interesting — suggests Cowork already tried to auto-fix something and gave up.

3. Modified the script and re-ran

Adapted the script to source from Claude\vm_bundles\claudevm.bundle\ (where files actually are) and link into Claude-3p\vm_bundles\claudevm.bundle\ (in case Cowork checks that path). Used dynamic file discovery so it caught all 15 files. Output:

[OK] Linked: .auto_reinstall_attempted
[OK] Linked: .initrd.origin
[OK] Linked: .initrd.zst.origin
[OK] Linked: .rootfs.vhdx.origin
[OK] Linked: .rootfs.vhdx.zst.origin
[OK] Linked: .vmlinuz.origin
[OK] Linked: .vmlinuz.zst.origin
[OK] Linked: initrd
[OK] Linked: initrd.zst
[OK] Linked: rootfs.vhdx
[OK] Linked: rootfs.vhdx.zst
[OK] Linked: sessiondata.vhdx
[OK] Linked: smol-bin.vhdx
[OK] Linked: vmlinuz
[OK] Linked: vmlinuz.zst

All linked successfully. Restarted Cowork. Tested bash. Same error.

The path mismatch theory doesn't apply to my install. The hard-link fix from this thread did not resolve my issue.

4. Diagnosed host virtualization

Initial PowerShell check showed VT-x off in BIOS:

VirtualizationFirmwareEnabled:               False
SecondLevelAddressTranslationExtensions:     False
Microsoft-Windows-Subsystem-Linux:           Disabled
wsl --status:                                "WSL is not installed"

So I:

1. Rebooted, entered BIOS, enabled Intel VT-x, saved and exited.
2. Ran wsl --install (admin PowerShell), rebooted.

Post-fix check:

HyperVisorPresent:                           True
WSL Default Version:                         2
Default Distribution:                        Ubuntu
wsl -e echo "hello from wsl"  →              hello from wsl

Virt stack is fully functional. WSL can run Linux. Hyper-V is up.

Tested bash in Cowork. Same error. Virt stack alone wasn't the bottleneck.

5. Defender exclusions

Added Windows Defender exclusions for both VM bundle paths and the Claude.exe process:

powershell

Add-MpPreference -ExclusionPath "...\Roaming\Claude\vm_bundles"
Add-MpPreference -ExclusionPath "...\Roaming\Claude-3p\vm_bundles"
Add-MpPreference -ExclusionProcess "Claude.exe"

Verified via Get-MpPreference. Tested bash. Same error. Real-time scanning wasn't the bottleneck either.

---

Summary of what's ruled out

Cause | Ruled out by -- | -- Plugin interference | Bash fails on fresh-chat baseline before any plugin loads Long-running session state | Fails in brand-new sessions Path mismatch (this thread's fix) | Hard links created with correct paths; bash still fails Host virtualization | WSL works, HypervisorPresent: True, Linux command runs Defender real-time scanning | Exclusions added; no change OneDrive | File tools fully functional Account-wide outage | Status page clean, account works in other ways

---

What's left

The bottleneck appears to be inside Cowork's own VM provisioning code path, independent of the host virtualization stack. Most likely candidates:

1. Corrupted/partial VM bundle download — the .auto_reinstall_attempted flag suggests prior auto-recovery failed.
2. Cowork app config drift pointing at a stale VM definition.
3. Stuck Hyper-V VM record from a previous failed provisioning attempt.

---

Next step

Full Cowork uninstall + reinstall, then let it re-download a fresh VM bundle on first launch. OneDrive files are independent of Cowork app local data, so manuscripts and other work files survive.

Will post here whether the clean reinstall resolves it.

[seniortiger16]

Update — bash now works on this machine. Diagnosis revised; previous theories partially wrong.

Following the diagnostic path posted upthread, I did the full nuclear-option reset: uninstall Cowork via Settings → Apps, full reboot, removed all residual app state (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc, %APPDATA%\Claude, %APPDATA%\Claude-3p, %LOCALAPPDATA%\Claude-3p), reinstalled fresh from claude.ai/download. After the reinstall, bash did eventually provision — but only after a 5-minute startup window during which the UI shows a mix of Workspace still starting and Workspace unavailable… failed to start. Posting the corrected timing picture because it changes the bug significantly.

The diagnosis I posted last time was partially wrong. The HCS 0xC037010D / Invalid JSON document '$' Hyper-V-Compute event isn't the root failure — it appears to be associated with the auto-reinstall teardown path that fires after Cowork's first-attempt connection timeout. The real failure on this hardware is much simpler: provisioning is just slow, and Cowork's first-attempt timeout is too aggressive to ever succeed.

Cold-start sequence on this hardware (Intel Celeron N5095, captured from cowork_vm_node.log):

20:56:55  Bundle:status rootfs.vhdx missing (fresh install, downloads from server)
21:02:41  rootfs.vhdx download completes
21:03:08  All VM files ready  → download_and_sdk_prepare completed (370798ms = 6m10s)
21:03:11  vm_boot completed (1714ms)
21:03:13  add_plan9_shares completed
21:03:23  Still waiting for guest connection... 10s
21:04:07  Still waiting for guest connection... 54s
21:04:14  [error] Connection timeout, last completed step: add_plan9_shares
21:04:25  Startup failed: VM connection timeout after 60 seconds
21:04:25  Auto-reinstalling workspace after startup failure
21:04:25  [warn] rootfs.vhdx locked by running VM (EBUSY), skipping
21:04:25  Reinstall files deleted (sessiondata.img and compressed cache preserved)
21:04:33  VM:shutdown completed in 7339ms
[Cowork app re-launches, second attempt begins]
21:05:05  VM:start beginning, NEW instance ID: 5d39ef36-ef21-4993-bdfe-78643ba1bf3e
21:08:44  rootfs.vhdx decompression from cache completed in 228834ms (3m49s)
21:09:18  vmlinuz decompression completed in 33809ms
21:09:27  initrd decompression completed in 8128ms
21:09:27  All files ready  → download_and_sdk_prepare completed (261439ms = 4m21s)
21:09:31  vm_boot completed (0ms)
21:09:42  Still waiting for guest connection... 10s
21:09:51  [VM] Network status: CONNECTED
21:09:51  [VM:steps] sdk_install started
21:09:56  [VM] API reachability: REACHABLE
21:10:06  [VM:steps] sdk_install completed (15112ms)
21:10:06  [VM:start] Startup complete, total time: 300756ms

Total time from app launch to working bash: 5 minutes 0 seconds. First attempt always fails at the 60-second add_plan9_shares → guest-connection wait. Cowork's auto-reinstall does fire correctly on this build (1.6259.0.0) and the second attempt succeeds. The user surface during this window is misleading — they see "failed to start" on the first attempt, the app appears to die, but it's actually re-launching and a second attempt is in progress.

What changed from my prior comment:

• The HCS 0xC037010D error is now believed to be from the auto-reinstall teardown sequence, not the underlying provisioning bug. Engineering should still verify the JSON-builder path, but it's not the headline issue.
• The 30-second SDK install timeout is not the bottleneck. The new log shows SDK install completes in 15 seconds. The actual long pole is rootfs.vhdx.zst decompression: ~229 seconds on this CPU.
• The .auto_reinstall_attempted flag is not permanently stuck on this build. The auto-reinstall path completes successfully, just very slowly.
• Hard-link path-mismatch fix from upthread definitively does not apply to this install. Verified: Test-Path "$env:LOCALAPPDATA\Claude-3p\vm_bundles\claudevm.bundle" returns False. The directory Local\Claude-3p exists but contains no VM bundle. The MSIX install pattern uses %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\ exclusively.

Two real bugs that should still be filed and Must Be Fixed:

1. 60-second guest-connection timeout is too aggressive on low-end hardware. Every cold start on this machine fails the first attempt and wastes ~5 additional minutes redoing decompression on the second attempt. If the timeout were higher (300s) or progressive, users would save the entire wasted-attempt cycle and never see the "failed to start" UI surface on slow boxes.

2. The "Workspace unavailable. The isolated Linux environment failed to start" UI message is misleading during the recoverable state. On this hardware, this is what users see during the first attempt — but it's not actually a terminal failure; Cowork's auto-reinstall is about to fire and a second attempt will succeed. Users who quit/restart at this message lose progress and never see the install complete. Suggested fix: distinguish "first attempt failed, auto-retrying — may take several more minutes" from "all attempts failed".

Bonus diagnosability ask still standing: the original "Workspace still starting" / "Workspace unavailable" error strings need to expose underlying state (which step is in progress, how many attempts have been made, ETA on slow hardware). Users on Celeron-class hardware are silently waiting through a 5-minute provisioning window with no signal that anything is happening.

App version in log: Claude_1.6259.0.0_x64__pzs8sxrjxfjjc (auto-updated since original report). Hardware: Intel Celeron N5095, Windows 11, MSIX install. Support ticket: 215474156404848. Account remains reproducible — happy to capture additional traces, run instrumented builds, or coordinate a debug session.

---

For other users hitting this issue — workaround until engineering ships a fix

If you're seeing Workspace unavailable. The isolated Linux environment failed to start. repeatedly on Cowork desktop (Windows), here's what worked for me. Read all the way through before starting — the most important step is "be patient," and partway through the process the app will look like it's failing when it isn't.

Step 1 — Confirm host prerequisites (skip if you already know these are good).
In an elevated PowerShell (aka Terminal Admin on Windows):

Get-CimInstance Win32_Processor | Select-Object VirtualizationFirmwareEnabled, SecondLevelAddressTranslationExtensions
wsl --status

VirtualizationFirmwareEnabled must be True. If it isn't, reboot into BIOS and enable Intel VT-x (or AMD-V). wsl --status should report a default version 2 distro. If WSL isn't installed, run wsl --install from an elevated prompt and reboot.

Step 2 — Full clean reset of Cowork.
Quit Cowork from the system tray. Then in elevated PowerShell:

Get-Process Claude -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Claude-3p" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Claude-3p" -Recurse -Force -ErrorAction SilentlyContinue

Then uninstall via Settings → Apps → Installed apps → Claude/Cowork → Uninstall.

Step 3 — Reboot. This clears any stuck Hyper-V VM records or vmcompute state. Don't skip it.

Step 4 — Reinstall fresh from claude.ai/download. Sign in.

Step 5 — Be patient. This is the most important step.
On the first cold start after reinstall, Cowork has to download the Linux VM image from Anthropic's servers and decompress it. On low-end hardware (Celeron-class CPUs, etc.), this takes 5 to 10 minutes. During that window you will probably see, in this order:

• Workspace still starting… for several minutes
• Workspace unavailable. The isolated Linux environment failed to start. (this looks like a terminal failure but it isn't — Cowork's auto-reinstall is firing)
• Workspace still starting… again
• Eventually: bash works

Do not quit Cowork when you see "failed to start." Do not close the chat. Do not try to nuke the bundle manually. Just wait. The app is doing a second provisioning attempt in the background and will succeed if you let it finish.

Step 6 — Test bash. Once Cowork looks idle, ask Claude to run echo test in a fresh chat. If you see test come back, you're done.

If after 15 minutes bash is still failing, capture the log so engineers can see what your machine is doing differently:

$src = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log"
$dst = "$env:USERPROFILE\Desktop\cowork_vm_node.log"
Copy-Item $src $dst -Force
Get-Item $dst | Select Name, Length, LastWriteTime

Attach cowork_vm_node.log from your Desktop to a comment on this thread.

What did NOT work for me, despite being suggested earlier in the thread:

• The Gemini-suggested hard-link script (path mismatch fix). My install layout doesn't match what the script expects, and the bug isn't a path-mismatch bug anyway.
• Adding Defender exclusions. Real-time scanning isn't the bottleneck.
• Toggling Memory Integrity / HVCI off. Not relevant to this failure mode.
• Restarting Cowork repeatedly without the full clean reset above. The Cowork app holds onto bad state across normal restarts.

Going forward (workflow on slow hardware):
After the initial fix, every cold start of Cowork still takes 5–7 minutes to make bash available, and you'll typically see "failed to start" once during that window. The fix is the same: wait through it, don't quit. The auto-reinstall path on the current build (1.6259.0.0) recovers correctly. Don't manually nuke the bundle as a "workaround" — that just forces a 5-minute redownload for nothing.

If your hardware is faster than mine (anything above a Celeron N5095 / Jasper Lake should be), expect a shorter window — likely 1–3 minutes total. Same principle: be patient on the first attempt.

Hope this helps the next person who hits this.

Engineers, the diagnostic-UX gap is the single biggest contributor to people reporting this as a hard failure when it isn't — please consider Bugs 1 and 2 above a priority.

[naivej]

This issue is fixed for me after upgrading to 1.6259.1

[SsuHan-Liu]

Adding a verified workaround for what looks like a distinct failure mode from the auto-reinstall timeout pattern @seniortiger16 has documented so well above. On Windows 11 MSIX (Claude Desktop 1.6259.0), the same Workspace unavailable symptom can be caused by a path mismatch between the App and the service that I haven't seen sketched in this thread yet.

Failure mode: cross-process MSIX path mismatch

@seniortiger16 already noted "at least two install layouts exist in the wild for the VM bundle path." On a Layout B install (Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\…), the failure is not just which layout is on disk but who sees what:

• Claude Desktop App (packaged, runs inside the MSIX container) writes to %APPDATA%\Claude\vm_bundles\…. MSIX File System Redirection silently rewrites this to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\….
• CoworkVMService (Windows service, runs outside the MSIX container) reads from the real %LOCALAPPDATA%\Claude\vm_bundles\….

These are two completely different directories. The bundle (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx, sessiondata.vhdx) lives only in the MSIX-virtualized location; the path the service expects often doesn't even exist on disk. cowork_vm_node.log confirms (timestamps from my own machine, 2026-05-06):

[VM:start] Copying smol-bin.x64.vhdx to bundle:
    … -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
[error] Startup failed: Error: failed to set VHDX path:
    VHDX file not found: C:\Users\<user>\AppData\Local\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx

The outer Workspace unavailable is what most of the thread reports; the inner failed to set VHDX path is what distinguishes this mode from the auto-reinstall-timeout mode. Worth grepping cowork_vm_node.log to disambiguate before applying the workaround.

Why the obvious link-based workarounds don't work

CoworkVMService has explicit defensive checks against link-based redirection. I worked through three dead ends:

1. Directory junction (mklink /J vm_bundles → MSIX path) → is a symlink or junction, refusing to open (FILE_ATTRIBUTE_REPARSE_POINT check on the directory).
2. Per-file hardlinks (mklink /H on each bundle file — same approach @Momo520 tried in the duplicate-flagged threads) → has multiple hard links, refusing to open (GetFileInformationByHandle nNumberOfLinks check on each file). This is why @seniortiger16's hardlink retry on Layout B failed: the service rejects any file with link count > 1 by design.
3. Set-Service -StartupType Automatic → Access is denied even with admin elevation, because CoworkVMService is registered as WIN32_PACKAGED_PROCESS (sc.exe TYPE: 210) and inherits MSIX AppContainer restrictions on service config (see [BUG] Cowork workspace fails to start — CoworkVMService cannot create named pipe due to WIN32_PACKAGED_PROCESS sandbox restrictions #48468). sc.exe config / sc.exe delete fail the same way; the service can only be controlled via Start-Service / services.msc GUI / direct registry.

These three together establish that the service only accepts real, independent files in a real directory tree.

Verified workaround: real copy (not a "nuke")

Important distinction from "delete and redownload" (which @seniortiger16 rightly cautions against): the MSIX-virtualized bundle stays intact. We only add a real-Local copy that the service can reach.

# 1. Quit Claude Desktop completely (incl. system tray icon)
Stop-Process -Name Claude -Force -ErrorAction SilentlyContinue

# 2. Remove any prior junction/hardlink attempts (safe even if absent)
$real = "$env:LOCALAPPDATA\Claude\vm_bundles"
if (Test-Path $real) {
    $item = Get-Item $real -Force
    if ($item.LinkType -eq 'Junction') { cmd /c rmdir "$real" }
    else { Remove-Item $real -Recurse -Force }
}

# 3. Real copy from MSIX-virtualized path to real Local (~14.8 GB; 30-60s on SATA SSD)
$msix = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles"
Copy-Item -Path $msix -Destination $real -Recurse -Force

# 4. Verify link count = 1 on key files (fsutil should list only the file's own path)
foreach ($f in 'sessiondata.vhdx','rootfs.vhdx','vmlinuz','initrd','smol-bin.vhdx') {
    fsutil hardlink list "$real\claudevm.bundle\$f"
}

# 5. Relaunch Claude → new session → bash works

Confirmed working on Claude Desktop 1.6259.0 (Layout B / MSIX): bash returns Linux 6.8.0-106-generic / Ubuntu 22.04 / x86_64.

Caveats

• ~15 GB extra disk usage — the bundle is now duplicated; sessiondata.vhdx alone is ~2.5 GB.
• Stale on Claude updates — when Claude itself updates, smol-bin.vhdx / rootfs.vhdx / vmlinuz / initrd in the MSIX-virtualized path get refreshed, but the real-Local copy stays at the old version and bash will re-break. A re-sync (steps 1-3) is needed after each Claude update.
• Doesn't help every variant — @naivej's report that 1.6259.1 fixed it for them suggests at least one path was addressed upstream. If you're on 1.6259.1+ and still seeing Workspace unavailable, please post the tail of cowork_vm_node.log — that's how to tell whether it's the path-mismatch mode (this comment) or the auto-reinstall-timeout mode (@seniortiger16's analysis above).
• This is a workaround, not a fix — the underlying issue is that the App writes to the MSIX-virtualized location while the service reads from the real-Local path. A proper fix would either have the App write to a non-virtualized location, or have the service follow MSIX redirection rules so both ends see the same directory.

Credit to @seniortiger16, whose two-layouts observation was the bridge to seeing this as a cross-process visibility issue rather than just a path-string difference.