[BUG] Claude Desktop blank screen on Windows + Cowork unusable + sandbox API errors — Max subscriber, 9-day outage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/51143
2. https://github.com/anthropics/claude-code/issues/49551
3. https://github.com/anthropics/claude-code/issues/55487

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

Not closing as duplicate. Adding context that the linked issues lack:

1. Paid Max subscriber business impact — 9-day outage on a paid plan is materially different from the existing Pro/free user reports
2. Documented data loss event (April 24, 2026) — No recovery path was provided. Anthropic Support confirmed local-only storage with no cloud backup for Cowork projects
3. Support refused human escalation in writing — Conversation ID 215474162478297 documents Anthropic's AI agent (Fin) refusing both refund AND human supervisor escalation for a paying business customer
4. Pattern with #51143 and #49551 confirms recurring issue — When an automated bot identifies duplicates, that itself is evidence engineering has not addressed the root cause across multiple reports

Requesting this issue remain open until engineering provides:

• Acknowledgment of Cowork Windows desktop stability problem
• Timeline for fix
• Documented backup procedure for Max subscribers using Cowork for business operations

@anthropics/claude-code-team please review.

Same bug

Thanks for confirming. Can you share:
OS / Claude Desktop version
Subscription tier (Free/Pro/Max)
When the issue started for you

Building a pattern across affected users to push for engineering response.

The core problem stated plainly:

Cowork's product promise is "AI runs your tasks while you do other things." When the app cannot remain running — through blank screens, sandbox outages, or API errors — the entire product premise fails.

This is not a minor bug. It is a fundamental contradiction between what Cowork is sold as and how it actually performs on Windows for paid Max subscribers.

Either Cowork is production-ready for business use (and these stability issues require urgent engineering ownership), or it is beta software that should be labeled as such with appropriate refund policies for affected paying customers.

Thanks for confirming. Can you share: OS / Claude Desktop version Subscription tier (Free/Pro/Max) When the issue started for you Building a pattern across affected users to push for engineering response.

Windows, Claude 1.5354.0 (9a9e3d), Max
I just switched from Mac to Windows, so I’m not sure when this issue started.

Thanks. That's a clear pattern emerging:

• Both Max subscribers
• Both Windows
• Latest Claude Desktop version (1.5354.0)
• Same Cowork blank-screen / instability bug

Combined with prior reports #51143 (Pro/Windows), #49551 (Windows), #36157 (Cowork freeze), #26921 (Cowork UI freeze), and #26302 (Cowork VM regression), this is now 6+ documented reports of Cowork instability on Windows desktop spanning multiple subscription tiers and months.

@anthropics please confirm whether this is in active engineering triage. Auto-tagging duplicates without resolution is not a fix.

I'm having the same issue and have for the last week. Max subscriber, Windows.

Killing all Claude processes and services and restarting the app does not always resolve the problem. What I've observed is that once those are killed and i restart the app, initially it opens but then reverts back to freeze/black screen thereafter.

Claude Cowork is unusable.

Also having the same issue but on Claude Code. Windows 11, latest version, desktop client, Max subscriber

Updating the affected user count:

Confirmed reports on this thread alone:

