[BUG] Cowork completely unusable on Windows — recurring VM crashes, tab disappearing, and brief recovery followed by immediate failure (Max plan subscriber)

[On-Track-26]

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?

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 a Max plan subscriber ($200/month) and Cowork has been essentially unusable for me since I started using it. The errors occur immediately upon entering a prompt — no work is completed at all. I rarely get more than one or two conversations going before hitting a wall, and most of the time I can't even start a single conversation. I just get an error instantly.
The problem is getting worse, not better. After reinstalling Claude Desktop to try to fix the errors, the Cowork tab disappeared entirely from the UI — only the Chat tab remained. After further troubleshooting, Cowork briefly came back and answered one single question successfully, then immediately stopped working again with the same errors. This on-again-off-again pattern makes the feature completely unreliable for professional work.
I have reported this issue multiple times through the Claude interface with no resolution.
Errors Encountered
These are the errors I have received over the past two days. They appear immediately after submitting a prompt — Cowork does not perform any work before failing:
Error 1:
Something went wrong
sdk-daemon not connected
Error 2:
Something went wrong
Prompt is too long
(Note: My prompts are NOT too long. I am only getting 1–2 conversations in before this appears, and usually no conversation at all — just the error.)
Error 3:
Something went wrong
failed to write length: An established connection was aborted by the software in your host machine.
Error 4:
Something went wrong
RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
Error 5:
Something went wrong
sdk-daemon not connected
(Recurring — this one appears frequently.)
Error 6:
Something went wrong
Prompt is too long
(This appeared again after Cowork briefly recovered and answered one question — the very next prompt failed with this error despite being a normal-length prompt.)
Cowork Tab Disappearing
After experiencing the errors above, I did a complete reinstall of Claude Desktop (fresh download from claude.ai/download, cleared cache). After reinstalling, the Cowork tab was completely gone from the UI — only the Chat tab was visible.
This appears to be a known issue where VM errors cause the "yukonSilver" VM to be flagged as "unsupported," which triggers a cleanup that removes the VM bundle and hides the Cowork tab entirely. This creates a vicious cycle: errors → VM flagged unsupported → tab hidden → reinstall → same thing happens again.
The tab eventually reappeared, Cowork answered one single question, and then immediately failed again with "Prompt is too long."
Impact

Cowork is completely non-functional. I cannot complete any tasks.
This is not a one-time issue. These errors have been occurring consistently over multiple days.
The problem is escalating. It started with errors, progressed to the Cowork tab disappearing entirely, and now cycles between brief recovery and immediate failure.
Multiple error types suggest systemic instability, not a single isolated bug.
No workaround exists from my end — restarting the app, restarting my computer, clearing cache, and fully reinstalling have not resolved the issue.
Usage limits are being consumed on failed attempts, which is especially frustrating on a paid Max plan.
I cannot use Cowork for my professional work (safety consulting document analysis, report generation) which is the reason I subscribed to Max.

Steps to Reproduce
Initial errors:

Open Claude Desktop (latest version)
Switch to Cowork mode
Enter any prompt
Error appears immediately — no work is performed

Tab disappearing:

Experience the errors above repeatedly
Fully quit Claude Desktop (from system tray)
Reinstall Claude Desktop (fresh download from claude.ai/download)
Clear Claude cache
Reopen Claude Desktop
Cowork tab is completely missing from the UI

Brief recovery then immediate failure:

After further troubleshooting, Cowork tab reappears
Submit a prompt — it works for one question
Submit a second prompt — immediately fails with "Prompt is too long" Actual Behavior
Cowork fails immediately with one of the errors listed above. No task execution occurs. The errors rotate between sdk-daemon disconnections, virtiofs mount failures, connection aborts, and false "prompt too long" messages.

What Should Happen?

Cowork should accept prompts and execute tasks reliably, especially for subscribers on the highest-tier plan.

Error Messages/Logs

