[BUG] Regression ~Aug 5-6 2026 (Windows): Cowork bash dies with "not supported on this device" on installs that worked for months — msix_required is now enforced and legacy installs have no upgrade path

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?

Filing this as a regression report plus a resolution, because the fix is not in any of the existing threads. #57968 is now locked and its bot message asks that a new issue be filed referencing it — hence this one. Related: #55649, #56145, #56566, #52359, #55404, and especially #84570.

What happened

Cowork's bash / Linux workspace worked normally on this machine for months — Python, pandas, parquet, file writes, everything. It stopped around 2026-08-06. Since then, every bash call returned:

Workspace unavailable. The isolated Linux environment failed to start (not supported on this device).

File tools kept working; only bash/Python was dead. Windows 11 x64, consumer plan, personal machine, not company-managed.

This is the part that matters: nothing about the machine changed. The install that had been running Cowork fine for months was suddenly declared unsupported.

The app knew why, and never said

Claude Desktop writes supported-features-info.json into its support-log export. Mine contained six entries reading:

"reason": "Cowork requires Claude Desktop be installed with our modern installer"
"unsupportedCode": "msix_required"

The client naming its own blocker, in structured form, on my disk — while the UI showed only "not supported on this device."

Get-AppxPackage -Name "*Claude*" returned nothing: the install was the legacy, non-MSIX kind. It had been that way the whole time, including all the months Cowork worked.

So the regression is not that my install was broken. It is that the msix_required gate began being enforced against installs that were previously fine, and the in-app auto-updater does not offer the packaged build — so there is no upgrade path and no notification. From the user's side the app reports it is on the latest version, and Cowork simply stops.

Possibly the same release — #84570

#84570 reports Cowork's workspace stopping on 2026-08-05, one day after an app update, on Windows, also a regression on a previously-working install. Different surface string ("Download failed" rather than "not supported on this device"), and that reporter was already on MSIX so their cause differs — but the dates are within a day of each other on the same platform. Correlation, not proof, and worth checking whether one release is behind both.

The fix that worked

1. Quit Claude completely, including the tray icon (right-click → Quit). Closing with X is not enough — see the secondary bug below.
2. Download from claude.com/download.
3. Right-click the installer → Run as administrator.

Anthropic's own docs state that without admin rights the app installs fine but Cowork will not be available — exactly the "installs cleanly, Cowork silently absent" symptom.

After:

Get-AppxPackage -Name "Claude" | Select-Object Name, Version, SignatureKind, InstallLocation
→ Claude 1.30096.5.0 Developer C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc

bash runs again. First launch spent several minutes on "Workspace still starting" while it downloaded the VM bundle.

That message change is a useful signal in itself. "not supported on this device" means the client refused before trying; "Workspace still starting" means it is booting. If your error moves from the first to the second, it is working — wait rather than assuming a new failure.

One thing I enabled that I now believe was NOT the cause

I also found Windows HypervisorPlatform set to Disabled (a separate optional feature from VirtualMachinePlatform, which was Enabled) and turned it on before the reinstall:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All -NoRestart

I am reporting this as probably irrelevant, not as part of the fix. Cowork had worked for months on this machine with that feature Disabled, so it cannot have been required. #84570 independently reports enabling it changed nothing. I never tested it in isolation against a working install, so I cannot rule it out — but anyone reading this should treat the MSIX reinstall as the fix and this as noise I am disclosing for completeness.

Correction to advice circulating from #37312

Guides derived from #37312 suggest SignatureKind: Developer indicates a broken per-user sideload requiring removal and Add-AppxProvisionedPackage. Please be careful. Developer is the normal value for any MSIX installed from a vendor website — Store is reserved for Microsoft Store delivery and is unreachable from claude.com. My working install reports Developer. Acting on that guidance means uninstalling a healthy app; it nearly cost me one.

Secondary bug — pending updates are invisible if you close with X

I close the app with the X in the title bar rather than File → Exit, which leaves it running in the tray. I was never shown that an update was pending. Given that install state was the whole root cause here, "closed the window" and "quit the app" looking identical to the user while meaning very different things to the updater is a real trap. A tray badge or a prompt on next window open would close it.

Three requests

1. Do not silently revoke Cowork from installs that were working. If a gate like msix_required starts being enforced, the affected user needs to be told, in the app, at the moment it happens.
2. Surface the real unsupportedCode reason in the UI. The client has both the diagnosis and the remedy and displays neither. Anyone who would think to export and unzip a support-log bundle did not need the hint.
3. Give the in-app assistant the client's capability report and post-update changelog. Claude spent two days troubleshooting Windows services that were healthy, reading GitHub issues about three different app versions, because it had no view of what this build changed or what the client already knew about itself. It should be able to check the app before it troubleshoots the operating system.

Scope caveat

This is what fixed my machine. #56566 looks different (that reporter has CoworkVMService running and a vm_bundles directory; their VM hangs at boot rather than being refused). If your supported-features-info.json does not say msix_required, this is not your problem.

What Should Happen?

Three things:

1. A working Cowork install should not silently stop working. If a capability gate such as msix_required begins being enforced, the app should tell the affected user at that moment and explain what to do — not simply start refusing.

1. When Cowork is unavailable because of msix_required, the UI should say so and name the remedy ("Claude Desktop needs to be reinstalled with the modern installer, as administrator") instead of the dead-end string "not supported on this device". The client already holds this in structured form in supported-features-info.json.

1. The in-app updater should either offer the packaged (MSIX) build to users on legacy installs, or detect the legacy install and say plainly that Cowork cannot work until they reinstall. Reporting "you are on the latest version" while Cowork is gated off with no upgrade path is what turned this into a two-day investigation.

Error Messages/Logs

--- The UI error, every bash call, for two days ---
Workspace unavailable. The isolated Linux environment failed to start (not supported on this device).

--- What supported-features-info.json actually said (6 entries, verbatim) ---
"yukonSilver":                        {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}
"yukonSilverGems":                    {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}
"yukonSilverGemsCache":               {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}
"coworkKappa":                        {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}
"coworkArtifacts":                    {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}
"coworkAutoModeAlwaysAllowOverride":  {"status":"unsupported","reason":"Cowork requires Claude Desktop be installed with our modern installer","unsupportedCode":"msix_required"}

--- BEFORE the fix ---
PS> Get-AppxPackage -Name "*Claude*" | Select-Object Name, Version, SignatureKind, InstallLocation
(returned nothing)

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

PS> Get-Service | Where-Object { $_.Name -match 'claude|cowork|anthropic|vmservice' }
(returned nothing)

PS> Get-WindowsOptionalFeature -Online | Where-Object { $_.FeatureName -match 'VirtualMachinePlatform|HypervisorPlatform|Microsoft-Hyper-V-All' } | Select FeatureName, State
VirtualMachinePlatform    Enabled
HypervisorPlatform        Disabled      <-- required, and OFF
Microsoft-Hyper-V-All     Disabled

%APPDATA%\Claude\vm_bundles                 : absent
Test-Path "$env:LOCALAPPDATA\AnthropicClaude" : True   (legacy install layout)

--- AFTER: enable HypervisorPlatform + reboot, then reinstall as administrator ---
PS> Get-AppxPackage -Name "*Claude*" | Select-Object Name, Version, SignatureKind, InstallLocation
Name    Version       SignatureKind  InstallLocation
----    -------       -------------  ---------------
Claude  1.30096.5.0   Developer      C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc

bash:
  first several minutes -> "Workspace still starting. The isolated Linux environment is booting in the background."
  then ->
    Linux claude 6.8.0-124-generic #124~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
    2 cores / 3.8Gi RAM, mounted folders present and writable

Note the error string changed CLASS, not just wording: "not supported on this device" is a capability
gate (the client refuses before trying); "Workspace still starting" is first-boot VM provisioning.

Steps to Reproduce

The regression:

1. On Windows, have Claude Desktop installed via the legacy (non-MSIX) installer — Get-AppxPackage -Name "*Claude*" returns nothing — and have Cowork bash working normally. This was my state for months.
2. Around 2026-08-05/06, bash begins failing on every call with "Workspace unavailable. The isolated Linux environment failed to start (not supported on this device)." Nothing on the machine changed. File tools keep working.
3. Apply in-app updates. The app reports it is on the latest version and the symptom does not change — the auto-updater does not offer the packaged build, so there is no path out from inside the app.

To see the diagnosis the app is already holding:

1. Export the support-log bundle, unzip it, open supported-features-info.json. Six entries read "unsupportedCode": "msix_required" with the remedy in the reason field. None of this is shown in the UI.

To fix:

1. Quit Claude completely, including the tray icon (right-click → Quit).
2. Download from claude.com/download, right-click the installer → Run as administrator.
3. Reopen Claude and run a bash command. First launch returns "Workspace still starting" for several minutes while the VM bundle downloads, then succeeds.

Note: I had also enabled Windows HypervisorPlatform before step 5, but I do not believe it was the cause — Cowork had worked for months with it Disabled. See the body.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Worked until ~2026-08-05/06; exact prior build not recorded. Failing build was 1.30096.1.

Claude Code Version

Claude desktop app (Cowork) — NOT the Claude Code CLI. Failing: 1.30096.1 (legacy non-MSIX install). Working after fix: 1.30096.5.0 (MSIX, SignatureKind Developer).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is the Claude desktop app in Cowork mode on Windows, not the Claude Code CLI.

Timeline: bash worked normally on this machine for months (Python, pandas, parquet, file writes) and stopped around 2026-08-06. I did not notice an app update at the time — see the tray/X bug in the body, which is likely why.

Ruled out during the investigation, all verified by reading the machine rather than assuming:

• Hardware virtualization enabled in firmware; 63.9 GB RAM; ample free disk.
• vmcompute and hvhost both Running. A full day went into these; they were healthy the entire time and were never the problem.
• Not an account, plan or usage limit: cloud Cowork bash worked on the same account while local bash failed, isolating the fault to this machine.
• Not fixable via the cloud/browser path: browser cloud sessions get no bridge to local folders, tested with device verification both on and off.
• Antivirus quarantine considered and judged unlikely — AV typically quarantines the binary and leaves the service registration behind; here no Claude service registration existed under any name.

Two things that would have found this on day one, and neither was available:

1. The unsupportedCode value shown anywhere in the UI.
2. A changelog visible to the in-app assistant after an update. It reasoned from GitHub issues describing app versions 1.1.7714.0 and 1.5354.0.0 while running on 1.30096.1 — three different builds — and inherited a wrong claim from one of them (the SignatureKind: Developer guidance addressed in the body), which nearly led to uninstalling a healthy install.

Hope it helps, if added info needed reach out.