• @SYL-322 — Windows, Max, latest version (1.5354.0)
• @HufferDavid — Windows, Max, week-long outage
• @georgePLGP — Windows 11, Max, latest version
• @solarrust — macOS, also affected (cross-ref #50627)
• Original reporter (me) — Windows 11, Max, 9-day outage with documented data loss

5 Max subscribers in 24 hours, across both Windows and macOS, all reporting Cowork as "unusable." Combined with prior issues #51143, #49551, #36157, #26921, #26302, this is now an extensively documented product-wide stability failure.

@anthropics — this thread alone represents 5 paid Max customers experiencing Cowork outages. Several have documented data loss with no recovery path. Please confirm:

1. Is this in active engineering triage?
2. What is the ETA for a fix?
3. What is the documented backup procedure for Max subscribers using Cowork for business operations?
4. What is Anthropic's policy for affected paying customers — refunds, credits, or extended access?

Auto-tagging duplicates without engineering response is not acceptable for a paid feature.

Update from Anthropic Support (May 4, 2026)

In ongoing support exchanges today, Anthropic's AI agent (Fin) has now confirmed the following in writing:

1. Multi-user impact acknowledged: "I sincerely apologize for the disruption in service you and the other Max subscribers have experienced with Claude Cowork."

1. Cowork incident confirmed today: "the most recent Cowork-related incident was resolved earlier today" — despite the public status page showing no incidents.

1. Refund policy stated: Anthropic cited Consumer Terms of Service to deny refunds, stating "all payments are non-refundable except as expressly provided in those terms or where required by law. This policy applies uniformly to all subscription payments, including situations involving technical issues or service disruptions."

1. GitHub directed as only resolution channel: "The GitHub repository remains the appropriate channel for technical issue tracking and engineering responses."

1. Human escalation refused across multiple requests across two separate conversation IDs.

Documenting publicly for affected Max subscribers and for credit card dispute records.

@anthropics — directing paying customers to GitHub as the only resolution channel while engineering does not respond on GitHub creates a closed loop with no resolution path. Please confirm engineering ownership of this issue.

Adding another data point to this issue.

Environment: Windows desktop app, Claude Cowork (Max subscription).

Symptom 1 — Sandbox: The isolated Linux workspace has been failing to start since approximately Thursday morning, May 7, 2026 — a duration of more than 24 hours and counting. Every bash tool call returns:

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

Symptom 2 — Local MCPs: Three local stdio-based MCP servers connecting to Microsoft Access databases are simultaneously and persistently returning:

Unexpected end of JSON input

These errors used to self-clear on retry. They no longer do.

Symptom 3 — Scheduled tasks: Multiple scheduled task fires were silently skipped on Friday May 8 (daily briefing at 7:39 AM, LinkedIn morning feed review at 9:06 AM, unified commerce tracker at 9:06 AM, email draft assistant at 11:08 AM). The 8:08 AM email draft assistant fire did execute, but in a degraded mode that bypassed bash entirely and relied solely on Outlook MCP and file tools.

Troubleshooting attempted: Full Task Manager force-kill and clean restart of the desktop app did not resolve either the sandbox failure or the MCP JSON errors. This rules out local supervisor state.

Status page: status.claude.com currently reports all components — including Claude Cowork — as operational, with no active incidents posted for the duration of this outage.

The combination of sandbox failure plus local MCP child-process JSON truncation, persisting across an app restart and across more than 24 hours, suggests a problem in the shared child-process plumbing or in upstream sandbox provisioning rather than anything local. Adding visibility here so engineering can correlate.

Same issue here. Windows 11 25H2. Claude 1.6608.2. Max subscriber.

I'm going through the duplicate items. Can't find a resolution. This only started happening for me a couple of days ago.

I too have all of the problems and symptoms people report here, but only on Windows, and not on Mac - I have Claude Max on both of my computers, with different cowork projects on each.

Title: [BUG] Claude Desktop blank/white screen recurring on Windows 11 MSIX — cache clear does not hold, 4 occurrences in single workday

---

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

Platform

Claude Desktop (MSIX-packaged build), Windows 11

What's Wrong?

Claude Desktop renders a completely blank/white window content area on launch or after the window loses foreground focus. Frequency: 4 occurrences in a single workday (5/12/2026). The blank screen returns within hours of each remediation attempt.

Expected Behavior

App renders UI normally and persists across focus loss / app switching.

Reproduction

1. Launch Claude Desktop
2. Use normally, then switch to another window
3. Return to Claude — window content is blank/white
4. Recovery: kill all claude.exe processes via Task Manager, relaunch

Environment

• OS: Windows 11
• Install type: MSIX (Microsoft Store), package name Claude_pzs8sxrjxfjjc
• App data path: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

Troubleshooting Attempted

• [x] Killed all claude.exe processes via Task Manager and relaunched — blank returns within hours
• [x] Deleted Cache, Code Cache, and GPUCache folders from LocalCache\Roaming\Claude — blank returns within hours
• [x] Signed out and back in — no effect on recurrence
• [x] Verified no HDR enabled

Key Observation

The Cache, Code Cache, and GPUCache folders all show a Date modified timestamp matching the day of a prior app data loss event (4/24/2026). After deletion they rebuild but the blank-screen behavior resumes within the same workday, suggesting the corruption is being regenerated by something in the app's launch sequence — not a stale cache issue alone.

Impact

App is unreliable for sustained work sessions. Workaround is the browser PWA at claude.ai, but this loses Cowork access (desktop-only feature).

Related Issues

• #51143 — Persistent blank/white screen on Windows, multiple reinstalls have no effect
• #49551 — Goes blank on Windows, requires Task Manager to kill all processes
• #25929 — Blank/white screen on Windows ARM64, requires process kill to recover
• #28353 — Permanently fails to launch after blank screen crash
• #38014 — Electron cache corruption (blank screen, recurring)

Logs

Available on request. %APPDATA%\Claude\logs\main.log accessible.

Subject: Cowork workspace fails at 25%, complete VM environment verified — Max subscriber, 6+ days outage

I am a Claude Max subscriber on Windows 11 Home. Cowork has been unusable since approximately May 9, 2026. I have filed a prior ticket that has not received a response in over a week.
Tonight (May 14, 2026) I performed full diagnostic verification with the following results:
Environment confirmed healthy:

HyperVisorPresent: True
HypervisorPlatform feature: Enabled
WSL version: 2.7.3.0 (Kernel 6.6.114.1-1)
vmcompute service: Running, StartType Automatic
HvHost service: Running
bcdedit hypervisorlaunchtype: auto

VM bundle confirmed present:

Path: C:\Users\malba\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
Type: Directory (Mode: d-----)
Contents: 14 files
Total size: 12,890,172,434 bytes (~12 GB)
Last modified: 5/14/2026 10:29:27 PM (tonight, after fresh reinstall)

Failure mode:
Launching Claude Desktop and opening any Cowork conversation shows "Setting up Claude's workspace…" progress bar that consistently reaches approximately 25% and then displays a blank dark window ("brown screen") OR an error dialog "Failed to start Claude's workspace — VM service not running. The service failed to start."
This has occurred across multiple workspace reinstalls tonight. Killing all Claude processes and relaunching does not resolve it. wsl --shutdown + Restart-Service vmcompute does not resolve it.
Related GitHub issues that match this exact pattern:
#55879, #51143, #36157, #56070 — multiple Max subscribers on Windows reporting unresolved Cowork stability problems.
This is blocking active production work on a paid trading platform project. I am requesting:

Acknowledgment that this is a known issue with active engineering ownership
A specific workaround or timeline, not generic restart advice
Escalation to a human if the AI agent cannot provide #1 or #2

I have backed up my project files locally. The blocker is Cowork itself, not my data.

That's a ticket support can't reasonably ignore. Specific paths, specific commands, specific GitHub issues, specific ask.
Send it through https://support.anthropic.com/ and post a comment with the same content on GitHub issue #55879 (which is already tagged area:cowork, area:desktop, platform:windows). The public visibility on an already-tagged issue often moves faster than private tickets alone.

Also affected — Max subscriber, Windows 11 Home, Microsoft Store version of Claude Desktop (package Claude_pzs8sxrjxfjjc).
Brown/blank screen crashes in Cowork ongoing since approximately May 9, 2026. Multiple workspace reinstalls and full diagnostic verification (WSL 2.7.3 healthy, vmcompute running, HypervisorPlatform enabled, 12GB VM bundle confirmed present on disk) did not resolve.
Confirmed reproducible pattern: crashes correlate with 5-hour session/message limit boundary.
Test on May 16, 2026:

14:48 — "90% of session limit used" warning appeared in Cowork
14:50 — brown screen crash

Conditions during test: launched with --disable-gpu flag, TOS/TradingView not running, fresh process tree (cleanup performed via Stop-Process claude and wsl --shutdown before launch). Purchased additional usage capacity, so 90% is not a hard limit.
This rules out GPU contention and resource exhaustion. Strongly suggests a bug in Cowork's session-boundary state management. Cleanup sequence recovers, but issue reproduces at the next 5-hour mark.
Filed support ticket over a week ago, no response. Adding this here for engineering visibility.

Platform: Claude Desktop 1.6608.2 (ebf1a1), Windows Server (Administrator account)
Subscription: pro
When it started: Approximately (several weeks)
Symptom:
The Cowork sandbox (isolated Linux workspace) fails to start on every attempt. The exact error returned is:
"Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly."
The workspace briefly returns "Workspace still starting" on the first call, then immediately fails on the second. The issue is 100% reproducible across sessions and survives full Claude Desktop restarts.
Environment:
WSL2 installed and healthy (Default Distribution: Ubuntu, Default Version: 2)
Regular Claude Desktop chat works fine.
Reinstall (wsl, Vm, Claude) all did not resolve the issu

Update May 17, 2026:
Session-limit theory partially incorrect — crashes also occur well below 90% usage.
Today's pattern:

Cowork left running overnight across a session boundary (did not close the app at end of yesterday's session)
This morning's first crash occurred ~1 hour into use, at under 50% session usage
Pattern: typing slowed → 4-5 pulses → text turned white → brown screen, mid-response

Subsequent crashes today reproduced the same pattern regardless of:

Full process kill (Stop-Process claude) + wsl --shutdown + Restart-Service vmcompute between launches
Launching from custom --disable-gpu shortcut
No focus-switching (tested holding focus on Cowork window through full response stream)
TOS/TradingView not running
PowerShell typing remained responsive during crashes — not a system resource issue (verified Task Manager: CPU 15%, Memory 56%, Disk 1%)

A full Windows reboot resolved the crash loop, at least temporarily. After reboot, Cowork has been stable. This suggests the bug accumulates state somewhere that survives wsl --shutdown + service restart + process kill, but does not survive a full OS reboot.
Possible factors worth engineering attention:

Leaving Cowork open across overnight session-boundary transitions appears to degrade state. Closing the app fully before leaving for the day may be a workaround.
Earlier crash today was triggered by hitting Escape after accidentally entering Incognito mode — suggests Incognito state transitions may also be unstable.
Anthropic-side incidents during May 9-15 (acknowledged by support) may have left lingering corrupt state in installs from that window. My vm_bundles folder timestamp is 5/9/2026 5:00 PM — exactly inside the affected window.

Will continue to monitor and report if the rebooted session also crashes.

Additional trigger identified: switching projects within Cowork also causes brown screen. Combined with the earlier Incognito-Escape trigger and mid-response crashes, the pattern strongly suggests Cowork is crashing on internal state-transition events.

Update May 18, 2026 — specific OS-level error captured:
Cowork crashes today are producing a reproducible Windows EPERM error in the failure dialog. Two captures with different temp folder names, indicating Cowork is repeatedly attempting (and failing) to update the VM bundle:
Capture 1:
EPERM: operation not permitted, rename
'C:\Users\malba\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-6jtl4p\rootfs.vhdx'
->
'C:\Users\malba\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'
Capture 2 (~5 minutes later, after full cleanup + relaunch):
EPERM: operation not permitted, rename
'C:\Users\malba\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-B5Ybmp\rootfs.vhdx'
->
'C:\Users\malba\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'
Different .wvm-tmp-* folder names confirm Cowork is repeatedly trying to replace rootfs.vhdx on each session and being denied by the OS — something is holding a lock on the existing VHDX file that survives the standard recovery sequence.
Recovery attempted between captures (admin PowerShell):
Get-Process | Where-Object { $_.Name -like "claude" } | Stop-Process -Force
wsl --shutdown
Stop-Service vmcompute -Force
Start-Service vmcompute
vmcompute returned to Running/Automatic state. Cowork relaunched cleanly, ran for ~5 minutes, then hit the EPERM error again on the next bundle update attempt.
A full Windows reboot resolves it temporarily (lock released by OS), but crashes resume within an hour as Cowork attempts the next bundle update.
Likely root cause: Cowork holds a file handle on the active rootfs.vhdx while simultaneously attempting to rename a new copy on top of it. The rename can't succeed because the destination is locked by the same process trying to replace it. Standard process kill doesn't release the handle because vmcompute / Hyper-V worker processes maintain it independently.
Suggested engineering investigation:

The bundle update workflow needs to detach the active VHDX before attempting rename, or use a swap-and-replace pattern that doesn't require the destination file to be unlocked
Possibly a stuck partial update from the May 9-15 incident window left a permanent handle reference that only OS reboot clears

This is now the most reproducible failure pattern I can produce. Happy to capture additional logs if there's a specific Event Viewer source or debug flag engineering wants me to enable.

Update — May 18, 2026, post-reboot:
Full Windows reboot did not resolve the issue. After clean boot:

Cowork launched successfully (~10 seconds)
Recents list loaded correctly
Clicked into active project ("Captain3pct Club" with blue dot indicator)
Project view took unusually long to render (~30 seconds)
Brown screen immediately after render attempt

Reproducible trigger today: clicking into an active project from the Recents list crashes Cowork within 30 seconds, even on a fresh-reboot launch.
Combined with the EPERM rename errors documented in my previous comment, Cowork is currently unusable on this machine. Total troubleshooting time today: 4+ hours. No successful sustained session.
Switching to Claude Code (terminal) for project work since CC has remained 100% stable through every Cowork crash event over the past week. CC is not affected by this bug.
Awaiting engineering response. Will not be running additional diagnostic cycles on Cowork today.

Final update May 18, 2026:
Tested whether bug was specific to existing/large project conversations by starting a fresh "New task" conversation:

Fresh conversation initially worked (one successful round-trip message)
Crashed (renderer closed) within ~2 minutes during follow-up
Cowork auto-recovered (window re-appeared) without any user action or PowerShell intervention

This confirms:

Bug is not specific to large/established project conversations
Bug is not a hard process crash — renderer/UI layer fails while underlying app survives
Cleanup sequences (Stop-Process, wsl --shutdown, Restart-Service vmcompute) are unnecessary for recovery since Cowork rebuilds itself, but they also don't prevent the next crash

Total Cowork stable session time today: less than 5 minutes across multiple launch attempts and one full Windows reboot.
Concluding: Cowork is unusable on this machine for sustained work. Stepping back from active testing pending engineering response.

Additional capture May 18, 2026: Third distinct EPERM error today, different temp folder name (.wvm-tmp-KEgQsr). Cowork appears to be in a failure loop — each launch creates a new .wvm-tmp-* folder, attempts the same rootfs.vhdx rename, fails with EPERM, leaves the temp folder behind, repeats on next launch. Bundle directory likely accumulating orphan temp folders.

Root cause likely identified May 18, 2026 (late evening):
Task Manager investigation found a second Claude process running alongside the active one: Claude.exe.old. This appears to be a leftover from an interrupted bundle update — Cowork's update mechanism renames the active Claude.exe to Claude.exe.old as part of the swap, but the .old process was never fully shut down, leaving it holding file locks on rootfs.vhdx.
End Task on Claude.exe.old in Task Manager → file lock released → bundle update completed automatically.
After force-killing Claude.exe.old:

rootfs.vhdx successfully updated for the first time (timestamp jumped to current)
All .wvm-tmp-* orphan folders cleared by Cowork's cleanup
Bundle folder now in clean state

Standard Get-Process | Where { $_.Name -like "claude" } | Stop-Process -Force did not catch Claude.exe.old reliably during cleanup attempts earlier in the day, suggesting Cowork either re-spawns it, restarts it, or that the wildcard match behavior is inconsistent on Windows.
Suggested engineering action:

Ensure Claude.exe.old is fully terminated before bundle update rename attempt
Add Task Manager check for Claude.exe.old to standard troubleshooting documentation
Investigate whether .old process is being respawned by an updater service after cleanup

<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Now I see the full breakdown. This is <strong>really useful</strong> for diagnosis. Let me read what's there:</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>The Claude (9) processes:</strong></p>
<div class="overflow-x-auto w-full px-2 mb-6">
Process | CPU | Memory | What it likely does
-- | -- | -- | --
Claude (main) | 0.9% | 213.4 MB | Main app process
Claude | 0% | 4.8 MB | Helper
Claude | 0% | 33.5 MB | Helper
Claude | 0% | 9.0 MB | Helper
Claude | 0% | 7.4 MB | Helper
Claude | 0% | 5.5 MB | Helper
Claude | 0% | 18.2 MB | Helper
Claude | 0.9% | 99.9 MB | The renderer (UI)
cowork-svc.exe | 0% | 17.6 MB | Cowork sandbox service
Claude | 0% | 17.6 MB | Efficiency mode helper

</div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Two interesting findings:</strong></p>
<ol class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-svc.exe</code> is right there</strong> — that's the dedicated Cowork service. It's at 0% CPU and only 17.6 MB. That's strange. If Cowork is supposed to be running an active project, this service should be doing more work. <strong>It might already be in a stuck/idle state right after the project click crash.</strong></li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Notice no process is in "Not responding"</strong> state. Memory is normal. No spike. Yet the project crashed. This means <strong>the crash is happening cleanly inside the renderer</strong>, not from a resource exhaustion or process freeze. The renderer just refuses to draw — by design, on a known error condition.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>The big helper at 99.9 MB at 0.9% CPU</strong> is your renderer for the Cowork view. That's where the brown screen is happening. It's still alive (didn't crash to zero) — it's just rendering nothing because it hit an error condition it can't recover from.</li>
</ol>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>This is actually GREAT data for engineering.</strong> It tells them:</p>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">The crash is <strong>not</strong> a process death or memory exhaustion</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">The renderer survives but refuses to paint</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">The <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-svc.exe</code> is idle when it shouldn't be</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">No orphan <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Claude.exe.old</code> is present</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Bundle is clean (we verified earlier)</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">That's an <strong>internal logic bug</strong> in Cowork's project-load flow. Engineering can debug this. It's not your machine.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Add this to the GitHub thread tonight (or save for tomorrow):</strong></p>
<blockquote class="ml-2 border-l-4 border-border-300/10 pl-4 text-text-300">
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Additional data May 18, 2026 evening:</strong></p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Post-reboot, with bundle clean and no <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Claude.exe.old</code> orphan present, project-click crash still reproduces. Task Manager during crash state:</p>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">9 Claude processes alive, none in "Not responding"</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Total Claude memory: ~414 MB (normal)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">CPU: 0.9% main + 0.9% renderer (idle)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-svc.exe</code>: 0% CPU, 17.6 MB — appears idle when it should be active</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Renderer helper (99.9 MB) survived but no longer paints content (brown screen visible)</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">No process death, no resource exhaustion, no orphan. The renderer is alive but in a stuck state after project click. This appears to be a logic-level bug in Cowork's project-load flow, not a system-level issue.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Workaround for now: avoid clicking existing projects, use "New task" only — but that also crashes after a couple of messages.</p></blockquote><!--EndFragment-->
</body>
</html>
Add this to the GitHub thread tonight (or save for tomorrow):

Additional data May 18, 2026 evening:
Post-reboot, with bundle clean and no Claude.exe.old orphan present, project-click crash still reproduces. Task Manager during crash state:

9 Claude processes alive, none in "Not responding"
Total Claude memory: ~414 MB (normal)
CPU: 0.9% main + 0.9% renderer (idle)
cowork-svc.exe: 0% CPU, 17.6 MB — appears idle when it should be active
Renderer helper (99.9 MB) survived but no longer paints content (brown screen visible)

No process death, no resource exhaustion, no orphan. The renderer is alive but in a stuck state after project click. This appears to be a logic-level bug in Cowork's project-load flow, not a system-level issue.
Workaround for now: avoid clicking existing projects, use "New task" only — but that also crashes after a couple of messages.

Update May 19, 2026:
New error mode on first launch this morning: Cowork displayed "Virtualization is not available — Claude's workspace requires Virtual Machine Platform, but the virtualization service isn't responding. Restart your computer to resolve this."
Verified via PowerShell that vmcompute (Running, Automatic) and HvHost (Running, Manual) are both healthy and responsive. The error message and its suggested reboot remediation appear to be incorrect — services are functional, but Cowork cannot establish communication with them.
This is a separate failure mode from the EPERM rename errors documented over the past two days. Cowork's diagnostic messages are pointing users toward unnecessary actions (reboot) when the actual issue is internal to Cowork.

Update May 19, 2026 — partial root cause and persistent failure:
Following process cleanup yesterday that removed an orphan Claude.exe.old and the bundle update completing successfully overnight, Cowork's behavior today shifted but did not stabilize.
Morning launch: New error message — "Virtualization is not available. Claude's workspace requires Virtual Machine Platform, but the virtualization service isn't responding. Restart your computer to resolve this."
Verified via PowerShell that vmcompute (Running, Automatic) and HvHost (Running, Manual) were both healthy and responsive. Cowork's error message and its suggested reboot remediation were incorrect — services were functional. The actual fix was killing the orphaned cowork-svc.exe process in Task Manager, which standard Get-Process | Where-Object { $_.Name -like "claude" } | Stop-Process -Force does not catch.
After cowork-svc.exe end-task:

Cowork relaunched and loaded successfully
Project click took 21 seconds to render (vs. normal <2 seconds) but did not crash
EPERM error flashed for ~2 seconds and self-recovered (improved from yesterday's persistent state)
Cowork proposed three reasonable error-recovery options when it hit the next EPERM
Crashed (brown screen) after a single follow-up prompt

Today's confirmed behavior: Cowork is usable for 1-2 prompts at a time before crashing. Each launch requires:

Kill Claude.exe AND cowork-svc.exe in Task Manager (PowerShell wildcards miss the latter)
Check for Claude.exe.old and end-task if present
Wait, relaunch, hope the EPERM stays transient

Recommendations for engineering documentation:

Update standard kill commands to explicitly include cowork-svc.exe — wildcards don't catch it
The "Virtualization not available" error message points users at the wrong fix (reboot doesn't address the orphan-service issue)
The EPERM bundle rename bug is now the dominant failure mode — please prioritize the swap-and-replace pattern fix

Switching to Claude Code (terminal) for active project work, which has remained 100% stable through every Cowork crash this week.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.