Skip to content

[BUG] [BUG] Cowork fails on Windows 11 Home (AMD): Plan9 share 'c' HRESULT 0x8007273f; persists after full troubleshooting #72685

New issue
New issue
Closed as not planned
Closed as not planned
[BUG] [BUG] Cowork fails on Windows 11 Home (AMD): Plan9 share 'c' HRESULT 0x8007273f; persists after full troubleshooting#72685
Labels
area:coworkbugSomething isn't workinghas reproHas detailed reproduction stepsplatform:windowsIssue specifically occurs on WindowsstaleIssue is inactive

Description

@sjain-tfl
sjain-tfl
opened on Jul 1, 2026

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?

Claude Desktop's Cowork workspace fails to start every time with:

Failed to start Claude's workspace
failed to add Plan9 share 'c': HcsWaitForOperationResult failed with HRESULT 0x8007273f (result len=39)

The VM boots successfully (vm_boot completes), but fails specifically at the add_plan9_shares step. 0x8007273f corresponds to WSAEAFNOSUPPORT (address family not supported), suggesting a networking-layer failure rather than a permissions issue.

Note: checked #59320, #47556, #47211 - different HRESULT codes and root causes (access denied / missing drive / drive-letter-count theory), so filing as a distinct issue.

What I've Already Tried (all unsuccessful)

  • Added user to Hyper-V Administrators group + rebooted
  • Granted SYSTEM full permissions (icacls) on the correct MSIX-scoped data path (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude)
  • Full netsh winsock reset + netsh int ip reset + reboot
  • Enabled IPv6 binding on all network adapters (was disabled, now enabled and confirmed via Get-NetAdapterBinding)
  • Confirmed VirtualMachinePlatform enabled
  • Enabled HypervisorPlatform (was disabled) + reboot
  • Confirmed hypervisorlaunchtype = Auto via bcdedit
  • Confirmed VT-x/virtualization present via systeminfo ("A hypervisor has been detected")
  • Disabled Memory Integrity / Credential Guard via Windows Security Core Isolation + reboot (confirmed SecurityServicesRunning went from {2} to {0})
  • Confirmed no WSL2, VirtualBox, or VMware running/installed
  • Confirmed Smart App Control is off (VerifiedAndReputablePolicyState = 0)
  • Checked Microsoft-Windows-CodeIntegrity/Operational log at failure timestamp — only unrelated Nahimic audio DLL signing warnings, nothing blocking Claude
  • Checked System event log for Hyper-V/HNS/VmCompute errors at failure timestamp — vmswitch.sys loaded cleanly, no errors logged
  • Full uninstall + reinstall of Claude Desktop (multiple times)
  • Multiple full computer restarts

What Should Happen?

Cowork workspace should start successfully, with the Plan9 share mounting correctly and the VM becoming reachable.

Error Messages/Logs

2026-07-01 12:07:18 [info] [VM:steps] vm_boot completed (570ms)
2026-07-01 12:07:19 [info] [VM:steps] add_plan9_shares started
2026-07-01 12:07:19 [error] [VM:start] VM boot failed: failed to add Plan9 share 'c': HcsWaitForOperationResult failed with HRESULT 0x8007273f (result len=39)
2026-07-01 12:07:19 [error] [VM:start] Startup failed: Error: failed to add Plan9 share 'c': HcsWaitForOperationResult failed with HRESULT 0x8007273f (result len=39)
    at o7i (...\app.asar\.vite\build\index.js:964:4864)
    at async Object.startVM (...\app.asar\.vite\build\index.js:3639:9169)

Steps to Reproduce

  1. Open Claude Desktop
  2. Go to the Cowork tab
  3. Attempt to start workspace
  4. Failure occurs consistently, every attempt

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.195 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

  • OS: Windows 11 Home, 10.0.26200 Build 26200
  • Device: Lenovo Legion Pro 5-16ARX8, System SKU 82WM
  • CPU: AMD Ryzen 7 7745HX
  • Claude Desktop version: 1.17377.1.0 (MSIX, package family Claude_pzs8sxrjxfjjc)
  • BIOS: LENOVO LPCN65WW, 3/25/2026, UEFI mode, Secure Boot Off

