[BUG] Cowork — vmcompute (Hyper-V Host Compute Service) terminates with "General access denied error" (0x80070005); workspace never starts despite readiness check PASS/SUPPORTED

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/67878
2. https://github.com/anthropics/claude-code/issues/38188
3. https://github.com/anthropics/claude-code/issues/61559

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

👎 Not a duplicate. Please keep this open — my configuration and failure stage differ from all three:

• #67878 is Windows 11 Pro with Credential Guard as the cause. I'm on Windows 11 Home (Core), where Credential Guard is not active. Different root cause.
• #38188 is Win11 Pro 25H2 (build 26200) and the SYSTEM-ACL grant on vm_bundles resolves it there. On my machine that same SYSTEM-ACL grant only transiently advances the error and does NOT survive a reboot (MSIX appears to reset the ACLs) — the workspace still never starts.
• #61559 is build 26200 where vmcompute runs and fails later at VHDX attach. On my machine vmcompute is terminated at service start with "General access denied" (0x80070005) — one stage earlier; the service never stays up.

Additional distinguishing facts:

• OS: Windows 11 Home, build 22631 (Core) — none of the three cover this edition/build.
• Antivirus ruled out: the same Kaspersky Premium runs Cowork fine on a second PC.
• Cowork readiness check returns SUPPORTED, yet vmcompute is denied at service start. The check also reports [WARN] VM service logon right — could not query LSA deny: {Access Denied} even when elevated, which may indicate a local LSA/security-policy issue specific to this machine.
• Stage oscillation (new symptom): depending on when the SYSTEM ACL is reapplied, the error cycles between "VM service not running. The service failed to start.", "Request timed out: configure", "Request timed out: startVM", and "RPC pipe closed".

secedit confirms SeServiceLogonRight contains *S-1-5-83-0 and there is no SeDenyServiceLogonRight entry, so logon rights are correct. Happy to provide cowork-service.log and full Event Viewer entries.

I have the same issue.
Here is the output for my claude readiness check.

Cowork readiness check — Windows (windows/amd64)

[PASS]  Windows version             10.0 build 26200
[PASS]  Architecture                x64
[PASS]  Hardware virtualization     hypervisor running (Microsoft Hv, root partition)
[PASS]  Virtual Machine Platform    services present: vmcompute, HNS, vfpext
[WARN]  VM service logon right      could not query LSA deny: {Access Denied}
A process has requested access to an object, but has not been granted those access rights.
                                    -> Run 'secedit /export /cfg out.inf /areas USER_RIGHTS' and check SeServiceLogonRight / SeDenyServiceLogonRight for SID S-1-5-83-0.
[PASS]  Windows edition             Core
[PASS]  Application control policy  none detected
[PASS]  Disk space                  60.2 GB free
[PASS]  Memory                      15.7 GB total
[PASS]  Page file                   27.9 GB available commit

Result: SUPPORTED

secedit confirms SeServiceLogonRight contains *S-1-5-83-0 and there is no SeDenyServiceLogonRight entry, so logon rights are correct.

Bug report — Cowork VM: vmcompute terminates with 0x80070005 (Access denied); every documented cause excluded

Prepared 2026-07-29. Intended for https://github.com/anthropics/claude-code/issues/69102 (open, identical symptom) or support.claude.com.

---

Summary

The Cowork workspace never starts. The Hyper-V Host Compute Service (vmcompute) fails to start with Event ID 7023, „Allgemeiner Zugriff verweigert"-Fehler (0x80070005). This is not a configuration problem: over four sessions every documented cause from related issues was checked and excluded by direct measurement, including the ACL fix that resolved #38188.

Environment

• Windows 11 (German locale), hypervisorlaunchtype = Auto
• Claude Desktop MSIX / Microsoft Store install, package Claude_pzs8sxrjxfjjc, app version 1.24012.9.0
• VM bundle path (real, de-virtualised): C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles
• Services: CoworkVMService Running (Automatic), HvHost Running (Manual), vmcompute Stopped (Manual)
• Free disk: 897 GB

Windows optional features

| Feature | State |
|---|---|
| VirtualMachinePlatform | Enabled |
| HypervisorPlatform | Disabled |
| Microsoft-Hyper-V-All (and all sub-features) | Disabled |
| Containers / Containers-HNS / Containers-SDN | Disabled (were Enabled; disabling changed nothing) |

Virtualisation-based security

VirtualizationBasedSecurityStatus: 2, SecurityServicesRunning: {2} — HVCI / Memory Integrity active. Was switched off once during troubleshooting and re-activated itself by the next check.

Symptom chain

