Bryce Watson
Back to blog
•
8 min read

Everything Broke at Once: Triaging Claude Desktop After a Week of Outages

After a week of Claude service disruptions, my local Claude Desktop installation had three separate problems, all presenting at the same time: Cowork’s VM service wouldn’t start, the Google Drive connector returned empty results on every query, and claude.ai showed errors on every page load. Each had a different root cause and a different fix. This post walks through all three.

Environment: Windows 11 Pro, Claude Desktop v1.1.7714.0, Claude Max (individual account).

Background: March 2026 saw documented outages on March 10-12, 16-19, and 22. The March 22 incident took down claude.ai authentication entirely. By March 23, the status page was green again, but the local damage was already done.

If you’re only here for the VM service fix, I wrote a standalone diagnostic guide with the complete decision tree and PowerShell commands.

Problem 1: Cowork won’t start

After rebooting and reinstalling Claude Desktop, Cowork showed:

Failed to start Claude's workspace
VM service not running. The service failed to start.

The built-in “Restart” and “Reinstall workspace” options did nothing. Rebooting the machine didn’t help either.

What I tried first (and why it didn’t work)

The standard recovery steps for Cowork are scattered across GitHub issues (#25663 (open but labeled “invalid”), #27801 (macOS, but identical error message), #29941 (Windows 11 Pro, signature verification error)). I ran through all of them:

  1. Reboot. No change.
  2. Reinstall Claude Desktop. No change.
  3. Click “Reinstall workspace” in the error dialog. No change.

Step 3 felt like it should have been definitive. It wasn’t.

The log that explained everything

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 30

Two lines stood out:

[deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)

The “reinstall workspace” button doesn’t actually reinstall the workspace. It deletes ancillary files but preserves sessiondata.img and rootfs.img.zst, the two files most likely to be corrupted. (Note: the log uses legacy .img names, but the actual files on disk are sessiondata.vhdx and rootfs.vhdx.zst — Hyper-V virtual hard disk format. Same files, different names in different log messages.) This is documented in #24070, where a macOS user found the same behavior.

The Event Viewer confirmed the service was crashing silently:

The Claude service terminated unexpectedly. It has done this 2 time(s).

No DCOM permission errors. No driver blocks. Just a clean crash on startup.

The actual fix

Delete the entire vm_bundles directory, not just the files the reinstall button touches:

Get-Process -Name "*claude*" -ErrorAction SilentlyContinue | Stop-Process -Force
Get-Process -Name "*cowork*" -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item -Recurse -Force "$env:APPDATA\Claude\vm_bundles"

Reopen Claude Desktop. Watch it download a fresh bundle:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 15
rootfs.vhdx not found, downloading...
rootfs.vhdx.zst checksum validated
All files ready in C:\Users\Bryce\AppData\Roaming\Claude\vm_bundles\claudevm.bundle

Then manually start the service, because Claude Desktop’s auto-start likely raced ahead of the download:

Start-Service CoworkVMService

If Start-Service fails, the bundle may still be extracting. Wait 30 seconds and retry. Confirm the bundle is ready by checking the log for “All files ready in …” before attempting.

The root cause: a race condition plus dirty shutdown

The underlying bug is a race condition. Claude Desktop tries to start CoworkVMService immediately on launch, before the VM bundle is fully ready. The service crashes, enters a failed state, and won’t auto-retry.

This is made worse by a shutdown timing issue. When you close Claude Desktop, it sends a VM stop command with a 30-second timeout (confirmed from log timestamps: shutdown started at 09:20:59, timeout error at 09:21:29). If the VM doesn’t stop in time:

[VM:shutdown] Failed: Error: Request timed out: stopVM

Hyper-V resources from the previous session are left in a dirty state, and the service crashes on next launch.

The most important thing I learned: don’t kill Claude processes in Task Manager. The service crash was reproducible when processes were force-killed after exiting Claude Desktop. The correct shutdown sequence is File > Exit, then wait for the VM shutdown to complete — this takes up to 30 seconds based on the timeout in the logs. Verify by checking Task Manager: Claude Desktop processes should disappear, but cowork-svc.exe should still be running. cowork-svc.exe is the CoworkVMService Windows service — it’s set to AUTO_START and is supposed to keep running independently of Claude Desktop. This is normal.

The full diagnostic decision tree, covering all six known root causes for this error message, is in the companion post.

Problem 2: Google Drive connector returning empty results

With Cowork running again, the Google Drive connector was broken. It showed as connected in Settings > Connectors with “Drive search” and “Drive fetch” tools listed, but every search query returned empty results. No errors. Just nothing.

Diagnosis

The OAuth token was stale. The March 22 outage took down claude.ai authentication, and the token was likely invalidated during that incident. The connector appeared connected but couldn’t actually authenticate to Google’s API.

This diagnosis is plausible but unverified from logs — the connector doesn’t log OAuth token state. The fix resolves both stale tokens and wrong-account scenarios, so it’s the right first step regardless of root cause.

A bug that blocked the obvious fix

Clicking “Disconnect” in Claude Desktop’s connector settings produced:

Missing permissions: integrations:manage required.
Please check with one of your organization admins if you think this is in error.

This is a bug. The integrations:manage permission is an organization-level admin gate meant for Team/Enterprise plans. It should not apply to individual Max accounts. Individual users should be able to manage their own connectors.

The workaround

Manage connectors through claude.ai instead of Claude Desktop:

  1. Go to claude.ai (web) > Settings > Connectors > Google Drive > Disconnect
    • This showed a “Not found” error toast but did successfully disconnect
  2. Reconnect Google Drive from the web interface with the correct Google account
  3. Test in a new web chat to confirm
  4. Restart Claude Desktop (File > Exit, wait, reopen) to pick up the new state
  5. Start a new Cowork session. Old sessions cache stale connector state.

Google Drive connector only searches Docs and Folders

During testing, I confirmed the Google Drive connector only searches two file types:

  • Google Docs (application/vnd.google-apps.document)
  • Google Folders (application/vnd.google-apps.folder)

PDFs, Sheets, Slides, and uploaded binary files are not searchable through it. This isn’t documented prominently, and it means the connector is significantly less useful than you’d expect if your Drive contains a mix of file types.

Problem 3: claude.ai showing errors on every page load

Every page refresh on claude.ai in the browser showed a red banner: “This isn’t working right now. You can try again later.”

The status page showed no active incidents on March 23, but the March 22 auth outage had only been resolved hours earlier.

Fix

Residual session state from the outage. Standard remediation:

  • Clear claude.ai cookies specifically (not just cache)
  • Test in an incognito window to confirm it’s local state
  • Hard refresh (Ctrl+Shift+R) to bypass cached error pages

If an incognito window works but your normal browser doesn’t, the problem is confirmed as local cookie/session state — clear cookies and you’re done.

This was the simplest of the three problems, but it contributed to the initial confusion. When the web interface is also broken, it’s harder to tell whether a Desktop issue is local or service-side.

What made this hard

None of these three issues were related to each other. The VM service failure was a race condition triggered by a dirty shutdown. The Google Drive issue was a stale OAuth token from the authentication outage. The web error was cached session state. Three different systems, three different root causes, three different fixes.

The common thread was timing. A week of service disruptions left local state corrupted across multiple layers. Each layer required its own diagnostic tools: PowerShell and Event Viewer for the VM service, the web interface for the connector, and browser dev tools for the cached errors.

The experience reinforced something I’ve seen repeatedly with Cowork: the error messages are generic, the recovery steps in the UI don’t always do what they claim, and the real diagnostic information is in log files that the UI never surfaces. The cowork_vm_node.log was the key to everything in Problem 1. Without it, I’d still be clicking “Reinstall workspace” and expecting different results.

I'm an independent engineer (ex-eBay) who designs and builds production AI systems. I work deep in the Claude Code and MCP ecosystem, document what I find, and take on contract work. Currently taking on projects. Get in touch .