[BUG] Cowork tab missing on Windows 11 Home 25H2 (Build 26200) - yukonSilver status=unsupported persists across 1.18286.0/1.18286.2/1.19367.0 despite virtualization fully enabled

Understood — this is a different failure mode (my backend stays healthy). I've split it out into #75642. Thanks for the pointer, @jackhstar!

Same missing-Cowork-tab symptom, but with an important difference: my VM backend is fully healthy the whole time — so this looks like a pure UI render/recovery bug, and for me it's a clean regression from 1.18286.2 → 1.19367.0. Adding my data in case it helps narrow it down. (Full sanitized log attached.)

Environment

• Windows 10 Pro 19045 (x64)
• Claude Desktop 1.19367.0.0 — MSIX, Publisher "Anthropic, PBC" (sideloaded, self-updating; not the Store)
• Plan: Max

Clean regression — the broken build went live this morning

2026-07-08 07:59:13 [updater] Version changed since last launch: 1.18286.2 → 1.19367.0

The Cowork tab worked fine on 1.18286.2 (daily use). It broke the moment 1.19367.0 became active.

Backend is healthy — unlike most reports here, yukonSilver is NOT "unsupported"

• VM boots fine: [VM:start] Startup complete … [VM] API reachability: REACHABLE
• Every launch: [WarmLifecycle:cowork] Initialized, [CoworkFilePreview] Protocol handler registered, coworkHipaaRestricted: unrestricted
• gate=claudeai_cowork_backend_marketplaces value=true
• Services vmcompute + hns Running (Automatic); CoworkVMService Running
• No YukonSilver not supported / no cleanupVMBundleIfUnsupported event on 2026-07-08 at all (that string appears only in mid-June, when the HCS services happened to be down).

Likely trigger (repro hypothesis)

Multi-monitor setup. The app was backgrounded ~86 min during a browser session, then I refocused it, moved it to another monitor and maximized it. The UI re-initialized with brief hangs:

10:58:46 [CCD] LocalSessions.setFocusedSession: sessionId=null
10:58:57 / 11:01:16 [event-loop-stall] main process blocked
[WarmLifecycle:cowork] Destroyed / Initialized (cycling)

After this UI re-init the Cowork tab was gone — while the backend stayed fully supported.

Doesn't recover

Full app restart, full PC reboot, and reinstall of the same 1.19367 MSIX did not bring the tab back. There is no toggle to re-enable it anywhere (sidebar customize / Cowork settings / General settings). The download at claude.com is also 1.19367.0.0, so reinstalling can't help.

Happy to test a pre-release/fix build. 👍

cowork-tab-bug-log-excerpt.txt

@wittmoo Thanks for the data point — I think yours is a different failure mode, so I want to keep this issue scoped to avoid confusing triage.

In my case the VM backend is never healthy and never started:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[warm] Skipping VM warm download - YukonSilver not supported
[LocalAgentModeSessionManager] no VMAPI; cliPluginBridge not registered

So this is a platform-detection failure, not a UI render/recovery bug. Other differences:

| | This issue | wittmoo |
|---|---|---|
| OS | Windows 11 25H2, Build 26200.8655 | Windows 10 Pro 19045 |
| VM backend | never starts (status=unsupported) | reported healthy |
| Affected versions | 1.18286.0, 1.18286.2 and 1.19367.0 | clean 1.18286.2 → 1.19367.0 regression |

A separate issue for the UI-render case would probably get a faster, better-targeted fix.

---

Additional signal for maintainers

1. This looks like the same root cause as #34920 (yukonSilver gated behind GrowthBook feature-flag targeting, with some machine configurations incorrectly excluded). My logs show the flag set loading immediately before the unsupported verdict:

[growthbook] loaded 204 features (204 changed)
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)

Meanwhile the platform is objectively capable:

• HypervisorPlatform : Enabled
• VirtualMachinePlatform : Enabled
• HyperVisorPresent : True

2. cleanupVMBundleIfUnsupported makes this unrecoverable. When detection returns unsupported, this function also cleans up the existing VM bundle. Cowork was working on this exact machine until an auto-update; once the regressed build ran, the previously-provisioned bundle was removed. So affected users cannot recover by reinstalling or downgrading — every available installer re-triggers the cleanup. This may explain the "reinstall doesn't help" reports across #28238, #27445, #47327, #32837.

**3. Possible discriminator for why only some Build 26200 users are affected.** VBS is active on this machine:

• VirtualizationBasedSecurityStatus : 2 (running)
• SecurityServicesRunning : 3,4 (System Guard Secure Launch, SMM firmware measurement)
• Note: Memory Integrity / HVCI (code 2) is not running.

If the yukonSilver support check mis-handles VBS/DRTM-active configurations, that would explain why many Build 26200 machines are fine while a subset is not. Worth checking against the flag targeting rules in #34920.

Happy to provide full logs or run any diagnostic command that would help.

Controlled negative test: HCS services are not the cause

Following up on the suggestion that yukonSilver not supported correlates with the HCS services being down (vmcompute / hns) — I tested this directly. It does not hold on my machine.