These are the errors I have received over the past two days. They appear immediately after submitting a prompt — Cowork does not perform any work before failing:
Error 1:
Something went wrong
sdk-daemon not connected
Error 2:
Something went wrong
Prompt is too long
(Note: My prompts are NOT too long. I am only getting 1–2 conversations in before this appears, and usually no conversation at all — just the error.)
Error 3:
Something went wrong
failed to write length: An established connection was aborted by the software in your host machine.
Error 4:
Something went wrong
RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
Error 5:
Something went wrong
sdk-daemon not connected
(Recurring — this one appears frequently.)
Error 6:
Something went wrong
Prompt is too long
(This appeared again after Cowork briefly recovered and answered one question — the very next prompt failed with this error despite being a normal-length prompt.)

Steps to Reproduce

Initial errors:

Open Claude Desktop (latest version)
Switch to Cowork mode
Enter any prompt
Error appears immediately — no work is performed

Tab disappearing:

Experience the errors above repeatedly
Fully quit Claude Desktop (from system tray)
Reinstall Claude Desktop (fresh download from claude.ai/download)
Clear Claude cache
Reopen Claude Desktop
Cowork tab is completely missing from the UI

Brief recovery then immediate failure:

After further troubleshooting, Cowork tab reappears
Submit a prompt — it works for one question
Submit a second prompt — immediately fails with "Prompt is too long"

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v1.1.4498 (24f768)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [B[BUG] Cowork Windows - RPC error -1: virtiofs/Plan9 mount fails after brief use #29587
2. [BUG] Cowork Windows — hvsock dies after idle, "connection aborted by software in host machine" (Win 11 Pro 24H2) #28309
3. [BUG] Cowork: RPC error -1 virtiofs/Plan9 mount fails with "Plan9 mount failed: bad address" #26554

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

[inchwormz]

I've this exact same issue, its infuriating. Just loses all tasks all the time. have to start again from scratch.

[Neomail2]

same here

[mathiasseredszun]

yes, have this for about a week now. Completely not usable

[gislirunar-png]

The same here spent 3 days setting up connection, n8n ect now nothing works
very frustrating

[andynewlife]

Infuriating. Windows user here. Signed up for Pro last week. Constantly hit with this error (from the original poster's list above) when trying to use Cowork. Multiple fixes implemented. Problem keeps returining

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

[garabedjunior-dotcom]

Solved: Same errors — caused by failing MCP servers

Hi @dianarude-ui, I had the exact same errors on my Windows machine:

• sdk-daemon not connected
• failed to write data: An established connection was aborted by the software in your host machine
• ProcessTransport is not ready for writing

I'm not a developer either — just a regular user. I spent hours checking Hyper-V settings, enabling HypervisorPlatform, and even uninstalling Docker Desktop. None of that fixed it.

Root Cause (in my case)

The problem was broken MCP servers configured in Claude Desktop. I had two MCP integrations that were failing on every startup:

• MCP_DOCKER — Docker Desktop was uninstalled but the MCP server was still configured, so it kept failing with "Docker Desktop is not running"
• Airtable MCP Server — was also having repeated connection issues

These failing MCP servers were crashing the VM communication pipe that Cowork depends on, causing all those sdk-daemon not connected and connection aborted errors.

The Fix (Step by Step)

Step 1 — Remove broken MCP servers:
Open Claude Desktop → Settings → Integrations / MCP Servers → Remove any MCP server that shows errors or depends on software you no longer have installed.

Step 2 — Close Claude Desktop completely:

taskkill /f /im claude.exe 2>$null

Step 3 — Clear Cowork VM cache:

Remove-Item -Recurse -Force "$env:LOCALAPPDATA\AnthropicClaude\vm-data" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:APPDATA\Claude\local-agent-mode-sessions" -ErrorAction SilentlyContinue

Step 4 — Restart VM services (PowerShell as Administrator):

Restart-Service vmcompute -Force
Restart-Service vmms -Force

Step 5 — Reopen Claude Desktop and test Cowork.

How to check if this is your issue

Run this in PowerShell to see your Claude Desktop logs:

Get-Content "$env:APPDATA\Claude\logs\*.log" -Tail 100

Look for lines like:

• Server disconnected from any MCP server
• Docker Desktop is not running
• Server transport closed unexpectedly

If you see any MCP server repeatedly failing, that's likely your culprit.

My Setup

• Windows 11 Pro 25H2
• 16 GB RAM / 1 TB SSD
• Hyper-V fully enabled
• Claude Desktop v1.1.4498

Hope this helps! After removing the broken MCP integrations and clearing the cache, Cowork has been working perfectly.

[On-Track-26]

Root Cause Identified: Surface Pro 9 VBS/HVCI Firmware Conflict — Cowork Never Works

Update — Full Diagnosis Completed (March 3, 2026)

After extensive troubleshooting with system diagnostic tools, I have identified the root cause of my Cowork failures. Posting this in detail in case it helps others and to request a fix.

---

My Environment

Item	Details
Device	Microsoft Surface Pro 9
OS	Windows 11 Home — Build 26200
Processor	Intel Core i7-1255U, 10 Cores
RAM	16 GB
WSL Version	2.6.3.0 (WSL2, Default Version: 2)
WSL Kernel	6.6.87.2-1
Claude Desktop	Latest MSIX via Microsoft Store
MCP Servers	None configured ("No servers added")
Subscription	Max Plan ($200/month)

---

Root Cause: Virtualization-Based Security (VBS) + HVCI

My msinfo32 System Information confirms the following is active and enforced at the firmware level:

Virtualization-based security:                    Running
VBS Services Running:                             Hypervisor enforced Code Integrity, SMM Firmware Measurement
App Control for Business policy:                  Enforced
Secure Boot:                                      On
Kernel DMA Protection:                            On
SMM Isolation Level:                              Firmware Protection Version Three
HypervisorPresent:                                True

The Surface Pro 9 ships with VBS and HVCI enabled by default at the hardware/firmware level (Microsoft has done this on all Surface devices since Surface Pro 7+). This permanently occupies the hypervisor layer that Cowork's VM requires to start.

This cannot be disabled by the user — it is enforced at the UEFI/firmware level on Surface hardware.

---

Error Observed

Every time Cowork is opened:

"Failed to start Claude's workspace — Request timed out"

This error appears immediately, before any task is entered. The workspace has never successfully started since subscribing.

---

Troubleshooting Already Attempted

• ✅ Confirmed no MCP servers configured (zero entries)
• ✅ Killed all 7 simultaneous claude.exe processes that were running
• ✅ Cleared local-agent-mode-sessions cache (70+ crashed session files deleted)
• ✅ Cleared claude-code-vm cache directory
• ✅ Used in-app "reinstall the workspace" option — no change
• ✅ Confirmed WSLService is running (Default Version: 2)
• ✅ Confirmed claudevm.bundle exists at the expected path
• ✅ Full Claude Desktop reinstall — no change

None of these resolved the issue.

---

Connection to Other Issues

This appears to be the same underlying VM startup failure reported in:

• [BUG] Cowork VM never creates on Windows — connection timeout + macOS diagnostics running on Windows #25474 — "Cowork VM never creates on Windows — connection timeout"
• [BUG] Cowork - Unable to connect to Claude API on Windows (ECONNRESET / Request timed out) #26567 — "Unable to connect to Claude API on Windows (Request timed out)"

The common thread across all these reports: Cowork's VM cannot initialize on Windows machines where the hypervisor layer is already occupied, whether by VBS/HVCI (Surface Pro and many modern Windows 11 PCs) or other configurations.

Additionally, issue #25474 identified that after the VM timeout, Cowork runs macOS diagnostic commands (/sbin/ifconfig, /usr/sbin/scutil, === Comprehensive macOS Diagnostics ===) on Windows — suggesting the Windows implementation may be incomplete.

---

Request

1. Confirm whether Cowork is compatible with Windows 11 Home on Surface Pro 9 hardware with VBS/HVCI enforced
2. Provide a fix or workaround for the VBS/HVCI conflict — ideally Cowork should be able to run alongside Windows security features, not require them to be disabled
3. Update product documentation to disclose Surface Pro and VBS/HVCI compatibility limitations so subscribers know before purchasing
4. Issue a credit or refund for the period Cowork has been non-functional on a paid Max plan subscription

This affects a significant number of users — Surface Pro is one of the most common professional Windows devices, and VBS is now enabled by default on all modern Windows 11 hardware.

---

Diagnosed March 3, 2026. Full system diagnostic report available on request.

[inchwormz]

Root Cause Found: knowledge-work-plugins marketplace re-install crashes VM on second task

Summary

After applying the MCP server fix from @garabedjunior-dotcom (removing broken MCP servers + clearing VM cache), Cowork's first task works perfectly. But the second task always crashes with sdk-daemon not connected. The root cause is a marketplace re-install conflict inside the Cowork VM.

Evidence from logs

File: %APPDATA%\Claude\logs\cowork-service.log

Every time a new Cowork task starts, the VM tries to add the knowledge-work-plugins marketplace. On the first task after a clean reset, this succeeds. On the second task, the marketplace is already installed, and the initialization crashes:

Task 1 (works):

07:48:40 [RPC] Server started, waiting for sdk-daemon connection on port 51234
07:48:46 [RPC] sdk-daemon connected from VM 960e110c-fc59-5b4b-843d-68737d617893
07:48:46 [RPC] sdk-daemon is ready
07:48:46 [VM] sdk-daemon is ready!

Task 2 (crashes):

07:24:43 [VM] stdout[9a29cdf0]: {"type":"control_request",...,"subtype":"mcp_message","server_name":"plugins","message":{"method":"tools/list"}}
07:24:43 [RPC] Read error: failed to read length: EOF
07:24:43 [RPC] sdk-daemon disconnected

Marketplace conflict (stderr from cowork_vm_node.log):

07:24:49 stderr[cli-09c65a8f]: ✘ Failed to add marketplace: Marketplace 'knowledge-work-plugins' is already installed.
                               Please remove it first using '/plugin marketplace remove knowledge-work-plugins' if you want to re-install it.
07:24:49 [RPC] Process cli-09c65a8f exited: code=0xc001218570 signal=<nil>

Then the VM dies completely:

07:24:52 [RPC] Read error: failed to read length: An established connection was aborted by the software in your host machine.
07:24:52 [RPC] sdk-daemon disconnected
07:24:52 [VM] Warning: failed to close system handle: HcsCloseComputeSystem failed with HRESULT 0x7ffd027741f0

This is 100% reproducible

This exact sequence appears every time a second task is started:

• 03/03 17:00:03 — same marketplace error, same crash
• 03/04 06:55:18 — same marketplace error, same crash
• 03/04 07:24:49 — same marketplace error, same crash

The bug

The VM initialization code calls plugin marketplace add knowledge-work-plugins on every new task. But the marketplace persists in sessiondata.vhdx across tasks. So the second task finds it already installed, the add command fails, the CLI process crashes with a non-zero exit code, and this corrupts the RPC pipe — killing the sdk-daemon connection.

Suggested fix

Either:

1. Skip marketplace add if already installed (check before adding)
2. Use --force or equivalent to overwrite existing marketplace
3. Don't persist marketplace state across tasks in sessiondata.vhdx

Current workaround

Delete sessiondata.vhdx before each Cowork session:

Stop-Process -Name claude -Force
Remove-Item -Force "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"
Remove-Item -Recurse -Force "$env:APPDATA\Claude\local-agent-mode-sessions\*"
Remove-Item -Recurse -Force "$env:APPDATA\Claude\claude-code-vm\*"
# Then relaunch Claude Desktop

This works for the first task, but must be repeated every time you want a second task.

Setup

• Windows 11 Home 26200
• Claude Desktop v1.1.4498 (Windows Store)
• 16 GB RAM
• VirtualMachinePlatform + HypervisorPlatform enabled

[Karasowl]

Same issue here. Details below:

OS: Windows 11 Home, Build 26200
Claude Desktop version: 1.1.4498
Plan: Pro
Windows Features: VirtualMachinePlatform ✅, HypervisorPlatform ✅, Hyper-V ❌ (not available on Home)

Behavior:

~1 week ago: Cowork would crash intermittently but restarting the app usually restored it for 3-4 messages
Now: Completely unusable. VM starts, network connects, API shows reachable, then sdk-daemon not connected within ~20 seconds. Restarting no longer helps.
The problem is getting worse with each update, not better.

[JesperLive]

If you're hitting this on Windows, I built an automated fix toolkit that handles the full reset cycle (kill processes → purge VM cache → restart service → relaunch) without rebooting: https://github.com/JesperLive/ClaudeFix

Also includes a background health monitor that detects mount failures and auto-fixes them. Details in the README.