[BUG] vfpext missing (Solved)

[Houseton]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

I'm writing this because I had the vfpext issue but have solved it though Windows 11 Pro reported the vfpext was installed CoWork would not start:

Cowork Feedback Report — "Missing HCS services: vfpext" despite healthy virtualization stack

Summary

Claude Desktop's Cowork feature reports Missing HCS services: vfpext (unsupportedCode: hcs_not_available) and remains disabled, even though every underlying Windows virtualization component is present, enabled, and running. This looks like a detection/reporting bug in Cowork's feature-check logic rather than an actual missing service.

System

• OS: Windows (please fill in exact edition/build from winver if attaching this)
• Claude Desktop: latest version

Affected features (from supported-features-info.json)

• yukonSilver, yukonSilverGems, yukonSilverGemsCache
• coworkKappa, coworkArtifacts, coworkAutoModeAlwaysAllowOverride

All report:

"status":"unsupported","reason":"Missing HCS services: vfpext","unsupportedCode":"hcs_not_available"

Diagnostic steps taken and results

1. Confirm/re-enable Virtual Machine Platform

PS> Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
Path          :
Online        : True
RestartNeeded : False

2. Confirm vfpext.sys driver file exists on disk

PS> Test-Path C:\Windows\System32\drivers\vfpext.sys
True

3. Query vfpext service state

PS> sc.exe query vfpext
SERVICE_NAME: vfpext
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 1077  (0x435)
        SERVICE_EXIT_CODE  : 0  (0x0)

Note: exit code 1077 (ERROR_SERVICE_NEVER_STARTED) is expected/normal for this driver type — it starts on demand when a virtual switch binds to it, not at boot.

4. Enable full Hyper-V feature (not just VMP)

PS> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Path          :
Online        : True
RestartNeeded : False

5. Confirm vmcompute service

PS> sc.exe query vmcompute
SERVICE_NAME: vmcompute
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING

6. Confirm hns service

PS> sc.exe query hns
SERVICE_NAME: hns
        TYPE               : 30  WIN32
        STATE              : 4  RUNNING

7. Confirm a virtual switch exists

PS> Get-VMSwitch
Name           SwitchType NetAdapterInterfaceDescription
----           ---------- ------------------------------
Default Switch Internal

8. Manually restart vmcompute and re-check switch

PS> Start-Service vmcompute
PS> Get-VMSwitch
Name           SwitchType NetAdapterInterfaceDescription
----           ---------- ------------------------------
Default Switch Internal

(No change — switch was already present and healthy.)

9. Confirm Hyper-V Management PowerShell module

PS> Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell
FeatureName      : Microsoft-Hyper-V-Management-PowerShell
DisplayName      : Hyper-V Module for Windows PowerShell
State            : Enabled

Conclusion

Every component Cowork's own troubleshooting docs point to (VirtualMachinePlatform, vfpext.sys file presence, vmcompute, hns, an active VM switch, Hyper-V Management PowerShell) is confirmed present and functioning correctly. Despite this, Cowork's internal check still reports vfpext as a missing HCS service. This suggests the check itself — possibly relying on a stricter condition than "file exists + service registered" (e.g., checking service RUNNING state rather than STOPPED/on-demand) — is producing a false negative on this configuration.

Request

Please advise whether this is a known issue with the Cowork feature-detection logic, and if there's a workaround (e.g., manually starting the vfpext driver, or a config flag) short of a client-side patch.

Resolution

After I got all that working, I needed to clear the Claude Code cache and restart in the Help -> Troubleshoot menu. Once I did that it worked.

What Should Happen?

Claude helped with the issue but did not suggest clearing the cache and restarting before moving to the sending an item to support.
If Claude instructs the user to run all the necessary commands and finds that everything is fine on Windows, this should be the next step.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code desktop app
2. Try to toggle to CoWork and see the error message Missing HCS services: vfpext

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.216 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

I understand that this is not a Claude Code issue but a Claude Desktop issue.

[owenaslin]

Resolved this on my machine, and in my case vfpext was genuinely missing rather than a false negative from the feature check. Posting because the fix is a single Windows feature that I don't think has come up in this thread.

The key check:

Test-Path C:\Windows\System32\drivers\vfpext.sys
# False

sc.exe query vfpext
# [SC] EnumQueryServicesStatus:OpenService FAILED 1060:
# The specified service does not exist as an installed service.

Get-VMSwitchExtension -VMSwitchName "Default Switch" | Format-Table Name, Enabled, Running
# Name                                  Enabled Running
# ----                                  ------- -------
# Microsoft Windows Filtering Platform    False    True
# Microsoft NDIS Capture                   True   False

No driver on disk, no service registered, and no Azure VFP extension bound to the switch. All three agree — Cowork's Missing HCS services: vfpext was accurate.

The fix: vfpext.sys ships with the Containers optional feature, not with Hyper-V.

Enable-WindowsOptionalFeature -Online -FeatureName Containers -All

Reboot, then clear the app cache (Help → Troubleshoot → Clear Cache & Restart) — the feature-check result appears to be cached, so the app may keep reporting the stale answer until you do. Cowork initialized normally after that.

Why Hyper-V wasn't enough: I had Microsoft-Hyper-V -All already enabled (RestartNeeded: False) with a healthy Default Switch, vmcompute running, and hns running. None of that installs vfpext.sys. I'd been chasing this as a detection bug for exactly that reason.

Suggested triage step for others hitting this: run Test-Path C:\Windows\System32\drivers\vfpext.sys first. True + STOPPED service means you're in the false-negative case described above. False means the driver is actually absent and the Containers feature is what you need.

Environment: Windows 11 Pro 25H2, Build 26200.7171 · AMD Ryzen 7 5800X3D · Claude Desktop [VERSION] (MSIX x64) · Pro plan.

One note on a workaround circulating in related threads: disabling Memory Integrity / HVCI did nothing for me. Confirmed enabled, disabled it, rebooted, log entries were byte-identical. Re-enabled it and Cowork still works fine, so it's unrelated to this failure mode.