Claude Desktop Cowork not supported on Windows LTSC despite Hyper-V being available
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,vmmsservices 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.windowsStoreisfalsefor the.exeinstallerO4t()checks ifprocess.execPathcontains awindowsappspath segment — alsofalsefor the.exeinstaller
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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