Activity

  1. sjain-tfl
    added
    bugSomething isn't working
    on Jul 1, 2026
  2. github-actions
    added
    area:cowork
    platform:windowsIssue specifically occurs on Windows
    has reproHas detailed reproduction steps
    on Jul 1, 2026

  3. JeroBianco commented on Jul 17, 2026

    @JeroBianco
    JeroBianco
    on Jul 17, 2026

    Confirming this same HRESULT (0x8007273f) on different hardware/edition — the matching build number across both reports may be a more relevant signal than Windows edition.
    Environment

    OS: Reports as "Windows 10 Pro" / Professional via Get-ComputerInfo, but OsBuildNumber = 26200 (same build as OP's Windows 11 Home report) — WindowsVersion field shows "2009," which looks like a stale/misreported value given the build number is Windows 11-era
    Device: ASUS, System Product Name (generic/custom-built desktop)
    CPU: Intel Core i5-12600K (12th Gen) — different vendor than OP's AMD Ryzen 7745HX
    Claude Desktop version: 1.22209.0 (77c938)

    What I've tried (all unsuccessful):

    Confirmed vmcompute (Hyper-V Host Compute Service) running
    Initially found vmms (Hyper-V Virtual Machine Management) service did not exist — Hyper-V Windows feature wasn't enabled despite Pro edition supporting it
    Enabled Hyper-V via Dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /all + reboot; confirmed vmms now running
    Confirmed CoworkVMService running
    Cleared vm_bundles from MSIX-scoped path (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles) and let it redownload fresh
    Restarted CoworkVMService, fully quit/relaunched Claude Desktop
    Failure is identical: fails at add_plan9_shares with the same HRESULT 0x8007273f

    Key observation: two independent reports now share the exact same OsBuildNumber (26200) despite different CPU vendors (AMD/Intel), different reported editions (Home/Pro), and different hardware manufacturers (Lenovo/ASUS). Worth checking whether this HRESULT correlates specifically to build 26200 rather than edition or CPU — possibly a Windows networking-stack change introduced in that build that HCS's Plan9 share step doesn't handle correctly (consistent with the WSAEAFNOSUPPORT theory already raised).

  4. shanehart314-lgtm commented on Aug 3, 2026

    @shanehart314-lgtm
    shanehart314-lgtm
    on Aug 3, 2026

    Confirming this on Windows 11 Home as well — found a workaround.

    Same error: failed to add Plan9 share 'c': HcsWaitForOperationResult failed with HRESULT 0x8007273f (result len=39)

    What resolved it for me:

    1. Confirmed Windows Features enabled: Virtual Machine Platform, Windows Hypervisor Platform, Windows Subsystem for Linux (rebooted after enabling)

    2. Get-Service vmms returns "Cannot find any service" on Home edition — this is expected, not the problem. Cowork uses Virtual Machine Platform/HCS directly, not full Hyper-V (vmms), which isn't available on Home.

    3. Ran a Winsock reset, then rebooted:

       netsh winsock reset
    1. On next Cowork launch, was prompted to run:
       wsl --update

    Accepted and let it install.

    1. Error then reverted to the generic "VM service not running" message instead of the Plan9 error

    2. Checked the service status:

       Get-Service CoworkVMService | Format-List Name, Status, StartType

    It had silently stopped despite StartType: Automatic

    1. Manually restarted it:
       Start-Service CoworkVMService
    1. Cowork started successfully on next attempt

    My guess: the winsock reset addressed the actual 0x8007273f networking issue, but the WSL update + reboot cycle left CoworkVMService stopped instead of auto-restarting, which caused the follow-up error. Restarting the service by hand was the final piece.

    Hope this helps somebody, I see you also messed with winsock, but for any others having similar trouble. I'm happy to share full logs if useful.

    Additional Information:

    OS: Windows 11 Home, 10.0.26200 Build 26200
Device: MSI Thin A15 B7UCX
CPU: AMD Ryzen 5 7535hs
Claude Desktop version: 1.24012.9.0
BIOS: MSI_NB - 1072009 American Megatrends International, LLC. 3/19/2026

  5. sjain-tfl commented on Aug 3, 2026

    @sjain-tfl
    sjain-tfl
    on Aug 3, 2026
    Author

    Tried this exact sequence (wsl --update, netsh winsock reset, reboot) but no change for me, still hit the same error: failed to add Plan9 share 'c': HcsWaitForOperationResult failed with HRESULT 0x8007273f. CoworkVMService was confirmed Running throughout, so it's not the stopped-service issue you ran into. Something deeper on my end.

  6. github-actions
    added
    staleIssue is inactive
    on Aug 24, 2026

  7. github-actions commented on Sep 8, 2026

    @github-actions
    github-actionsBot
    on Sep 8, 2026 – with GitHub Actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  8. github-actions
    closed this as not plannedon Sep 8, 2026

  9. github-actions commented on Nov 8, 2026

    @github-actions
    github-actionsBot
    on Nov 8, 2026 – with GitHub Actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  10. github-actions
    locked as resolved and limited conversation to collaborators on Nov 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coworkbugSomething isn't workinghas reproHas detailed reproduction stepsplatform:windowsIssue specifically occurs on WindowsstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions