[BUG] Claude Desktop Cowork unavailable in 1.24012.9 but available in 1.24012.1 (two different machines, same Windows 11 Home build)

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?

BLUF: The toggle for Cowork is functional on 1.24012.1, but not functional on 1.24012.9. Two machines, same OS edition, different app version, different result.

New PC build from July with Windows 11 Home 26200.8875 has Claude 1.24012.9, and Cowork is unavailable. Laptop with Windows 11 Home 26200.8875 has Claude 1.24012.1, and Cowork is available and working (have not yet re-launched and updated).

Debugging with Sonnet 5 on the machine with 1.24012.9: virtualization enabled (yes), vmcompute present (yes), vmms/Containers absent (expected, Home doesn't ship them), CoworkVMService never registers, Claude Code could not find a CLI at first

What Should Happen?

The toggle should function and allow usage of Cowork on Windows 11 Home in 1.24012.9.

Error Messages/Logs

Cowork requires Claude Desktop to be installed with our modern installer.

Steps to Reproduce

Revert back to Claude Desktop version 1.24012.1, run the checks, and look for Cowork toggle and service functionality.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.24012.1

Claude Code Version

2.1.219 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Claude Code version check originally could not find a CLI, despite finding config files and harness. Debug summary directly from Sonnet 5:

Summary: claude --version check reveals missing CLI + inconsistent postinstall behavior
Environment

OS: Windows 11 Home 10.0.26200
Shells tested: Git Bash (/usr/bin/bash) and PowerShell 7+
Working directory: a non-git folder under C:\Users\user\Documents\Claude\New folder
Activity timeline

Ran claude --version in Bash → bash: line 1: claude: command not found
Ran claude --version in PowerShell → The term 'claude' is not recognized...
Searched for an existing install:
where.exe claude → no matches
npm / node / npx → none found on PATH in either shell
Checked common install locations (%APPDATA%\npm, %LOCALAPPDATA%\Programs, %USERPROFILE%\.claude, Program Files, nvm dirs) → nothing found
Notably, %USERPROFILE%\.claude did exist and contained sessions/, projects/, backups/, .credentials.json, mcp-needs-auth-cache.json — i.e., harness state/config was present, but there was no accompanying CLI binary or Node.js runtime anywhere on the machine.
Confirmed winget was available (v1.29.280) and used it to install OpenJS.NodeJS.LTS (v24.18.0) — succeeded cleanly.
Ran npm install -g @anthropic-ai/claude-code (v2.1.219) — install succeeded, but npm emitted:
npm warn allow-scripts 1 package has install scripts not yet covered by allowScripts:
npm warn allow-scripts @anthropic-ai/claude-code@2.1.219 (postinstall: node install.cjs)
npm warn allow-scripts
npm warn allow-scripts Run npm approve-scripts --allow-scripts-pending to review, or npm approve-scripts <pkg> to allow.
Despite the postinstall script apparently being blocked, claude --version immediately returned a valid result: 2.1.219 (Claude Code).
Ran npm approve-scripts --allow-scripts-pending as instructed by the warning → npm responded No packages with unreviewed install scripts. (i.e., nothing to approve).
Re-ran claude --version → still 2.1.219 (Claude Code), unchanged.
Anomalies / unexpected findings

No local CLI binary despite active harness state: ~/.claude contained session/credential data, implying Claude Code had been used on this machine before, yet no claude executable, Node.js, or npm was discoverable anywhere on disk or PATH. This suggests the harness/session runtime is decoupled from any local CLI install — worth clarifying in docs whether this is expected.
Postinstall script warning vs. actual behavior mismatch: npm install explicitly warned that install.cjs (the package's postinstall script) was not run due to allow-scripts policy. However, the CLI was immediately functional without it. Then npm approve-scripts --allow-scripts-pending reported nothing pending, contradicting the prior warning that a script was awaiting approval. It's unclear whether:
the postinstall script silently ran anyway (making the warning misleading), or
the postinstall script never ran and its effects are simply unnecessary for basic operation (making the warning noisy/unnecessary), or
allow-scripts state tracking has a bug where a flagged-pending script isn't actually queryable/approvable afterward.

This inconsistency between "script blocked, needs approval" and "no packages with unreviewed scripts" is the core reproducible oddity worth reporting.