[BUG] Cowork: VM filesystem mounts lost when Claude Desktop is restarted during active session

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?

When Claude Desktop is restarted while a Cowork session is actively running (e.g., to reload updated local MCP server configurations), the VM filesystem mounts break. The Cowork VM continues running and tools remain functional, but all access to the Mac filesystem via the virtiofs/FUSE bridge is severed. Files previously accessible at /sessions/<id>/mnt/ return errors.

Steps to reproduce:

1. Start a Cowork session with mounted folders (Downloads, Documents, CloudStorage, etc.)
2. Verify filesystem access works (e.g., ls /sessions/<id>/mnt/Downloads/)
3. Restart Claude Desktop (Cmd+Q, reopen — required when updating local MCP server.py files)
4. Return to the still-running Cowork session
5. Attempt filesystem access — fails with mount errors

Workaround: Toggling the filesystem connector off then on in the Cowork session re-establishes the mounts immediately. No data loss occurs.

Impact: This is a friction point for anyone who runs local MCP servers (stdio-based, configured in claude_desktop_config.json) and needs to iterate on them during a Cowork session. The restart-to-reload cycle is the only way to pick up server.py changes, and it breaks filesystem access every time.

Environment: macOS (Apple Silicon), Claude Desktop Pro, Cowork mode with multiple mounted directories, local MCP servers via stdio in claude_desktop_config.json.

What Should Happen?

VM filesystem mounts should survive a Claude Desktop restart, or automatically re-establish when the Desktop reconnects to the running VM session. The VM process lifecycle is already independent of the Desktop process (the session persists through restart), so the mount lifecycle should be too.

Alternatively, if mount persistence isn't feasible, an automatic re-mount on Desktop reconnection would eliminate the manual toggle workaround.

Error Messages/Logs

Steps to Reproduce

1. Start a Cowork session and mount folders (Downloads, Documents, CloudStorage, etc.)
2. Verify filesystem access: run ls /sessions/<id>/mnt/Downloads/ — works fine
3. Quit Claude Desktop (Cmd+Q) — e.g., to reload a modified local MCP server.py
4. Reopen Claude Desktop
5. Return to the still-running Cowork session
6. Run ls /sessions/<id>/mnt/Downloads/ — fails, mount is broken
7. Toggle filesystem connector off then on in Cowork — access restored

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop Pro (Cowork mode)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The root cause appears to be that VM filesystem mounts (virtiofs) are tied to the Claude Desktop process lifecycle rather than the Cowork session lifecycle. When Desktop restarts, the VM session persists but the mount points become stale. The workaround (toggling the filesystem connector off/on in Cowork) suggests the re-mount capability exists but isn't triggered automatically on Desktop reconnection.

This is a significant friction point for users who run local MCP servers via stdio (configured in claude_desktop_config.json) — the restart-to-reload cycle is currently the only way to pick up server.py changes, and it breaks all filesystem access in the active Cowork session every time.