Test

vmcompute was Stopped (StartType Manual, demand-start). I set it to Automatic, started it, and confirmed it stayed Running (no stop events in the Service Control Manager event log). Then I fully quit and relaunched Claude Desktop.

Result — still unsupported, with every prerequisite satisfied

vmcompute : Running   (StartType=Automatic)
hns       : Running
HvHost    : Running

Claude Desktop 1.19367.0 launched 21:32:03
21:32:11 [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
21:32:11 [LocalAgentModeSessionManager] no VMAPI; cliPluginBridge not registered

The detection ran 8 seconds after launch, while vmcompute was demonstrably Running.

Full prerequisite state at detection time

| Prerequisite | State |
|---|---|
| HypervisorPlatform | Enabled |
| VirtualMachinePlatform | Enabled |
| HyperVisorPresent | True |
| vmcompute | Running (Automatic) |
| hns | Running |
| HvHost | Running |
| vmms | absent (Windows Home — expected) |
| CoworkVMService | absent (never registered, even after an Administrator reinstall) |

Why this matters

Every locally controllable prerequisite is satisfied, and yukonSilver is still classified unsupported on all three builds I tested (1.18286.0, 1.18286.2, 1.19367.0). This rules out the HCS-services explanation and points squarely at the platform-detection / feature-flag path — consistent with the GrowthBook flag-targeting hypothesis in #34920.

Environment: Windows 11 Home 25H2, Build 26200.8655 (x64), Max plan.

Still happy to run any diagnostic or test a pre-release build.

@jackhstar Adding a data point that speaks directly to your VBS/DRTM discriminator hypothesis in point 3 above.

Environment

• Claude Desktop: 1.19367.0 (1a5be1)
• OS: Windows 11 Enterprise, 25H2, Build 26200.8655 — same build as this issue (note: registry ProductName key stale-reports "Windows 10 Enterprise" from an in-place upgrade; DisplayVersion/CurrentBuildNumber confirm Windows 11 25H2)
• Managed corporate machine, local admin rights available

Same symptom, same logs

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Chat mode works normally; only Cowork is affected. Broke immediately after the 2026-07-07 auto-update to 1.19367.0. No Windows update since June 2026, ruling that out. No other team member on the same Claude Desktop version shows this symptom, consistent with a config-dependent rather than blanket regression.

The discriminator you're looking for — here's a data point that differs from your own case

• VirtualizationBasedSecurityStatus : 2 (running)
• SecurityServicesRunning : 1, 2, 4... — Memory Integrity/HVCI (code 2) IS running here, unlike your machine where it's confirmed off.
• HypervisorPlatform / VirtualMachinePlatform : both enabled, hypervisor present — same as you.

So if the yukonSilver check is mis-handling VBS/DRTM-active configurations broadly, this suggests the mis-detection isn't specific to HVCI being on or off — both configurations (yours without HVCI, mine with HVCI) trip the same "unsupported" verdict. That would point more toward VBS itself (or a related security service) as the trigger for the GrowthBook flag mis-targeting in #34920, rather than HVCI specifically.

One difference from your case worth flagging
Get-Service CoworkVMService here returns the service as registered (StartType: Automatic), just permanently stuck in Status: Stopped — rather than "service not found" as in your report. Not sure yet whether this is a meaningful variant or just a timing/cleanup artifact (e.g., an older working bundle not yet fully purged). Flagging in case it's useful for narrowing which code path handles the "unsupported" verdict on registration vs. runtime.

Also avoided "Reinstall workspace" for the reason you flagged — didn't want to risk triggering cleanupVMBundleIfUnsupported on a bundle that might still be partially intact. Happy to pull additional logs or run diagnostics if useful for narrowing the GrowthBook targeting rule.

Quick note to prevent this from being closed as resolved alongside #75642.

That issue was a UI-gating case with a healthy backend, resolved by a server-side UI rollout. This issue is different: the VM backend is never supported here.

Still reproduces on my machine as of today (2026-07-09):

2026-07-09 08:56:39 [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)

No app or config change on my side. All prerequisites remain satisfied (HypervisorPlatform + VirtualMachinePlatform Enabled, vmcompute/hns/HvHost Running). The "Cowork's new home" rollout does not apply, since there is no supported VM backend to surface regardless of where the entry point lives.

Please keep this open as a platform-detection / feature-flag issue (see #34920), distinct from the UI-gating case in #75642.

Environment:

OS: Windows 11 Pro x64
Claude Desktop: 1.19367.0 (EXE installer, AnthropicClaude)
Hyper-V: Enabled (Microsoft-Hyper-V-All)
VirtualMachinePlatform: Enabled
vmms: Running
WSL: Disabled (not required, Hyper-V full stack present)
Antivirus: Trend Micro Apex One 6.7.4166 + Windows Defender (inactive)

Symptom:
Cowork tab absent. cowork_vm_node.log repeats:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Steps taken without resolution:

Enabled Hyper-V + VirtualMachinePlatform (were missing initially)
Deleted vm_bundles completely — bundle re-downloads and extracts successfully (All files ready)
VM starts but CoworkVMService crashes on named pipe: connect ENOENT \\.\pipe\cowork-vm-service
Uninstalled MSIX (Store version), installed EXE version — same yukonSilver result
Trend Micro exclusions added for Claude paths

Conclusion:
Bundle download works. Hyper-V stack complete. yukonSilver detection incorrectly marks system as unsupported on version 1.19367. Cowork was working previously on this machine.

Consolidating the corroborations from @Christophe-Lamontagne and @JoseRB2 — thanks both.

This now spans every Windows edition, which rules out an edition/virtualization-config cause:

• Home (me): VBS on, HVCI off
• Enterprise (@Christophe-Lamontagne): Build 26200.8655, VBS on, HVCI on
• Pro (@JoseRB2): full Hyper-V + vmms running

All three have virtualization fully enabled and all three hit the identical yukonSilver not supported (status=unsupported) verdict on 1.19367.0. It is purely app-side detection.

Refined VBS hypothesis: since HVCI-on (Christophe) and HVCI-off (me) both fail, the discriminator is likely VBS itself (or a related DRTM/security service), not HVCI specifically. Worth checking against the GrowthBook targeting rule in #34920.

Three variants of CoworkVMService state, all ending in unsupported — may help isolate the code path:

• not registered / "service not found" (me)
• registered Automatic but stuck Stopped (@Christophe-Lamontagne)
• starts, then crashes on named pipe connect ENOENT \\.\pipe\cowork-vm-service (@JoseRB2)

Common denominator: all broke on the auto-update to 1.19367.0 (worked on the prior build), no Windows update in the relevant window.

Resolved on my machine as of 2026-07-09 ~21:20 (KST), via what appears to be a server-side rollout — the app version was unchanged (1.19367.0) throughout.

yukonSilver flipped from unsupported to supported between two launches today:

19:21:57  yukonSilver not supported (status=unsupported)
21:20:54  [VM] Module loaded successfully

After the flip, the VM bundle re-downloaded and booted cleanly:

21:31:42  [VM:start] Startup complete
21:31:57  [VM] API reachability: REACHABLE

No local change, no reinstall, no version bump fixed it — consistent with the GrowthBook feature-flag targeting hypothesis in #34920.

Thanks @wittmoo — your note that Cowork had moved to the new "+ → Chat / Cowork" composer picker (rather than the old top tab bar) was accurate and helped me locate the entry point once the backend came back. For clarity to others: in my case the blocker was the backend detection (yukonSilver unsupported), separate from that UI relocation.

For anyone still affected (@JoseRB2, @Christophe-Lamontagne): this was a real backend detection bug fixed server-side, likely a staged rollout. Worth watching cowork_vm_node.log for the unsupported→supported transition. Closing mine as resolved.

My case, report made by Claude ;-)
Reproduction report (2026-07-10)

Environment:

• CPU: Intel Core i7-1255U (12th Gen)
• OS: Windows 11 Pro x64
• Claude Desktop: 1.20186.0 (EXE installer, AnthropicClaude)
• Antivirus: Trend Micro Apex One 6.7.4166 + Windows Defender (inactive)

Hyper-V stack — all present:

• Microsoft-Hyper-V-All: Enabled
• VirtualMachinePlatform: Enabled
• vmms: Running
• VTx: Enabled in BIOS/UEFI (confirmed, locked by firmware virtualization protection)

Symptom:

• Cowork tab absent from Claude Desktop
• cowork_vm_node.log repeats on every launch:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)

• main.log: [warm] Skipping VM warm download - YukonSilver not supported
• CoworkVMService: not registered

Root cause identified:

• VBS (Virtualization Based Security) active: VirtualizationBasedSecurityStatus=2
• HVCI/Memory Integrity running: SecurityServicesRunning={2}
• Result: VMMonitorModeExtensions=False, SecondLevelAddressTranslationExtensions=False
• yukonSilver interprets missing nested virtualization extensions as unsupported platform

Workaround attempts:

1. Disabled HVCI via registry → SecurityServicesRunning changed to {0} — extensions still False
2. Disabling VBS completely pending reboot — not acceptable long-term in corporate environment

Steps taken before identifying root cause:

• Enabled Hyper-V + VirtualMachinePlatform (were missing initially) → no fix
• Full vm_bundles deletion and re-download → bundle downloads successfully, VM fails to start
• Uninstalled MSIX Store version, installed EXE version → no fix
• Added Trend Micro exclusions for Claude paths → fixed bundle download, yukonSilver persists
• CoworkVMService pipe error: connect ENOENT \\.\pipe\cowork-vm-service

Conclusion:
yukonSilver capability check requires VMMonitorModeExtensions and
SecondLevelAddressTranslationExtensions (nested virtualization) which are unavailable
when VBS/HVCI is active. These extensions are not required for standard Hyper-V VM
execution. Fix needed: yukonSilver should verify basic Hyper-V capability
(vmms running + VTx enabled) instead of nested virtualization extensions,
which are consumed by Windows security features in corporate environments.