[BUG] Cowork HCS 0x800707de duplicate Plan9 shares — recurrence after #31877 "resolution", business impact from scheduled task loss

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?

This bug reproduces the exact signature of #31877 (which was closed as resolved 3 weeks ago and is now locked). Duplicate Plan9 shares in the HCS VM config are causing HcsWaitForOperationResult to fail with hr=0x800707de at Construct. I've now hit this three times in separate months — March, April mid-month, and again today (2026-04-19), weeks after #31877 was marked resolved — so either the fix didn't fully land for my configuration or a regression has reintroduced the bug. The practical business impact extends beyond the underlying defect to the absence of any recovery path for scheduled task configurations.
Environment

Claude Desktop v1.1.6041.0
Windows 11, 13th Gen Intel Core i7-1355U
AzureAD-joined, Intune-managed corporate device
All required Windows features confirmed enabled (Hyper-V, VirtualMachinePlatform, HypervisorPlatform, WSL)

Error signature (from %APPDATA%\Claude\logs\cowork-service.log)
"Plan9":{"Shares":[
{"AccessName":"home","Name":"home","Path":"C:\\Users\\<user>","Port":9999},
{"AccessName":"home","Name":"home","Path":"C:\\Users\\<user>","Port":9999}
]}
...
[HCS] HcsWaitForOperationResult returned: hr=0x800707de
[HCS] Result JSON: {"Error":-2147022882,"ErrorMessage":"","Attribution":[{"OperationFailure":{"Detail":"Construct"}}]}
Identical to the signature documented in #31877.
Current user-facing symptom
"Failed to start Claude's workspace — VM connection timeout after 60 seconds." This differs from #31877's "VM service not running" symptom, but the underlying HCS config logged by cowork-service.log contains the same duplicate share. Notable: the failing log entry in my current state is timestamped 2026-03-11, suggesting the service has been serving a stale failure state continuously, with the "60-second timeout" surfacing as a newer front-end symptom on top of the same root cause.
Recurrence pattern

March 2026: First occurrence. Workaround (delete vm_bundles and claude-code-vm) resolved it but wiped all scheduled tasks.
April 2026 (mid-month): Second occurrence after a reboot. Same workaround, same data loss.
April 19, 2026: Third occurrence — occurring weeks after #31877 was marked resolved and locked. Currently unresolved while attempting to extract scheduled task data from the VM's VHDX files before running the destructive workaround.

Business impact
I rely on Cowork's scheduled tasks for recurring business operations — document processing, quality review agenda generation, reporting workflows, and MCP-based integrations with internal systems. Each recurrence forces a choice between:

(a) Running the cleanup workaround and losing all scheduled task configurations, or
(b) Abandoning Cowork entirely.

There is no in-product export mechanism for scheduled tasks, and the only recovery path (mounting sessiondata.vhdx directly) requires Linux tooling that corporate-managed Windows machines typically don't ship with. Each recurrence costs hours of reconfiguration work.
Requests beyond the underlying fix

Export/import for scheduled tasks — even a simple JSON dump via a CLI command would be sufficient. This is the single highest-impact mitigation.
Separate scheduled task storage from the VM bundle — so cleanup workarounds don't destroy user configuration.
Documented recovery path — sanctioned instructions for extracting scheduled tasks from sessiondata.vhdx when Cowork cannot start.
A more durable fix for the duplicate-share generation bug — whatever was shipped under #31877 is clearly not fully resolving the underlying issue across all configurations.

Related issues
#31877 (duplicate Plan9 shares, same signature — closed/resolved but clearly not fully fixed), #32828 (same duplicate Plan9 shares in v1.1.5749), #33040, #43482, #43290, #43896, #44007 (add_plan9_shares 60-second timeout, matches my current front-end symptom), #44486, #45577, #48001. The breadth of Plan9-family failures on Windows over the past two months suggests the host-to-VM filesystem bridge may need more fundamental attention, not just point fixes.
What I've tried

Restarted Claude Desktop
Restarted computer
Manually started CoworkVMService (per a Reddit suggestion) — temporary improvement, does not persist across restarts
Verified all Windows features are enabled
Updated Claude Desktop (updated yesterday; current error still occurs)
wsl --update (reports already current)
Microsoft Store's WSL update (fails repeatedly, likely unrelated Store issue)

Workaround that works but destroys user data: Stop-Service CoworkVMService, delete vm_bundles and claude-code-vm, Start-Service CoworkVMService.
Thank you.

What Should Happen?

Claude Cowork should open without error

Error Messages/Logs

Steps to Reproduce

Addressed in main comment

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.17 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_