[BUG] Cowork: VM runtime download leaves .partial and never completes — 'SDK version not verified', survives clean reinstall (Windows, MSIX)

Additional data point that narrows this down:

On the affected machine, Claude Code (CLI / VS Code extension) works fine.

Both products share the same VM stack and the same runtime directory (claude-code-vm), and Claude Code successfully starts its VM and mounts host folders on that machine. Only Claude Desktop fails.

That rules out the whole local virtualization layer as the cause:

• Firmware/BIOS virtualization is enabled (otherwise Claude Code could not run a VM either)
• VirtualMachinePlatform / HypervisorPlatform are effective, not just flagged as enabled
• Endpoint security is not blocking Hyper-V or the Plan9/virtiofs share
• The network path can complete a runtime download — Claude Code has a fully downloaded, verified runtime in the same folder

So the failure appears specific to how Claude Desktop fetches and validates its runtime version, not to the machine's ability to run the VM. On this machine Desktop needs 2.1.260 and cannot complete that download, while an older verified runtime for Claude Code sits in the same directory and works.

Update: the .partial theory in my original report is not the whole story

Same enterprise environment, two more affected machines today (2026-09-10). One of them I debugged for several hours over a remote session. What I found contradicts the original title, so I want to correct the record.

The runtime file is present, complete, and hash-verified — the guest still rejects it

%LOCALAPPDATA%\Claude-3p\claude-code-vm\2.1.260\
  .payload      103 bytes   {"sha256":"7a2f…","size":214687216}
  .verified      64 bytes   (created by the app itself, not by me)
  claude    214,687,216 bytes   sha256 matches .payload exactly

Yet every start fails within 1–2 seconds:

[VM:steps] sdk_install started
[postConnect] Installing SDK: subpath=c/Users/<user>/AppData/Local/Claude-3p/claude-code-vm, version=2.1.260
[error] [VM:start] Startup failed: RPC error -1: SDK version 2.1.260 not verified at
  /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Claude-3p/claude-code-vm/2.1.260/.verified

There is no download attempt in the log at all. No .partial, no network error. The host has the file; the guest says it is not verified.

Everything before sdk_install succeeds

[VM:steps] vm_boot completed (218ms)
[VM:steps] add_plan9_shares completed (11ms)
[VM] Network status: CONNECTED
[VM:steps] sdk_install started        <- fails here, always

add_plan9_shares reports success on the host side, but that only means the share was registered — it does not prove the guest mounted it.

A second machine shows what looks like the same root cause from the other side

Different user, same environment, never touched by any of my scripts:

resume: RPC error -1: failed to mount
  /mnt/.virtiofs-root/shared/c/Users/…/uploads as uploads:
  source path … is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: <name> already exists unexpectedly: uid=1010 gid=1010

A third machine reported uid=1005. So on some machines the guest cannot mount the host c share at all, and on others it mounts but cannot read a specific file under it. My working assumption is now that both symptoms are the guest failing to access the host share, not a download problem.

What did not fix it

• Restart app, restart PC (multiple times)
• "Reinstall workspace" from the error dialog
• Deleting local-agent-mode-sessions / claude-code-sessions
• Wiping vm_bundles\claudevm.bundle down to only the .zst caches and their .origin markers
• Deleting claude-code-vm entirely and letting the app re-fetch (it did, correctly — same failure)
• Full clean reinstall: Remove-AppxPackage, delete the whole Claude-3p user folder (~9 GB), reinstall, sign in fresh. The app downloaded the runtime itself and wrote its own .verified. Still fails identically.
• Disabling real-time antivirus

The clean reinstall is the important one: at that point nothing on the machine came from me, the app produced every file itself, and it still could not read its own output from inside the VM.

Three secondary findings that may be worth fixing regardless

1. Auto-reinstall only ever runs once, permanently

[VM:start] Skipping auto-reinstall (already attempted once)

A zero-byte .auto_reinstall_attempted marker in vm_bundles\claudevm.bundle makes the app give up self-healing forever. Deleting it makes the app retry properly. As shipped, a user who hits one transient failure loses automatic recovery for good.

2. That one auto-reinstall attempt is incomplete because of a file lock

[deleteVMBundle] rootfs.vhdx locked by running VM (EBUSY), skipping
[deleteVMBundle] Keeping .rootfs.vhdx.origin — rootfs.vhdx is locked
[deleteVMBundle] Deleted vmlinuz
[deleteVMBundle] Deleted initrd
[deleteVMBundle] Reinstall files deleted (sessiondata.img and compressed cache preserved)