1. Claude Desktop retries every ~5 minutes: [ScheduledTasks] VM not ready (tick N), requesting startVM
2. Startup proceeds normally through download_and_sdk_prepare, load_swift_api, smol-bin copy, Windows VM service configured, create_network
3. [VM:steps] create_vm_config started — and the log ends there. No further line, no error from HCS.
4. After 60 s: [VM:start] Startup failed: Error: Request timed out: configure (also seen as Request timed out: startVM, getNetworkDrives)
5. Later builds surface it directly as VM service not running. The service failed to start.
6. Windows System log, concurrently and on every retry:

Der Dienst "Hyper-V-Hostserverdienst" wurde mit folgendem Fehler beendet: Allgemeiner "Zugriff verweigert"-Fehler (Event ID 7023)

Start-Service vmcompute from an elevated prompt fails identically; the service never reaches Running.

Note: the timeout is a symptom, not the fault. create_vm_config calls into a service that is not running, so nothing ever answers.

Causes checked and EXCLUDED

| # | Hypothesis | Method | Result |
|---|---|---|---|
| 1 | Missing SYSTEM ACL on vm_bundles (the fix in #38188) | icacls on the real MSIX path | Already present: NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F). Not the cause here. |
| 2 | Corrupt / incomplete VM image | Directory listing with sizes | Intact: rootfs.vhdx 7 688 MB decompressed, vmlinuz 14 MB, initrd 72 MB, all current |
| 3 | Disk space | Get-PSDrive | 897 GB free |
| 4 | Containers feature enabled (the cause in #37068) | Disable-WindowsOptionalFeature for Containers, -HNS, -SDN + reboot | Disabled; error unchanged, identical Event 7023 |
| 5 | Service account / logon rights | sc qc vmcompute | LocalSystem, DEMAND_START — standard |
| 6 | Service security descriptor | sc sdshow vmcompute | D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLORC;;;AU) — standard, SY has SERVICE_START |
| 7 | ACL on vmcompute.exe | icacls | Standard: TrustedInstaller (F), Administrators/SYSTEM/Users (RX) |
| 8 | Registry ACL on the service key | Get-Acl | Standard: SYSTEM and Administrators FullControl |
| 9 | Missing dependencies | Get-Service rpcss,wcifs,hvsocketcontrol,condrv | All four Running |
| 10 | Corrupt component store | DISM /RestoreHealth + sfc /scannow, then VirtualMachinePlatform disable → reboot → re-enable → reboot | Error unchanged |
| 11 | Third-party security software (Comodo Firewall 12.2.2.8012, incl. its cmdGuard "Internet Security Sandbox Driver") | fltmc unload → 0x801f0010 (refused); sc config start= disabled → silently ineffective; finally uninstalled entirely + reboot | cmdGuard gone, no Comodo services remain — error unchanged. Excluded. |
| 12 | Any other third-party file-system filter | fltmc filters, then Get-AuthenticodeSignature on the only unfamiliar one (bfs) | Every loaded minifilter is Microsoft-signed. bfs = "Brokerdateisystem", CN=Microsoft Windows. No third-party filters present. |
| 13 | HVCI / Memory Integrity | Disabled via Windows Security → Core Isolation, rebooted, verified SecurityServicesRunning: {0} | HVCI confirmed off; vmcompute still fails identically. Excluded. |
| 14 | Policy / MDM enforcement of security settings | Win32_DeviceGuard, reg query HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard /s, CI\Policy | SecurityServicesConfigured: {0}, no Group Policy entries, VerifiedAndReputablePolicyState = 0 (Smart App Control off). Nothing is being enforced externally. |

Nothing remains untested

Every hypothesis available from the related issues and from standard Windows service-failure diagnostics has been checked and excluded by measurement. Final state at the last attempt:

• VirtualizationBasedSecurityStatus: 2, SecurityServicesRunning: {0}, SecurityServicesConfigured: {0}
• No third-party kernel filter drivers loaded at all
• All four vmcompute dependencies Running
• Correct ACLs on binary, service key, service SDDL and the MSIX bundle directory
• Component store repaired, VM image intact, 897 GB free
• vmcompute still terminates with 0x80070005 on every start attempt

Why this looks like a product bug

After #11 and #12 the machine has no third-party kernel filter drivers at all, correct ACLs at every level, all dependencies running, a repaired component store and a verified-intact VM image — and vmcompute still cannot start. Every published workaround has been applied and measured.

Requests

1. Under what conditions does the MSIX-packaged CoworkVMService cause vmcompute to terminate with E_ACCESSDENIED at service start (not at HCS call time)? Event 7023 points at service initialisation, not file access.
2. Is the MSIX VFS path virtualisation described in #38188 (AppData\Roaming\Claude\... vs ...\LocalCache\Roaming\Claude\...) passed correctly to HCS? The cowork_vm_node.log still prints the virtualised path (C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle) rather than the real one.
3. Is HVCI a known-incompatible configuration? If so it should be surfaced in the readiness check, which currently reports the system as supported.
4. Please add a preflight check and an actionable error message. The current failure presents as a generic timeout and gives no path to diagnosis.

Related issues

• #69102 — identical symptom, still open (there with Kaspersky; whitelisting did not help, matching the Comodo result above)
• #38188 — same HRESULT, resolved by a SYSTEM ACL that is already correct on this machine
• #37068 — same failure class caused by the Containers feature; disabling it changed nothing here
• #32574 — tracking issue for Windows Cowork failures

Wrote by Claude but I have read it all and I was the one performing the actions.

Reproduced this exact issue on a Windows 11 (25H2) machine — same symptom, same event log signature:

Event Viewer > System, Source: Service Control Manager, Event ID 7023:
"The Hyper-V Host Compute Service service terminated with the following error:
General access denied error"

Event Viewer > Applications and Services Logs > Microsoft > Windows > Hyper-V-Compute-Admin, Event ID 10000:
"The Host Compute Service failed to start:  Access is denied.  (0x80070005)"

Start-Service vmcompute fails immediately with the same generic StartServiceFailed PowerShell error, no matter the account used to invoke it.

What I ruled out (all confirmed via direct testing)

• Memory Integrity / HVCI — toggled off (VirtualizationBasedSecurityStatus confirmed 2→still 2 with SecurityServicesRunning: {0}), rebooted, vmcompute still fails identically.
• SeServiceLogonRight / deny rights — confirmed via secedit /export that S-1-5-80-0 and S-1-5-83-0 both hold the right, no SeDenyServiceLogonRight entries.
• File/registry ACLs — captured a full Process Monitor trace of vmcompute.exe on launch. It performs entirely normal startup registry reads (all SUCCESS/benign NAME NOT FOUND), then exits cleanly with Exit Status 0 in ~17ms, before ever touching a device driver or VM-related resource. There is not a single ACCESS DENIED entry in the trace. This means the denial is not a file/registry permission problem — it's happening somewhere Procmon's file/registry filter can't see (most likely the SCM-to-service handshake, or deeper in the virtualization stack).
• A full Hyper-V role being present — this machine had accidentally had the full Microsoft-Hyper-V-All role force-enabled (via a bad troubleshooting suggestion from an unrelated tool (docker desktop installation program), Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V,Containers -All) months prior, layered on top of the lightweight VirtualMachinePlatform/HypervisorPlatform WSL2 stack. Cleanly disabled the full role (Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All), rebooted, confirmed VirtualMachinePlatform/HypervisorPlatform/WSL still Enabled — vmcompute still failed identically. So a conflicting Hyper-V role is not required to hit this bug (though it's still worth not doing).
• System file corruption — sfc /scannow did find and repair a corrupt file, but it was an unrelated Bluetooth driver (bthmodem.sys). No change to vmcompute.
• Profile-specific corruption — created a brand-new local admin account from scratch, tested Start-Service vmcompute there. Identical failure. Confirmed machine-wide, not user-profile-specific.

What actually fixed it

The machine was significantly behind on Windows Update — still on 22H2. Worth noting why: it was stuck there because "Security Device Support" (the BIOS/UEFI toggle for exposing the TPM to the OS) was disabled in firmware, which blocked Windows Update from offering the 23H2/24H2/25H2 feature updates at all (TPM 2.0 is a hard requirement for those). Enabling that BIOS setting was the prerequisite step that let Windows Update actually proceed past 22H2. After fully updating to the latest 25H2 cumulative update and rebooting, vmcompute started immediately and has been stable since — WSL2, a fresh Ubuntu install, and Docker Desktop all worked on the first try afterward. Also worth noting: DISM /Online /Cleanup-Image /CheckHealth reported "No component store corruption detected" the whole time, yet CBS.log repeatedly logged "The store corruption status report is incomplete. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]" — consistent with the servicing store being stale/incomplete due to missing updates, in a way the quick health check didn't flag as an error.

If anyone hitting this bug is also stuck on an old Windows 11 version (or can't seem to get feature updates to install at all), check whether your BIOS/UEFI has TPM ("Security Device Support," "PTT," "fTPM," or similar depending on vendor) disabled — that's worth checking before anything else here.

Suggested addition to the readiness check / troubleshooting docs: have it explicitly check Windows Update status (Get-WindowsUpdateLog or a pending-updates count) rather than just checking that the relevant optional features are Enabled — feature state can look completely healthy while the underlying servicing/virtualization stack is stale enough to break vmcompute at runtime.

The raw Procmon trace and CBS.log are still sitting on the machine locally — can paste specific excerpts here if a maintainer wants to see something in particular.