Claude Desktop Cowork not supported on Windows LTSC despite Hyper-V being available

Resolved 💬 4 comments Opened Mar 28, 2026 by stableMinds Closed Mar 28, 2026

Description

Claude Desktop's Cowork feature (YukonSilver) is blocked on Windows 10/11 IoT Enterprise LTSC editions, even though all required infrastructure (Hyper-V, HCS, Containers) is fully functional.

Environment

  • OS: Windows 10 IoT Enterprise LTSC 2024 (Build 26100, 24H2)
  • EditionID: IoTEnterpriseS
  • Claude Desktop: 1.1.9310 (.exe / Squirrel installer)
  • Hyper-V: Enabled and running (vmcompute, vmms services active)
  • Containers feature: Enabled
  • HCS: Working (verified via hcsdiag list)

The Problem

1. MSIX installer requirement

The xl() function in app.asar checks whether the app was installed via MSIX/Microsoft Store:

function xl() {
  return Cs
    ? w5 !== void 0 ? w5
    : process.windowsStore ? (KW = "windowsStore", w5 = true, true)
    : O4t() ? (KW = "appPath", w5 = true, true)  // checks for "windowsapps" in execPath
    : (KW = null, w5 = false, false)
    : false;
}
  • process.windowsStore is false for the .exe installer
  • O4t() checks if process.execPath contains a windowsapps path segment — also false for the .exe installer

When xl() returns false, aun() returns {status: "unsupported", unsupportedCode: "msix_required"} and Cowork is disabled.

Windows LTSC does not include the Microsoft Store, so the MSIX package cannot be installed. The .exe installer is the only option, but it fails this check.

2. VM bundle cleanup

cleanupVMBundleIfUnsupported() runs on every startup and deletes the Cowork VM bundle files when the feature is detected as unsupported, making it impossible to use Cowork even if the check were bypassed later in the same session.

Expected Behavior

Cowork should check for the actual required capabilities (Hyper-V, HCS, Containers) rather than the installer type. All the infrastructure Cowork needs is present and functional on LTSC:

| Requirement | Status on LTSC |
|------------|---------------|
| Hyper-V | Enabled |
| vmcompute service | Running |
| vmms service | Running |
| Containers feature | Available and can be enabled |
| HCS (Host Compute Service) | Working |
| hcsdiag list | Returns running VMs |

Workaround

Creating a directory junction to make the .exe version appear to run from a WindowsApps path satisfies the O4t() check:

New-Item -ItemType Junction -Path "$env:LOCALAPPDATA\WindowsApps\Claude" -Target "$env:LOCALAPPDATA\AnthropicClaude\app-<version>"

Launching from the junction path makes process.execPath contain WindowsApps, so xl() returns true and Cowork proceeds to load the VM module successfully.

Suggested Fix

Replace the MSIX installer check with a capability check. The aun() function already has an HCS availability check — the MSIX check (xl()) could be removed or made non-blocking on Windows, since the actual VM infrastructure is what matters, not the installer type.

Impact

Windows LTSC is widely used in:

  • Enterprise environments with strict update policies
  • IoT and embedded systems
  • Government and regulated industries
  • Development workstations that need long-term stability

These are exactly the environments where Claude Desktop's Cowork feature would be most valuable.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