Cowork (Windows desktop): CoworkVMService never restarts and Plan9 drive shares fail to attach, surfaced as "You've been signed out"

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?

Product: Claude Desktop app (Cowork), Windows 11, MSIX package Claude_pzs8sxrjxfjjc, app version 1.49585.0, Electron 44.2.0. Not the CLI.

Related existing issues: #31877, #36590, #59794, #64592. Filing separately because the combination below, and in particular the data loss risk in the circulating workaround, is not covered by any of them.

After an unclean shutdown overnight, Cowork became unusable and stayed unusable through a full day of remediation. Three faults were involved, two of which produced misleading errors that sent a non technical user down entirely the wrong path.

1. Opening error implies data loss. On launch the app failed with:

RPC error -1: failed to mount
...\local-agent-mode-sessions\<account>\<org>\spaces\<space>\memory as .auto-memory:
source path ... is under Plan9 share "c" which is not mounted

The user read this as his conversation history being corrupted, renamed local-agent-mode-sessions to .old and created an empty replacement to get the app running. That made a 14,100 message conversation built up since April appear to be gone.

2. CoworkVMService stops and never restarts. The service had stopped itself and is set to start manually, so every reboot brought it back stopped. The app's banner says "Claude's workspace service isn't running. Restart your computer to restore it." That advice is wrong. The user restarted several times for nothing. Start-Service CoworkVMService fixed it in one second.

3. Plan9 drive shares do not attach. With the service running the VM boots and then fails at:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Same underlying fault as the launch error. Still unresolved.

4. Sandbox failure is surfaced as an auth failure. With no workspace, the conversation shows "You've been signed out. Sign in again to continue." The banner blocks the composer so the conversation cannot be used, and signing in loops because the workspace it needs never starts. Nothing is wrong with the account.

Ruled out: hypervisor running and logging normally; CoworkVMService Running and Automatic; vm_bundles present; no Android emulator processes running (MuMu and LDPlayer installed but closed); all 16 session folders intact and readable.

Impact: a full working day lost for a small business that uses Cowork daily to draft customer email. Worse, the workaround circulating for #31877 tells users to delete local-agent-mode-sessions, which would have permanently destroyed three months of history. That folder held the only copy.

What Should Happen?

1. The app should start CoworkVMService itself when it finds it stopped, and the service should be installed with a failure/restart action so Windows brings it back automatically. It should not tell the user to restart the computer when the actual fix is one service start.

1. A sandbox failure should not be surfaced as "You've been signed out". That sends users to account recovery for an infrastructure problem, and the banner blocks the composer so the conversation cannot be used at all.

1. The mount error should say what it means. "The sandbox could not access your drive" instead of a Plan9 share message that reads like data corruption.

1. Reset guidance, anywhere it appears, should name vm_bundles and claude-code-vm only, and state explicitly that local-agent-mode-sessions must never be deleted because it is the only copy of the user's conversation history.

1. Ideally a repair action in Settings that resets VM state without touching user data.

Error Messages/Logs

On app launch:

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/<account>/<org>/spaces/<space>/memory as .auto-memory: source path ... is under Plan9 share "c" which is not mounted

In-app banner:

Claude's workspace service isn't running. Restart your computer to restore it. Reinstalling won't help. The workspace files are fine; the background service just needs to restart.

With CoworkVMService running, the VM boots and then fails at:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

In the conversation view:

You've been signed out. Sign in again to continue. You can restart the conversation from an earlier message.

Note: the app's own logs (logs\main.log and logs\cowork_vm_node.log) were last written three weeks before the incident, so they contain nothing about it.

Steps to Reproduce

Observed on Windows 11 with the MSIX Claude Desktop build. The trigger was an unclean shutdown (machine crashed overnight) while Cowork had been in use.

1. Use Cowork normally on Windows with at least one connected folder.
2. Let the machine shut down uncleanly (power loss or crash) while the sandbox VM has been running.
3. Start Claude Desktop and open an existing Cowork conversation.
4. Observe the RPC mount error naming a Plan9 share "c" that is not mounted.
5. Restart the computer. Observe that the workspace still does not start, because CoworkVMService is set to Manual start and comes back stopped. The banner still advises restarting the computer.
6. Run Start-Service CoworkVMService in an elevated PowerShell. The service starts immediately and the VM now boots.
7. Observe that the VM still fails with "no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared", so Cowork remains unusable.
8. Open a Cowork conversation and observe "You've been signed out". Clicking Sign in again loops back to the same banner, because the workspace it needs never starts.

Diagnostic state at step 7: hypervisor running and logging normally, CoworkVMService Running and StartType Automatic, vm_bundles present, no Android emulator processes running, all session data intact on disk.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Same build, 1.49585.0. Worked until 8 September 2026. Not a version regression, the trigger was an unclean shutdown.

Claude Code Version

Claude Desktop 1.49585.0 (not the CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This is the Claude Desktop app on Windows, not the Claude Code CLI, so several fields in this template do not map cleanly. There is no terminal involved and no claude --version; the version given is the desktop app build.

Environment: Windows 11, Claude Desktop 1.49585.0, MSIX package Claude_pzs8sxrjxfjjc, Electron 44.2.0, Node 24.20.0.

Context on the impact, since it is the part I would most want a maintainer to read. This is a small lawn care business that uses a Cowork conversation daily to draft replies to customer email. That conversation holds 14,100 messages built up since April. When the first error named the sessions folder and said a share was not mounted, the natural reading was that the history was corrupt. The workaround circulating for #31877 says to delete vm_bundles, claude-code-vm and local-agent-mode-sessions. Following that advice would have destroyed three months of work permanently, because that folder is the only copy and nothing warns you of that.

The history was eventually recovered intact by reading the session files directly, so no data was actually lost here. But it was close, and the only reason it was close is that the error messages point at the wrong thing.