[FEATURE] Cowork: deterministic VM filesystem mounts that survive Claude Desktop restart

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Cowork's VM filesystem mount feature breaks two deterministic-automation use cases:

1. Mounts are severed when Claude Desktop restarts mid-session, requiring manual connector toggle each time.
2. Mount points are non-deterministic across sessions, blocking reproducible script paths and scheduled-task workflows.

Proposed Solution

Native VM filesystem mount support with three properties:

1. Deterministic mount points — same path across sessions and restarts.
2. No per-session OAuth flow — once granted, mount persists.
3. Broader file scope — beyond the Google Drive folder pattern (e.g., local directories the user grants once).

Alternative Solutions

For day-to-day file work, FUSE-mounting Google Drive at a stable user-side path (e.g., ~/My Drive (account@gmail.com)/) provides a persistent, deterministic mount that survives Desktop restarts. This unblocks daily file work but doesn't replace native VM mounts for broader file scope (non-Drive directories) or scheduled-task workflows that need predictable mount points without per-session OAuth.

Priority

Medium - Would be very helpful

Feature Category

File operations

Use Case Example

Scheduled task in Cowork mode reads/writes to a deterministic mount point (e.g., /cowork/projects/foo/) every morning to refresh a project-status report. Today this requires either:

• Manual connector reconnect each time Desktop restarts, OR
• FUSE mount at a user-side path (current workaround)

With native VM mounts surviving Desktop restart, the scheduled task could write to the same path day after day without intervention.

Additional Context

Refile of #39669, which the bug template auto-closed as 'not planned' on 2026-04-26 with the invitation to file a new issue if still relevant. Reframing as a feature request rather than a bug since the underlying behavior may be intentional.