[BUG] Missing HCS services: vfpext — VFP extension never registers on virtual switch despite successful driver staging, module enable, and existing switch

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?

What's Wrong?

Cowork in Claude Desktop shows "Missing HCS services: vfpext" and the Cowork tab remains disabled. Unlike prior reports, I traced the failure past driver staging and module enablement, down to the point where the VFP switch extension fails to register with Hyper-V's virtual switch management entirely — it does not appear even as a disabled extension.

Environment

• OS: Windows 11 Pro, build 10.0.26100 (patch level 8875 as of 15/07/2026)
• Claude Desktop: latest version
• Architecture: amd64

Diagnostic sequence (in order performed)

1. Confirmed Hyper-V and all sub-features report "Enabled" via Windows Features UI.
2. Confirmed vfpext.sys payload present in WinSxS for the current build:

``
C:\Windows\WinSxS\amd64_microsoft-windows-hyper-v-vfpext_31bf3856ad364e35_10.0.26100.8875_none_9c52d2239be28c33\
`
Contents: vfpapi.dll, vfpctrl.exe, vfpext.sys — no .inf` in this folder.

1. Confirmed C:\Windows\System32\drivers\vfpext.sys does not exist (Test-Path → False), and sc.exe query vfpext returns error 1060 (service not installed).
2. Located the actual driver-install package in a separate WinSxS component:

``
C:\Windows\WinSxS\amd64_dual_wnetvsc_vfpp.inf_31bf3856ad364e35_10.0.26100.1_none_2b37ea75b2a0afbc\wnetvsc_vfpp.inf
``

1. First attempt to stage via pnputil /add-driver ... /install from a non-elevated PowerShell tab returned Added driver packages: 0, $LASTEXITCODE = 5 (ERROR_ACCESS_DENIED) — worth noting this fails silently without a clear permissions error in the pnputil output itself, which could mislead other users running from a PowerShell window they assume is elevated.
2. Re-ran from a properly elevated (Run as Administrator) PowerShell: pnputil /add-driver ... /install succeeded — Added driver packages: 1.
3. Rebooted (full Restart, not Shutdown). After reboot: vfpext.sys still absent from System32\drivers, sc.exe query vfpext still fails with 1060.
4. Checked Get-VMSwitch — failed with "term not recognized." Checked Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell → State: Disabled, despite the parent Hyper-V feature reporting "Enabled" the whole time. This means sub-features can silently fail to deploy even when the parent feature and Windows Features UI report full enablement — this alone may be the root pattern behind several of the linked issues.
5. Ran Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell -All, rebooted again. Module now reports Enabled, and Get-VMSwitch now works, returning an existing "Default Switch" (Internal type).
6. Despite an existing, functioning virtual switch, vfpext.sys is still absent and the service still doesn't exist.
7. Ran Get-VMSwitchExtension -VMSwitchName "Default Switch" — only two extensions are registered: "Microsoft Windows Filtering Platform" (Enabled: False, Running: True) and "Microsoft NDIS Capture" (Enabled: True, Running: False). The VFP forwarding extension does not appear at all — not even as a disabled/unregistered extension.

Root cause (as far as I can trace it)

The vfpext driver payload and its .inf are both present and stageable in WinSxS. Manual pnputil /add-driver staging succeeds when properly elevated. However, staging the driver package is not sufficient — the VFP extension additionally requires a registration step that ties it into Hyper-V's virtual switch extension management (visible via Get-VMSwitchExtension), and this registration step never occurs, whether triggered by feature enable, reboot, or the existence of an active virtual switch. This looks like a distinct failure point from the driver-staging issue described in #81396, and a more specific manifestation of the general "sub-feature silently not deployed despite parent feature reporting Enabled" pattern seen in #78866/#78858/#80584.

Expected behavior

What Should Happen?

Additional notes

Given that driver staging, feature enablement, and reboots all completed without error yet the extension registration step never fires, this looks like it needs to be resolved at either the Windows servicing level (Microsoft) or via a more specific/automated remediation path inside Cowork's setup flow (Anthropic), rather than something further fixable via user-side PowerShell commands. Happy to provide additional diagnostics (registry state under HKLM\SYSTEM\CurrentControlSet\Services, Get-WindowsFeature full output, etc.) if useful — but did not want to make further registry-level changes without guidance given the risk to the live networking stack.

Error Messages/Logs

Steps to Reproduce

Either:

• Hyper-V's virtual switch extension registration for VFP should complete automatically once the feature is enabled and the driver is staged (via reboot or switch creation), or
• Cowork/Claude Desktop should surface a more specific diagnostic than "Missing HCS services: vfpext" when this exact gap is detected (e.g. checking Get-VMSwitchExtension output specifically, and reporting "VFP extension not registered on any virtual switch" rather than a generic missing-service message).

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.220

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_