The kernel and initrd are removed while the 8 GB rootfs.vhdx survives, leaving a mismatched set. The marker from finding 1 is written anyway, so this half-cleaned state becomes permanent. Suggestion: stop the VM before deleting, and do not write the marker when the cleanup was partial.

3. Installing SDK gives no diagnostic on failure

The message is identical whether the file is missing, unreadable, or fails a checksum. On a machine where the file demonstrably exists with the right hash, there is no way to tell which of those happened. Logging the guest-side stat/read result would have saved most of a day here.

Environment

• Claude Desktop 1.49585.0.0, MSIX, enterprise deployment (registry bootstrap, self-hosted gateway, Amazon Bedrock backend)
• Windows 11 Pro, managed corporate image
• VM runtime 2.1.260
• VirtualMachinePlatform and HypervisorPlatform enabled; CoworkVMService, vmcompute, HvHost all running
• Onset: after a scheduled OS security update and company-wide reboot, several machines began re-provisioning the workspace at the same time and failed together

Machines in the same environment that had already fetched the runtime before that reboot are unaffected. Claude Code on the very same machine works normally, which rules out virtualization, antivirus and network as general causes — those would break Code too. The failure is specific to the Cowork workspace path.

Happy to collect any additional guest-side logs if you can tell me where they land.

Root cause located: the guest rejects the Plan9 mount with EINVAL

Following up on my earlier comment. I found the guest-side log and it pins the failure to a single call. Every symptom in this thread — SDK version not verified, Plan9 share "c" which is not mounted, ensure user: already exists unexpectedly — is downstream of this one line.

Guest log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log):

[coworkd] detected Hyper-V host, loading vsock/9p modules
[coworkd] resolved host share base: /mnt/.virtiofs-root/shared
[coworkd] mounting session disk /dev/sdc at /sessions
[coworkd] session disk mounted successfully at /sessions
[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
[hyperv] mounted 0/1 Plan9 shares

mounted 0/1. The session disk (/dev/sdc) mounts fine — only the 9p share fails, and it fails with EINVAL rather than a connection error.

The host side is fully healthy

Service log (C:\ProgramData\Claude\Logs\cowork-service.log), same session:

[HCS] HcsStartComputeSystem returned: hr=0x0
[VM] User token set for Plan9 identity
[VM] Plan9 share added: c -> C:\ (port=9902, readOnly=false)
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] HcsModifyComputeSystem returned: hr=0x0
[VM] Sent plan9Shares notification (1 shares)
[VM] Installed 46 CA certificates in guest
[coworkd] reachability check passed (status=200)

So: the share is registered successfully, host↔guest RPC works, the host writes 46 CA certs into the guest, and the guest reaches our gateway over HTTPS. Only mount fails.

This distinguishes it from #72685 and friends, where HcsModifyComputeSystem itself failed with HRESULT 0x8007273f. Here the host call succeeds and the guest kernel refuses the mount.

Why not verified is a red herring

.verified lives on the host under claude-code-vm/<version>/. The guest reads it through /mnt/.virtiofs-root/shared/c/..., which never gets mounted — so the check fails for a file that is present and correct.

I verified the file is not the problem:

.payload   {"sha256":"7a2f…","size":214687216}
claude     214,687,216 bytes, sha256 matches .payload exactly
.verified  ad1c0b3f…  ==  the linux-x64 checksum in the app's own bundled SDK manifest

The value matches what the app itself ships. Editing .verified (I tried the payload hash) only makes it worse.

What we ruled out — ~7 hours, one machine, full remote session

Host-side, all ineffective:

• Delete local-agent-mode-sessions / claude-code-sessions
• Wipe vm_bundles\claudevm.bundle to only the .zst caches; delete claude-code-vm entirely and let the app re-fetch
• Delete .auto_reinstall_attempted to restore self-healing (repeatedly — it comes back)
• Full clean reinstall: Remove-AppxPackage, delete the entire 11 GB user data folder, reinstall, sign in fresh, let the app download everything itself. Same failure.
• 4 reboots
• Disable antivirus real-time protection
• Remove every managed setting our enterprise bootstrap sends (13 keys, including the gateway connection itself) — no change
• CLAUDE_CODE_LOCAL_BINARY to force getRequiredVersion() to "local" — MSIX isolation drops the variable; [CCD] LOCAL OVERRIDE never logs
• Enable WSL + netsh winsock reset + wsl --update + reboot (the workaround from #72685)
• Disable Memory Integrity / HVCI (SecurityServicesRunning {2} → {0}) + reboot

Environment is otherwise clean:

VirtualMachinePlatform=Enabled   HypervisorPlatform=Enabled
Microsoft-Hyper-V-All=Enabled    HypervisorPresent=True
hypervisorlaunchtype=Auto        OSBuild=26200
vmcompute.dll / computecore.dll / computenetwork.dll all present
CoworkVMService / vmcompute / p9rdr / hns all Running
No network drives mapped

Also worth noting: Claude Code on the same machine works normally. Same VM stack, same box. That rules out virtualization, AV and network as general causes.

Requests

1. Log the actual mount arguments and errno when the 9p mount fails. invalid argument with no detail is what made this take a full day. The msize / version / trans / aname values would likely identify it immediately.
2. Treat mounted 0/1 Plan9 shares as a fatal, surfaced error. Right now the guest continues, and the user sees a misleading SDK version not verified several steps later pointing at a file that is perfectly fine.
3. If the mount options depend on host build or guest kernel version, that pairing looks like the thing to check — guest bundle 2a762adf here, which is the same bundle fingered in #87601.

Happy to pull any further guest-side logs, or run a build with verbose mount logging.

Environment: Claude Desktop 1.49585.0.0 (MSIX, enterprise deployment with registry bootstrap, self-hosted gateway, Amazon Bedrock backend) · Windows 11 Pro build 26200 · VM runtime 2.1.260 · guest bundle 2a762adf.

We have the same issue - just found it with this error 'SDK version not verified'
We have around 1200 clients but only 1 client has the issue.
Tried the same

Maybe Windows Update related
https://github.com/anthropics/claude-code/issues/92984

I'm also affected. I couldn't find any issue related to this SDK issue before, but now it looks like it's not just me affected :)
Here's my log https://gist.github.com/pkozuchowski/30d53b24603e65ecc42b69c93b0d56af

Resolved on our side — root cause is KB5124008, and it matches #92984 exactly

Closing the loop on my two earlier comments. My .partial theory and my guest-mount findings were both symptoms of the same thing, and @StephanGa's pointer to #92984 was correct.

Removing KB5124008 and rebooting restored Cowork immediately. App version held constant at 1.49585.0.0 throughout.

Before : OS 26200.9445 (KB5124008)  ->  [hyperv] mounted 0/1 Plan9 shares
After  : OS 26200.9278              ->  [VM:start] Startup complete, total time: 24030ms
                                        [vmOneShot] Running: soffice ...   (xlsx work succeeds)

One note for anyone following: wusa /uninstall /kb:5124008 returns ExitCode 87 on current Windows — cumulative updates can't be removed that way. This worked:

dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 /norestart

Then reboot. Takes 3–10 minutes plus a longer-than-usual boot.

The concrete defect, for whoever escalates this

The update ships a mismatched pair of Plan9 components:

p9rdr.sys   10.0.26100.9444   <- replaced by KB5124008
p9np.dll    10.0.26100.9278   <- left at the old version

Every report in #92984 that lists file versions shows this same split. That is almost certainly why the guest's 9p mount is rejected with EINVAL while the host-side HcsModifyComputeSystem still returns hr=0x0 — the host thinks it succeeded, the transport behaves differently than the guest expects.

Request: please escalate to Microsoft

The evidence is already at the level Microsoft would ask for:

• Deterministic: present on every machine with KB5124008, absent after removal
• Isolated: multiple reporters held the app version fixed and toggled only the KB
• Broad: 24H2 and 25H2, x64 and ARM64, multiple vendors, single-share and multi-share setups
• Specific: a named binary pair with a version mismatch, and an exact failing syscall

A vendor-side report from Anthropic carries weight that individual enterprise tickets do not, and you can quantify the affected install base. From our side this currently has no durable fix — the update is delivered by Windows Update, so any machine we repair gets it back on the next cycle.

If it helps, I'm happy to supply the host service log and guest coworkd log from a failing boot and a working boot on the same machine.

Two things that would reduce the damage regardless of Microsoft's timeline:

1. Surface mounted 0/N Plan9 shares as a fatal error. Today the guest continues and the user eventually sees SDK version not verified, which points at a file that is present and hash-correct. That misdirection cost us most of a day before we found the guest log.
2. Log the mount arguments and errno. invalid argument with no detail gives nothing to work with; the msize/version/trans/aname values would likely have identified the mismatch immediately.

Thanks to everyone in #92984 — that thread is what closed this out.