[BUG] Cowork completely unusable on Windows — recurring VM crashes, tab disappearing, and brief recovery followed by immediate failure (Max plan subscriber)
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?
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_
16 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I've this exact same issue, its infuriating. Just loses all tasks all the time. have to start again from scratch.
same here
yes, have this for about a week now. Completely not usable
The same here spent 3 days setting up connection, n8n ect now nothing works
very frustrating
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
Solved: Same errors — caused by failing MCP servers
Hi @dianarude-ui, I had the exact same errors on my Windows machine:
sdk-daemon not connectedfailed to write data: An established connection was aborted by the software in your host machineProcessTransport is not ready for writingI'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:
"Docker Desktop is not running"These failing MCP servers were crashing the VM communication pipe that Cowork depends on, causing all those
sdk-daemon not connectedandconnection abortederrors.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:
Step 3 — Clear Cowork VM cache:
Step 4 — Restart VM services (PowerShell as Administrator):
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:
Look for lines like:
Server disconnectedfrom any MCP serverDocker Desktop is not runningServer transport closed unexpectedlyIf you see any MCP server repeatedly failing, that's likely your culprit.
My Setup
Hope this helps! After removing the broken MCP integrations and clearing the cache, Cowork has been working perfectly.
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Root Cause Identified: Surface Pro 9 VBS/HVCI Firmware Conflict — Cowork Never Works</h1>
<h2>Update — Full Diagnosis Completed (March 3, 2026)</h2>
<p>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.</p>
<hr>
<h2>My Environment</h2>
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)
<hr>
<h2>Root Cause: Virtualization-Based Security (VBS) + HVCI</h2>
<p>My <code>msinfo32</code> System Information confirms the following is <strong>active and enforced at the firmware level</strong>:</p>
<pre><code>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
</code></pre>
<p>The Surface Pro 9 ships with VBS and HVCI <strong>enabled by default at the hardware/firmware level</strong> (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.</p>
<p><strong>This cannot be disabled by the user</strong> — it is enforced at the UEFI/firmware level on Surface hardware.</p>
<hr>
<h2>Error Observed</h2>
<p>Every time Cowork is opened:</p>
<blockquote>
<p><strong>"Failed to start Claude's workspace — Request timed out"</strong></p>
</blockquote>
<p>This error appears <strong>immediately</strong>, before any task is entered. The workspace has <strong>never successfully started</strong> since subscribing.</p>
<hr>
<h2>Troubleshooting Already Attempted</h2>
<ul>
<li>✅ Confirmed no MCP servers configured (zero entries)</li>
<li>✅ Killed all 7 simultaneous <code>claude.exe</code> processes that were running</li>
<li>✅ Cleared <code>local-agent-mode-sessions</code> cache (70+ crashed session files deleted)</li>
<li>✅ Cleared <code>claude-code-vm</code> cache directory</li>
<li>✅ Used in-app <strong>"reinstall the workspace"</strong> option — no change</li>
<li>✅ Confirmed <code>WSLService</code> is running (<code>Default Version: 2</code>)</li>
<li>✅ Confirmed <code>claudevm.bundle</code> exists at the expected path</li>
<li>✅ Full Claude Desktop reinstall — no change</li>
</ul>
<p><strong>None of these resolved the issue.</strong></p>
<hr>
<h2>Connection to Other Issues</h2>
<p>This appears to be the same underlying VM startup failure reported in:</p>
<ul>
<li>#25474 — "Cowork VM never creates on Windows — connection timeout"</li>
<li>#26567 — "Unable to connect to Claude API on Windows (Request timed out)"</li>
</ul>
<p>The common thread across all these reports: <strong>Cowork's VM cannot initialize on Windows machines where the hypervisor layer is already occupied</strong>, whether by VBS/HVCI (Surface Pro and many modern Windows 11 PCs) or other configurations.</p>
<p>Additionally, issue #25474 identified that after the VM timeout, <strong>Cowork runs macOS diagnostic commands</strong> (<code>/sbin/ifconfig</code>, <code>/usr/sbin/scutil</code>, <code>=== Comprehensive macOS Diagnostics ===</code>) on Windows — suggesting the Windows implementation may be incomplete.</p>
<hr>
<h2>Request</h2>
<ol>
<li><strong>Confirm</strong> whether Cowork is compatible with Windows 11 Home on Surface Pro 9 hardware with VBS/HVCI enforced</li>
<li><strong>Provide a fix or workaround</strong> for the VBS/HVCI conflict — ideally Cowork should be able to run alongside Windows security features, not require them to be disabled</li>
<li><strong>Update product documentation</strong> to disclose Surface Pro and VBS/HVCI compatibility limitations so subscribers know before purchasing</li>
<li><strong>Issue a credit or refund</strong> for the period Cowork has been non-functional on a paid Max plan subscription</li>
</ol>
<p>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.</p>
<hr>
<p><em>Diagnosed March 3, 2026. Full system diagnostic report available on request.</em></p></body></html><!--EndFragment-->
</body>
</html>
Root Cause Found:
knowledge-work-pluginsmarketplace re-install crashes VM on second taskSummary
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.logEvery time a new Cowork task starts, the VM tries to add the
knowledge-work-pluginsmarketplace. 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):
Task 2 (crashes):
Marketplace conflict (stderr from
cowork_vm_node.log):Then the VM dies completely:
This is 100% reproducible
This exact sequence appears every time a second task is started:
03/03 17:00:03— same marketplace error, same crash03/04 06:55:18— same marketplace error, same crash03/04 07:24:49— same marketplace error, same crashThe bug
The VM initialization code calls
plugin marketplace add knowledge-work-pluginson every new task. But the marketplace persists insessiondata.vhdxacross 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:
--forceor equivalent to overwrite existing marketplacesessiondata.vhdxCurrent workaround
Delete
sessiondata.vhdxbefore each Cowork session:This works for the first task, but must be repeated every time you want a second task.
Setup
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.
<img width="812" height="342" alt="Image" src="https://github.com/user-attachments/assets/98051b9f-7343-4a1a-bc10-71b858a9ca89" />
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.
I am using the latest version of Claude Code
I am experiencing the exact same issue described in this report. Cowork fails immediately upon submitting any prompt with the RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address error. The error is recurring and persistent — restarting does not provide a lasting fix.
This is happening on a Max 20x subscription. A product that is central to this tier is completely non-functional, which is unacceptable given the cost of the plan.
I would like to know whether a fix is actively being worked on and what the expected timeline is. This is not a minor inconvenience — it renders a paid feature entirely unusable.
Same issue here. Windows 11 Pro, Claude Desktop Cowork. The error keeps coming back after restarting — makes Cowork unreliable for daily use.
Man the few times I had this working it was amazing, but I was getting this bug intermittently, and just tried reinstalling the desktop app as the app suggested to do, and now I get no Cowork tab at all anymore (which is what I desperately want to be using).
I just can't believe this would be allowed by this company. I want to have so much respect for what they are doing. I support Dario and respect what Anthropic is doing generally. But how can you support, respect and "be ok" when you have hours into setup of an application promising and beginning to transform your life, and then it's like "Nope!"...every time you touch it it works worse and worse? Like, I'm trying to get work done. I don't know what to do with this now. Well, now it just doesn't work, so I need to go back to the old way I was doing things and hope they get this fixed some day I guess.
They need to get major resources on this instantly or they are going to have hoards mass exodus like they did recently to ChatGpt 5.2 that brought so many to them in the first place.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.