[BUG] Claude Desktop on Windows — Cowork connection errors after session crash
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?
After Claude Desktop on Windows crashes and is restarted, two distinct errors appear in Cowork:
Error 1 — Connection aborted:
failed to write length: An established connection was aborted by the software in your host machine.This error occurs after a crash, indicating the Cowork connection was forcibly terminated by the Windows host machine.
Error 2 — Process already running:
RPC error -1: process with name "blissful-sharp-gates" already running (id: fe1af3ed-5734-4202-8992-8c8b7d1491d7)This error occurs when trying to restart Cowork after a crash. The previous session's background process did not shut down cleanly, so when a new session tries to start, it conflicts with the orphaned process still running.
Context:
These errors appear to be downstream effects of the crash/instability issue reported in issue #27710. After each crash, the Cowork VM process is left in an inconsistent state — the connection is dropped (Error 1) and the process remains running (Error 2), preventing a clean restart without a full system reboot.
What Should Happen?
Claude Desktop should either recover gracefully after a crash without leaving orphaned processes, or provide a mechanism to cleanly kill the existing Cowork session so a new one can start without requiring a full system reboot.
Error Messages/Logs
Steps to Reproduce
- Use Claude Desktop on Windows with Cowork enabled
- App crashes during normal use (see related issue #27710)
- Attempt to restart Claude Desktop / Cowork
- Error 1 appears: "failed to write length: An established connection was aborted by the software in your host machine."
- Error 2 appears: "RPC error -1: process with name "blissful-sharp-gates" already running (id: fe1af3ed-5734-4202-8992-8c8b7d1491d7)"
- Cowork cannot be restarted — a full system reboot is required to clear the orphaned process
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Unknown (Claude Desktop on Windows)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_
11 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Same two issues for me.
same issue for me
Same issue here - searched for it, hoping there was a fix!
RPC error -1: process with name "clever-gracious-shannon" already running (id: xxxxxxxxxxxxxxxxxxxx)
Same issue, I'm a Max user. Have to restart Claude Cowork up to a dozen times a day via Windows Services as it keeps crashing.
Happens to me as well, have to keep shutting down the process via powershell
The issue happens for me when Cowork tries to launch an Eleventy server
Environment:
OS: Windows 11
Claude Desktop: latest
Plan: Max
What's Wrong:
When you stop a Cowork generation mid-task using the stop button, the VM session does not terminate cleanly. It gets stuck in a zombie state, and all subsequent Cowork attempts fail with one of these errors:
RPC error -1: process with name "X" already running (id: Y)
VM service not running. The service failed to start.
Steps to Reproduce:
Open Cowork and start any task
Hit the stop button before it completes
Try to start a new Cowork session
Observe the error
Expected: Session terminates cleanly, new sessions start normally
Actual: Zombie session blocks all new sessions until manually cleared
Workaround that actually helps me (make sure youre running power shell on admin) :
powershellStop-Process -Name "vmwp","vmcompute","cowork-svc","Claude" -Force -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Claude\local-agent-mode-sessions\*" -Force -ErrorAction SilentlyContinue
Start-Sleep -Seconds 3
Start-Service CoworkVMService
Then relaunch Claude Desktop.
Related issues: #27801, #25206, #29045
Workaround: cowork-session-fixer plugin
We built a Claude Cowork plugin that detects and fixes this — stuck sessions with orphaned
vmProcessNameentries causingRPC error: process with name "X" already running.Install from the MSApps plugin marketplace: cowork-session-fixer
SOSA Level 3 compliant — scans session state files, presents findings, and archives with user confirmation. Works on macOS and Windows.
Suggestion to Anthropic: Add automatic cleanup of orphaned session state files on app startup, or expose a "force close session" option in the UI.
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.