Cowork fails on ARM64 (Snapdragon X) despite passing readiness check

Add a comment with: Surface Laptop (the specific model — 7th Edition, I'd guess), Snapdragon X Plus 8-core at 3.30 GHz, Windows 11 Pro ARM64, Claude Desktop 1.3561.0 (fbc74b), confirmed ARM64 process, network range 192.168.86.x (no conflict), VPN disconnected, readiness check all green, timeout reproduces 100%.

+1 laptop lenovo System Type ARM64-based PC, Processor Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Oryon(TM) CPU, 3244 Mhz, 8 Core(s), 8 Logical Processor(s)

Gleiches Symptom, gleiche Plattformklasse — aber neue Diagnose-Daten, die auf eine Regression zwischen ca. 1.36xx und 1.3883 hindeuten.

System

• CPU: Qualcomm Snapdragon X (Oryon), 8 Cores
• Architektur: ARM64
• OS: Windows 11 Home, Build 26200
• Claude Desktop: 1.3883.0.0 (MSIX, natives ARM64 — Claude_1.3883.0.0_arm64)

Vorher / Nachher

• Letzter erfolgreicher Start auf derselben Maschine: 19.04.2026, ~07:49 Uhr. VM bootete in ~27 Sekunden, [coworkd] connected, waiting for commands — mit der damals noch windows-service-basierten Architektur (CoworkVMService → cowork-service.log → coworkd/user-…log via Daemon-Console-Pipe).
• Seit dem Update auf 1.3883: 0 von 4 Startversuchen erfolgreich. Genau das in #50674 beschriebene Symptom — UI: "VM connection timeout after 60 seconds", Readiness Check zeigt alles grün.

Neue Architektur (entdeckt beim Debuggen)

Die App nutzt in 1.3883 nicht mehr den Windows-Service CoworkVMService, sondern einen eingebetteten VM-Manager direkt im Electron-Prozess. Der relevante Log ist jetzt:

​``
%LocalAppData%\Packages\Claude_<id>\LocalCache\Roaming\Claude\logs\cowork_vm_node.log
​``

Der alte C:\ProgramData\Claude\Logs\cowork-service.log wird in 1.3883 zwar noch geschrieben, aber nur für Service-Internes — der tatsächliche VM-Lifecycle läuft komplett am Windows-Service vorbei. Wer sich bei #40198 / #46516 / #50674 auf den alten Pfad stützt, debuggt ins Leere.

Konkrete Fehlerstelle

Aus cowork_vm_node.log, vier Startversuche hintereinander (gekürzt, Zeitstempel umbenannt):

​``
[VM:steps] download_and_sdk_prepare completed (3ms)
[VM:steps] load_swift_api completed (0ms)
[VM:start] Copying smol-bin.arm64.vhdx to bundle: …\smol-bin.arm64.vhdx → …\smol-bin.vhdx
[VM:start] smol-bin.arm64.vhdx copied successfully
[VM:start] Configuring Windows VM service...
[VM:start] Windows VM service configured
[VM:steps] create_vm_config completed (114ms)
[VM:steps] vm_boot completed (114ms)
[VM:steps] add_plan9_shares completed (7ms)
[VM:start] Still waiting for guest connection... 10102ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20253ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30428ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40599ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50765ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
[info] Dispatching startup error: VM connection timeout after 60 seconds
[error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
[VM:start] Skipping auto-reinstall (already attempted once)
​``

Host-Seite ist sauber:

• vm_boot — 102–114 ms
• add_plan9_shares — 6–7 ms (sowohl für c:\ als auch für g:\ — der Plan9-g-Fehler aus früheren Issues ist vollständig behoben)
• vmmem-Prozess allokiert 450–480 MB RAM → die Linux-VM läuft tatsächlich als Hyper-V-VM

Guest-Seite ist tot:

• Keinerlei vsock-Connect-Attempt aus der VM heraus
• Im main.log dutzende Polls mit vm_guest_connected: false
• Kein Gast-Konsolen-Output sichtbar (unklar, ob der neue embedded Manager die Daemon-Console überhaupt noch mitschneidet — falls ja, nicht in den üblichen logs/-Pfaden)

Folgefehler: "VM is already running" + EBUSY

Schlägt der Start fehl, räumt der Manager die Hyper-V-VM nicht zuverlässig ab:

​``
[VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
[VM:start] Configuring Windows VM service...
[VM:start] Windows VM service configured
[error] [VM:start] VM boot failed: VM is already running
​``

Nachfolgende Versuche scheitern dann nicht mehr am Guest-Connection-Timeout, sondern direkt an der orphaned VM. Erst wenn die App komplett beendet wird (inkl. Tray), ist der Zustand wieder sauber.

[KernelBugMonitor]

Im Log taucht ein [KernelBugMonitor] State reset vor jedem Startversuch auf. Das interne Monitoring greift offenbar — nur scheint es den Fall "Guest-Daemon meldet sich innerhalb von 60 s gar nicht" nicht zu erfassen (keinerlei Kernel-Bug-Report in den Logs, trotz wiederholtem Timeout).

Vermutung

Die Regression liegt vermutlich im neuen embedded VM-Manager selbst oder in einem geänderten Boot-Pfad (neue smol-bin.arm64.vhdx, neue initrd-Logik). Auf derselben Maschine mit derselben vmlinuz/initrd (Zeitstempel 31.03.2026) lief der alte windows-service-basierte Pfad am 19.04. noch sauber durch. Irgendetwas am neuen Start-Handshake funktioniert auf ARM64-Hyper-V nicht.

Was hilfreich wäre

• Guest-Konsolen-Log im neuen Manager — aktuell gibt es keinen sichtbaren Kernel-/Daemon-Output mehr, der Nutzer (und ihr) debuggen blind.
• Höherer oder konfigurierbarer Timeout auf ARM64 — selbst auf funktionierenden Starts hat diese Plattformklasse früher 27 s gebraucht, 60 s sind knapp.
• Sauberes Aufräumen bei Fehlstart — aktuell bleibt die fehlgeschlagene VM liegen und blockiert den nächsten Start mit EBUSY.
• KernelBugMonitor sollte auch den Fall "Daemon schweigt" erfassen, nicht nur echte Kernel-Panics.

Logs (cowork_vm_node.log, main.log, Teile von cowork-service.log) können auf Anfrage hochgeladen werden.

Additional ARM64 / Snapdragon data point — same symptom, fresh logs
Hitting the same failure on Snapdragon ARM64. Posting matched host + client logs since the host side is clean and the failure is strictly on the guest sdk-daemon connect-back on hvsock port 51234 — which matches the root cause analysis in this thread.
Environment

Device: Lenovo IdeaPad Slim 3 15Q8X10
Processor: Snapdragon X – X126100 – Qualcomm Oryon CPU (2.96 GHz)
RAM: 16 GB
OS: Windows 11 Home, Version 25H2, Build 26200.8328
Architecture: ARM64 (64-bit, ARM-based processor)
Claude Desktop: 1.7196.0.0_arm64 (Microsoft Store, package Claude_pzs8sxrjxfjjc)
Cowork Readiness Check: Passes / SUPPORTED
Reproduction: 100%, every launch since first install

Client log (cowork_vm_node.log) — last completed step is always add_plan9_shares
[VM:steps] vm_boot completed (305ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (7ms)
[VM:start] Still waiting for guest connection... 10122ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20286ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30457ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40683ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50841ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
[error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
Host service log (C:\ProgramData\Claude\Logs\cowork-service.log) — all host-side ops succeed
[HCS] HcsCreateComputeSystem returned: hr=0x0
[HCS] HcsStartComputeSystem returned: hr=0x0
[HVSock] Listening on port 51234 (service GUID: 0000c822-facb-11e6-bd58-64006a7986d3)
[HVSock] Listening on port 1024 (service GUID: 00000400-facb-11e6-bd58-64006a7986d3)
[RPC] Server started, waiting for sdk-daemon connection on port 51234
[HCS] HcsModifyComputeSystem returned: hr=0x0 (Plan9 share added)
[VM] VM started successfully
[Console] Connected to daemon console pipe
After this point, the host RPC server sits indefinitely waiting for the guest sdk-daemon to connect on hvsock port 51234. The guest never connects. 60 seconds later the client times out.
Diagnosis (consistent with the root cause described upthread)

HCS compute system creation/start: ✓ (hr=0x0)
File ACL grants (rootfs / vmlinuz / initrd / smol-bin / sessiondata): ✓
Virtual network creation (172.16.10.0/24): ✓
Host HVSock listeners on 1024 and 51234: ✓
Plan9 share c -> C:\ via HcsModifyComputeSystem: ✓
Daemon console named-pipe connection: ✓ (implies VirtioSerial init in the guest)
Guest sdk-daemon HVSock connect-back on port 51234: ✗ (never arrives)

The daemon console pipe connecting suggests the Linux kernel reaches at least early init / VirtioSerial setup, but sdk-daemon either never starts or can't establish the vsock connection. Same chip family as Issue #46033 (also Snapdragon X X126100, different OEM — ASUS Zenbook A14 vs Lenovo IdeaPad Slim 3) — pattern suggests a guest-side issue specific to this Snapdragon SKU.
What I've tried (none successful)

Full uninstall + reinstall of Claude Desktop
Deleting vm_bundles\claudevm.bundle to force fresh download/decompress (all artifacts checksum-validate on re-extract)
Reboot
Launching Claude as administrator
Confirmed VirtualMachinePlatform and HypervisorPlatform Windows features are enabled

Happy to provide
Full unredacted cowork_vm_node.log, cowork-service.log, and coworkd/user-*.log on request.

Kommentar zu Issue #50674 — Vierter Snapdragon X X126100 Datenpunkt, Regression seit ~1.36xx, computer-use Fallback bestätigt

Link zum Issue: https://github.com/anthropics/claude-code/issues/50674

---

Bestätige @kendall25678's Diagnose — selbe CPU-SKU (Snapdragon X X126100), drittes OEM-Gerät mit identischem Symptom. Zusätzlich zwei Punkte, die in den bisherigen Berichten fehlen: eine konkrete Regression auf derselben Maschine, und das computer-use-Fallback-Verhalten von Cowork, wenn die lokale VM nicht hochkommt.

System

• CPU: Qualcomm Snapdragon X (Oryon) — X126100 (gleiche SKU wie @kendall25678 und #46033)
• Architektur: ARM64
• OS: Windows 11 Home, Build 26200
• Claude Desktop: 1.4758.0.0 (MSIX, natives ARM64), heute (27.04.) reproduziert. Auch in 1.3883.0.0 reproduzierbar.
• Cowork Readiness Check: Passes / SUPPORTED
• Reproduktion: 100% seit dem Architekturwechsel (siehe unten)

Datenpunkt 1: Regression auf derselben Hardware

19.04.2026 — Cowork lief auf dieser Maschine einmal sauber durch, mit dem damals noch windows-service-basierten Architektur-Pfad. Daemon-Log:

07:48:40 [tapvsock] connected to host network, bridge running
07:49:07 [proxy] CA certificate installed to system trust store
07:49:07 [rpc] connecting to host CID=2 port=51234
07:49:07 [rpc] connected successfully
07:49:10 [hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c
07:49:47 [coworkd] connected, waiting for commands

Boot dauerte ~27 s vom tapvsock connected bis rpc connected. Knapp am 60 s-Timeout, aber einmal erfolgreich.

Seit ~1.3883: 0/9 Startversuche erfolgreich. Identisches Fail-Pattern wie @kendall25678:

2026-04-27 08:38:23 [VM:steps] vm_boot completed (119ms)
2026-04-27 08:38:23 [VM:steps] add_plan9_shares completed (6ms)
2026-04-27 08:38:33 [VM:start] Still waiting for guest connection... 10180ms, 21 polls
2026-04-27 08:38:44 [VM:start] Still waiting for guest connection... 20337ms, 41 polls
2026-04-27 08:38:54 [VM:start] Still waiting for guest connection... 30493ms, 61 polls
2026-04-27 08:39:04 [VM:start] Still waiting for guest connection... 40854ms, 81 polls
2026-04-27 08:39:14 [VM:start] Still waiting for guest connection... 51001ms, 101 polls
2026-04-27 08:39:23 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares

Da die Hardware identisch ist und nur die Cowork-Version sich geändert hat, deutet das auf eine Regression im Guest-Boot-Pfad hin (vermutlich neue smol-bin.arm64.vhdx / geänderte sdk-daemon-Startsequenz), nicht primär auf den Snapdragon-Chip — auch wenn das Pattern mit der Chip-SKU korreliert, wie @kendall25678 zeigt.

Datenpunkt 2: Architekturwechsel

Wie schon im Faden erwähnt: 1.3883+ nutzt nicht mehr den Windows-Service CoworkVMService, sondern einen embedded VM-Manager im Electron-Prozess. Wer sich auf C:\ProgramData\Claude\Logs\cowork-service.log stützt, debuggt ins Leere — der reale Log ist:

%LocalAppData%\Packages\Claude_<id>\LocalCache\Roaming\Claude\logs\cowork_vm_node.log

Plus main.log im selben Verzeichnis (zeigt u.a. dutzende vm_guest_connected: false während des Polls).

Datenpunkt 3: Folgefehler "VM is already running" / EBUSY

Nach jedem Timeout bleibt eine Zombie-VM zurück (vmmem ~1 GB RAM, kein Guest), die den nächsten Start blockiert:

[warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
[error] [VM:start] VM boot failed: VM is already running

Erst nach komplettem App-Quit (inkl. Tray) ist der Zustand sauber. Bei dichter Folge von Startversuchen scheitert also nur der erste am eigentlichen Timeout — alle weiteren am EBUSY.

Datenpunkt 4: Cowork läuft trotzdem — via computer-use Fallback

Dieser Punkt fehlt in den bisherigen Berichten und ist meiner Meinung nach relevant: Cowork erscheint dem Nutzer als "funktional", weil bei verfügbarer computer-use-Integration die UI Tasks transparent auf computer-use umleitet, wenn die lokale VM nicht hochkommt. Konkret:

• Cowork-Tab in der UI öffnet wie gewohnt
• Nutzer gibt eine Aufgabe ein ("liste alle Dateien in C:\Users\<user>\Desktop")
• Statt VM-Sandbox wird ein Desktop-File-Explorer-Fenster geöffnet und ausgelesen (sichtbar in der Antwort als "computer-use-Integration verwendet" mit z.B. Verknüpfungen und Statusleisten-Daten, die ein VM-internes ls nicht hätte)

Das ist ein cleverer Fallback und macht das Produkt für Nutzer nutzbar — bleibt aber für Workloads, die die VM brauchen (lange Skripte, abgeschottete Tool-Ausführung, Cowork-Skills mit Linux-Tools), inadäquat. Wäre hilfreich, wenn die UI explizit anzeigte "lokale VM nicht verfügbar, nutze computer-use", statt das Fallback stillschweigend zu machen.

Stack-Status zum Zeitpunkt der Fehlschläge

• HCS Create/Start: ✓
• File ACLs (rootfs/vmlinuz/initrd/smol-bin/sessiondata): ✓
• Virtual network (172.16.10.0/24): ✓
• HVSock Listener Port 1024 + 51234: ✓
• Plan9 share c → C:\: ✓ (6 ms)
• Plan9 share g → G:\ (Google Drive): ✓ (Plan9-g-Fehler aus #44486 nicht mehr reproduzierbar, kann separat geschlossen werden)
• Daemon-Console-NamedPipe-Connect: ✓
• Guest sdk-daemon HVSock-Connect-Back auf Port 51234: ✗

Wie @kendall25678 schreibt: das Console-Pipe-Connect impliziert, dass die VM zumindest VirtioSerial init erreicht. Das sdk-daemon startet danach entweder nicht oder kann die vsock-Verbindung nicht aufbauen.

Was hilfreich wäre

Stimme @kendall25678's Vorschlägen zu, plus:

• Sichtbarmachung des Guest-Konsolen-Outputs im embedded Manager. Aktuell schreibt nichts mehr in den coworkd/user-*.log (das war an den Windows-Service gebunden) — Nutzer und Maintainer debuggen blind nach dem Architekturwechsel.
• Sauberes VM-Cleanup nach Timeout, damit der nächste Versuch nicht mit EBUSY scheitert.
• Explizites UI-Signal, wenn das computer-use-Fallback aktiv wird — sonst denken Nutzer (zu Recht), Cowork läuft, und entdecken erst spät, dass die lokale Sandbox tot ist.
• Höherer Timeout auf ARM64: am 19.04. brauchte mein erfolgreicher Boot 27 s, also gefährlich knapp an 60 s.

Logs (cowork_vm_node.log, main.log, ältere cowork-service.log + coworkd/user-*.log vom 19.04.) auf Anfrage.

Same issue reproduced on ASUS Zenbook A14 (Snapdragon X)

Hardware/OS:

• ASUS Zenbook A14 UX3407QA
• CPU: Snapdragon(R) X - X1-26-100 (Qualcomm Oryon, 8 cores)
• Windows 11 Home, build 26200 (ARM64)
• Claude Desktop 1.7196.0.0 (arm64)

Symptoms matching this issue:

• App shows: "Workspace unavailable. The isolated Linux environment failed to start."
• After commands: "bash failed on resume, create, and re-resume. resume: request timed out after 30s"

Diagnostic confirmation that guest kernel never boots:

cowork_vm_node.log (host side):

[VM:start] vm_boot completed (170ms)
[VM:start] add_plan9_shares completed (4ms)
[VM:start] Still waiting for guest connection... 10149ms / 20389 / 30546 / 40728 / 50926
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: VM connection timeout after 60 seconds

cowork-service.log (host service):

[VM] VM started successfully
[Console] Connected to daemon console pipe: \\.\pipe\cowork-daemon-console-...
(60 seconds of nothing — no sdk-daemon connection, no console output)
[VM] Stopping VM...
[VM] Graceful shutdown failed: HRESULT 0x80070032

coworkd log (inside VM): completely empty for this boot. The previous boot (before nuclear reset) had normal entries, so logging works — the new guest just never reaches userspace.

Bundle is correct ARM64:

• vmlinuz first bytes 4D 5A 40 FA ... 41 52 4D 64 ("ARMd" magic at offset 0x38, confirming ARM64 Linux kernel image format).
• smol-bin.arm64.vhdx copied from app resources (host log: "Copying smol-bin.arm64.vhdx to bundle").

What I tried (none fixed it):

1. Stop-Service CoworkVMService + Start-Service (cleared a zombie VM but new one still fails)
2. Delete sessiondata.vhdx and let it regenerate
3. Nuclear reset: deleted entire vm_bundles\claudevm.bundle\ (12.76 GB), let app re-download fresh rootfs.vhdx.zst / vmlinuz.zst / initrd.zst and decompress — checksums all validated, files all present, guest kernel still doesn't boot.

WSL2 works fine on this machine, so ARM64 Hyper-V is functional — the problem appears to be in the distributed kernel/initrd's compatibility with Snapdragon X virtualization, OR the 60s connection timeout is too short for this hardware.

Happy to provide full logs if useful.

Device: ASUS Zenbook A14 (Snapdragon X)
OS: Windows 11 Home 25H2 (ARM64)
Issue: Workspace always fails with "VM connection timeout after 60 seconds"

WSL2 2.7.3 is installed and working. Ubuntu is installed with a user set up.
HypervisorPlatform is enabled. WSL2 works normally from PowerShell.

But Claude Cowork's Linux sandbox still cannot connect — it just keeps showing
"Workspace still starting" and eventually times out.

File tools (Read/Write/Edit) still work. Only the bash/shell environment fails.

Please fix Snapdragon ARM64 support. This device cannot use any bash features at all.

Adding another data point. Same readiness check issue applies here — the check passes, but Cowork hard-fails.

Environment

• Device: Microsoft Surface Laptop, 7th Edition
• Processor: Snapdragon X 12-core X1E80100 @ 3.40 GHz (ARM64)
• OS: Windows 11 Enterprise, Build 10.0.26100

Error
Rather than a timeout, my failure is a hard crash at the Virtual BIOS layer — the VM never reaches boot:

HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80004001
  ErrorMessage: "Not implemented"
  EventId 12030: 'cowork-vm-39a86248' failed to start. (VM ID: ACCEE0C1-998A-5146-9F28-AB3D0A45A3C9)
  EventId 12010: Microsoft Virtual BIOS failed to Power On with Error 'Not implemented' (0x80004001)
  Attribution: VirtualDeviceFailure → PowerOnCold → Microsoft Virtual BIOS

Root cause signal: 0x80004001 E_NOTIMPL on PowerOnCold at the Virtual BIOS layer indicates the Hyper-V virtualization stack is invoking an x86/x64-specific code path that has no implementation on Snapdragon/ARM64. This is distinct from the timeout errors reported above — the VM isn't stalling, it's hard-failing at BIOS power-on.

Troubleshooting attempted

• Multiple restarts
• Claude Desktop reinstall
• Extended troubleshooting — no change in behavior

Reinforcing the ask in this thread: The Readiness Check showing green on ARM64 devices is actively misleading. 0x80004001 E_NOTIMPL at the Virtual BIOS level is a fundamental incompatibility, not a configuration issue that any amount of troubleshooting can resolve. Users — including non-technical ones — are investing significant time and effort based on false signals from tooling that should be catching this. The fix here is either ARM64 support or an honest gate in the Readiness Check. The Surface Laptop 7th Edition is a first-party Microsoft device with Snapdragon X as its default processor. This is not a niche use case.

I have the same issue.
My laptop is a Lenovo IdeaPad Slim 3 with Windows 11 Business. The processor is a Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) CPU (2.96 GHz)

please fix this

Same issue. Assus Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) CPU (2.96 GHz)

please fix this.. this bug is giving me a huge headache when running Claude cowork or code on my new laptop. (asus zenbook snapdargon, the lightest laptop on the market by the way...weight is the only reason i pick this laptop over a macbook air). This bug is making me regret getting this latpop..feels like superman being close to a piece of kryptonite.

Really love that my Claude chat asks if I've tried using cowork

How do we bump this up their priority list, as someone said you start regretting buy a laptop with snapdragon.

My cowork is sort of working now? I keep getting this error but things are happening...

<img width="2482" height="1586" alt="Image" src="https://github.com/user-attachments/assets/f9e23e1e-1ee8-4387-9948-16656a199e6d" />

I've been getting that for weeks. They need to fix it.

<img width="509" height="380" alt="Image" src="https://github.com/user-attachments/assets/f0a87a97-306d-446e-9255-ad5a1e04b687" />

Explain this to me like i am a 10 years old and a computer noob. I keep seeing ppl saying how great Claude AI and the new model Fable 5 is and yet when aren't they fixing this small bug? i tot we already hit AGI??

How do we bump this up their priority list, as someone said you start regretting buy a laptop with snapdragon.

how do we bump this up???

My cowork is sort of working now? I keep getting this error but things are happening... <img alt="Image" width="2000" height="1278" src="https://private-user-images.githubusercontent.com/268731140/605235987-f9e23e1e-1ee8-4387-9948-16656a199e6d.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODExNDMwMTAsIm5iZiI6MTc4MTE0MjcxMCwicGF0aCI6Ii8yNjg3MzExNDAvNjA1MjM1OTg3LWY5ZTIzZTFlLTFlZTgtNDM4Ny05OTQ4LTE2NjU2YTE5OWU2ZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNjExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDYxMVQwMTUxNTBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lMjRkNDdjNzBjYTdmYWI2NDYzOGY5MWE5ODRlNTNjNWYzOTZmNjlhYWQ1YzIyYTZhNjM4NzMxZDY3NGNlM2YxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.9wOIxrboDMDyUov_bfD5yv-Ey51M5qr_fnZqh_PV9c8">

u cant even ask cowork to "rename ur file" if u try... u can only read.... cowork and code is basically useless on a snapdragon laptop..

Same failure here (Snapdragon X Plus, Windows 11 Pro 25H2 build 26200.8655, Claude Desktop 1.11847.5.0 ARM64 MSIX via the standard installer, bundle c9b42670eaedf20c7035b018c904a0c6a3cb864f). I have guest-side evidence for what the guest is actually doing while the host waits, which I think is the root cause this thread is missing.

Root cause from inside the guest

The guest boots fine and gets all the way through module load and networking, then fails to format its session disk and loops forever. From C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log:

[coworkd] detected Hyper-V host, loading vsock/9p modules
[hyperv] modules loaded successfully
[hyperv] found session disk at /dev/sdc
[coworkd] configuring static IP on tap0: 172.16.10.3/24 gateway=172.16.10.1 dns=172.16.10.1
[coworkd] formatting session disk /dev/sdc with ext4
[coworkd] could not mount session disk: failed to format session disk: exit status 1: mke2fs 1.46.5 (30-Dec-2021)
/dev/sdc: Read-only file system while setting up superblock
[coworkd] starting coworkd
[updater] found smol-bin device: /dev/sdc1

Note the collision: the session disk finder selects /dev/sdc, but the updater finds the smol-bin partition at /dev/sdc1, i.e. the same disk. The smol-bin image is presumably attached read-only by design, which would explain the EROFS exactly. Either the guest is selecting the wrong disk as its session disk, or sessiondata.vhdx is being attached read-only on this hardware.

The guest then self-resets and retries on a ~7-9 minute cycle indefinitely. Hyper-V Worker-Admin events corroborate: successfully booted an operating system followed later by was reset by the guest operating system, repeating. The host side meanwhile shows the familiar sequence ending in Connection timeout, last completed step: add_plan9_shares on virgin boots.

Secondary bug that makes it unrecoverable

After the first timeout the VM is left running. Every subsequent attempt then logs:

[warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
[VM:start] Skipping auto-reinstall (already attempted once)

and the service logs startVM: VM already running, reusing existing session. The service never tears down the wedged VM, so it gets reused forever, and because the dead VM holds smol-bin.vhdx locked, both auto-reinstall and the manual "reinstall the workspace" flow silently fail to replace bundle contents. Only Stop-Service CoworkVMService -Force clears it (after which the next virgin boot fails at the session disk again). I also caught one RPC framing error on the service channel: Persistent RPC: connection ended: message too large: 2065853797 bytes.

Host ruled out

• Cowork readiness check (win32/arm64): pass
• diskpart create vdisk: succeeds, and Mount-DiskImage -Access ReadWrite on a copy of sessiondata.vhdx attaches writable and dismounts cleanly, so the host VHDX stack is healthy end to end
• sessiondata.vhdx in the bundle is a virgin 4 MB dynamic VHDX (10 GB virtual), attributes plain Archive, no ReadOnly bits anywhere in the bundle
• fltmc filters shows stock Microsoft filters only, no third-party AV, Controlled Folder Access off
• SeServiceLogonRight includes *S-1-5-83-0, CoworkVMService running from the correct MSIX path
• Smart App Control is On but the CodeIntegrity 3077 log is empty, so nothing is being blocked
• Full teardown attempted: stop service, delete claudevm.bundle + warm cache, fresh bundle download. Identical guest failure on the first virgin boot.

Regression data point

Unlike the OP's "never worked", Cowork worked briefly on this machine (late April to mid May 2026) and broke around 14-15 May. KB5092762 and KB5087051 installed 15/05/2026, correlation only but the window matches. The failure spans bundle versions (OP's fb30784 in March through c9b42670 in June) and install methods (manual Add-AppxPackage MSIX for the OP, standard installer MSIX here).

Happy to provide full logs, run instrumented builds, or test fixes on this hardware.

we just go tot keep motivating for them to fix it !!

Confirmed working again on Windows 11 ARM64 (Snapdragon X Plus)
Following up on this. As of today the Cowork workspace VM is starting successfully on my machine. The Linux guest now boots and formats its session disk without the earlier mke2fs "Read-only file system" failure on /dev/sdc, and shell commands run normally (uname -m returns aarch64).
I did not change anything on my end, so this looks resolved by an app-side update rather than a local fix.
Happy to share logs if useful for confirming the root cause, but from my side this can be considered fixed. Thanks!!

aagh
Reopening from my side. Earlier today I posted that this was confirmed working again on Windows 11 ARM64 (Snapdragon X Plus). That did not hold. Within the same day the workspace VM is failing to start again, so the fix appears unstable rather than resolved.
Current symptom: the Linux guest no longer boots. Shell commands sit in a "still starting" state through a couple of retries, then fail with VM connection timeout after 60 seconds. I have not made any local changes between the working state this morning and the failure now, which lines up with this being driven by an app-side rollout rather than anything on the machine.
Given it flipped from broken to working to broken again with no input from me, this looks intermittent, likely a race in the session-disk init (consistent with the original mke2fs "Read-only file system" failure on /dev/sdc) or a staged rollout flapping. Happy to grab and share guest boot logs if that helps pin down whether the disk format is failing again or the VM is dying earlier than that.

still waiting fo the bug to be fixed here...this is so totally annoying!!!

<html>
<body>
<!--StartFragment--><p><strong>Still failing on the latest build (1.15200.0.0) after a clean reinstall</strong></p>
<p>Confirming this is not fixed as of the current release. Same <code>VM connection timeout after 60 seconds</code> failure, identical signature to the original report and to <a href="https://github.com/anthropics/claude-code/issues/39161">#39161</a>.</p>
<p><strong>System</strong></p>

Detail | Value
-- | --
Device | Snapdragon X Plus (X1P42100, Qualcomm Oryon)
Architecture | ARM64-based PC
OS | Windows 11 Pro, build 26200
Claude Desktop | 1.15200.0.0 (ARM64 MSIX, installed correctly in WindowsApps)
CoworkVMService | Running
vmms | Running
HypervisorPresent | True

<p>A full clean reinstall did not change the behaviour.</p>
<p><strong>What works, and where it breaks</strong></p>
<p>Everything up to the guest connection completes. The VM boots in about 1 second, Plan9 shares mount, then the guest never connects back to the host across 101 polls before timing out.</p>
<p><code>[VM:steps] vm_boot completed (1051ms)[VM:steps] add_plan9_shares completed (21ms)[VM:start] Still waiting for guest connection... 10153ms elapsed, 21 polls[VM:start] Still waiting for guest connection... 50977ms elapsed, 101 polls[VM:start] Connection timeout, last completed step: add_plan9_shares[VM:start] Startup failed: Error: VM connection timeout after 60 seconds</code></p>
<p><strong>Notes</strong></p>
<ul>
<li>The guest gives zero response across all 101 polls, so this is a hard host-to-guest connection failure on ARM64, not a slow boot. A longer timeout would not help.</li>
<li>The Cowork Readiness Check passes every item, which gives false confidence on hardware that cannot currently run Cowork.</li>
<li>On a second start attempt the vhdx is held: <code>smol-bin.vhdx locked by running VM (EBUSY), skipping copy</code>, so a stale VM process can linger between attempts.</li>
</ul>
<p>Happy to provide the full <code>cowork_vm_node.log</code> if useful.</p>
<!-- notionvc: 820f69d2-9b55-4766-a48e-d16bbfee074d --><!--EndFragment-->
</body>
</html>Still failing on the latest build (1.15200.0.0) after a clean reinstall

Confirming this is not fixed as of the current release. Same VM connection timeout after 60 seconds failure, identical signature to the original report and to #39161.

System

| Detail | Value |
| --- | --- |
| Device | Snapdragon X Plus (X1P42100, Qualcomm Oryon) |
| Architecture | ARM64-based PC |
| OS | Windows 11 Pro, build 26200 |
| Claude Desktop | 1.15200.0.0 (ARM64 MSIX, installed correctly in WindowsApps) |
| CoworkVMService | Running |
| vmms | Running |
| HypervisorPresent | True |

A full clean reinstall did not change the behaviour.

What works, and where it breaks

Everything up to the guest connection completes. The VM boots in about 1 second, Plan9 shares mount, then the guest never connects back to the host across 101 polls before timing out.

[VM:steps] vm_boot completed (1051ms)[VM:steps] add_plan9_shares completed (21ms)[VM:start] Still waiting for guest connection... 10153ms elapsed, 21 polls[VM:start] Still waiting for guest connection... 50977ms elapsed, 101 polls[VM:start] Connection timeout, last completed step: add_plan9_shares[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Notes

• The guest gives zero response across all 101 polls, so this is a hard host-to-guest connection failure on ARM64, not a slow boot. A longer timeout would not help.
• The Cowork Readiness Check passes every item, which gives false confidence on hardware that cannot currently run Cowork.
• On a second start attempt the vhdx is held: smol-bin.vhdx locked by running VM (EBUSY), skipping copy, so a stale VM process can linger between attempts.

Happy to provide the full cowork_vm_node.log if useful.

<img width="548" height="415" alt="Image" src="https://github.com/user-attachments/assets/0881570f-2445-4178-8b0b-3e0958db4b4d" />
another day of unusable claude on my laptop...

<img width="1012" height="546" alt="Image" src="https://github.com/user-attachments/assets/2e03b068-a140-4ace-899a-471d790ee753" />

Update: still failing on 1.15962.0.0

No change on the latest build. Same VM connection timeout after 60 seconds, identical signature, Snapdragon X Plus / Windows 11 build 26200. VM boots and Plan9 shares mount, guest never connects across all 101 polls.

vm_boot completed (1004ms)
add_plan9_shares completed (5ms)
Still waiting for guest connection... 51146ms elapsed, 101 polls
Connection timeout, last completed step: add_plan9_shares
VM connection timeout after 60 seconds

<img width="332" height="95" alt="Image" src="https://github.com/user-attachments/assets/1c0c2461-5fb7-4ef1-85af-1d62c15385f1" />

still not working ..sigh

Update: still failing on 1.15962.1.0

No change. Same VM connection timeout after 60 seconds, identical signature, Snapdragon X Plus / Windows 11 build 26200. VM boots and Plan9 shares mount, guest never connects across all 101 polls.

vm_boot completed (207ms)
add_plan9_shares completed (12ms)
Still waiting for guest connection... 51124ms elapsed, 101 polls
Connection timeout, last completed step: add_plan9_shares
VM connection timeout after 60 seconds

its actually crazy that this has not been fixed!

<img width="424" height="71" alt="Image" src="https://github.com/user-attachments/assets/fea7174f-661c-4b4c-8467-92217c5f3256" />
i am noob at computing and stuff and is totally new to github and shit too...i posted here initially is bcos claude recoomended me to do it and ...how can we get their attention?? i have been trying myself to spam on this thread but seems like nothing is happening....

Another X1P42100 data point — confirmed stalled-boot type (idle VM, zero disk writes)

Same signature as this thread on Snapdragon X Plus X1P42100, Windows 11 Pro build 26200, Claude Desktop 1.15962.1.0 (ARM64 MSIX). Host side completes cleanly through add_plan9_shares, then 60s guest-connection timeout, echo hello never runs.
Following the slow-vs-stalled diagnostic from #39636, I measured whether the guest is alive after the UI gives up:

After the timeout, the VM stays powered on: vmmem present at ~718 MB, vmwp running.
But the guest is doing nothing: rootfs.vhdx LastWriteTime frozen and Length unchanged over 10+ minutes of soak; vmmem RAM flat at ~718 MB (no climb).

Zero disk writes + idle memory puts this in the stalled-boot category (like @ivangc1's Surface), not the slow-but-alive Vivobook case — even though I'm on the same X1P42100 as @vsaintloup's Vivobook, which does eventually connect. So same chip SKU, opposite outcome, which reinforces that the differentiator isn't the SKU alone.
Ruled out on my side: NAT collision (host on 192.168.0.x), stale VHDX lock (cleared, confirmed smol-bin copy succeeds), CoworkVMService state (RUNNING), fresh service restart. smol-bin.arm64.vhdx copied successfully, vm_boot and add_plan9_shares both complete, guest never connects.
A guest serial console (earlycon/earlyprintk) would separate stalled from slow here, as others have requested.

  [stack]: [Getter/Setter],
  [message]: 'VM connection timeout after 60 seconds'
}
2026-07-01 22:27:41 [info] [VM:start] Skipping auto-reinstall (already attempted once)
2026-07-01 22:28:00 [info] [KernelBugMonitor] State reset
2026-07-01 22:28:00 [info] [VM:start] Beginning startup, bundlePath=C:\Users\katar\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-07-01 22:28:00 [info] [VM:start] Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
2026-07-01 22:28:00 [info] [VM:start] VM instance ID: cfe65be8-e78b-46d8-a8b6-615a973204d5
2026-07-01 22:28:00 [info] [VM:steps] download_and_sdk_prepare started
2026-07-01 22:28:00 [info] [VM:steps] download_and_sdk_prepare completed (16ms)
2026-07-01 22:28:00 [info] [VM:steps] load_swift_api started
2026-07-01 22:28:00 [info] [VM:steps] load_swift_api completed (0ms)
2026-07-01 22:28:00 [info] [VM:start] Copying smol-bin.arm64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.15962.1.0_arm64__pzs8sxrjxfjjc\app\resources\smol-bin.arm64.vhdx -> C:\Users\katar\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-07-01 22:28:00 [warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
2026-07-01 22:28:00 [info] [VM:start] Configuring Windows VM service...
2026-07-01 22:28:00 [info] [VM:start] Windows VM service configured
2026-07-01 22:28:10 [info] [VM:start] Still waiting for guest connection... 10135ms elapsed, 21 polls
2026-07-01 22:28:20 [info] [VM:start] Still waiting for guest connection... 20253ms elapsed, 41 polls
2026-07-01 22:28:30 [info] [VM:start] Still waiting for guest connection... 30384ms elapsed, 61 polls
2026-07-01 22:28:40 [info] [VM:start] Still waiting for guest connection... 40518ms elapsed, 81 polls
2026-07-01 22:28:50 [info] [VM:start] Still waiting for guest connection... 50652ms elapsed, 101 polls
2026-07-01 22:28:57 [info] [startVM] VM startup already in progress, waiting...
2026-07-01 22:29:00 [error] [VM:start] Connection timeout, last completed step: load_swift_api
2026-07-01 22:29:00 [info] Dispatching startup error: VM connection timeout after 60 seconds
2026-07-01 22:29:00 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
    at vzr (C:\Program Files\WindowsApps\Claude_1.15962.1.0_arm64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1407:5919) {
  [stack]: [Getter/Setter],
  [message]: 'VM connection timeout after 60 seconds'
}
2026-07-01 22:29:00 [info] [VM:start] Skipping auto-reinstall (already attempted once)

Progress on 1.17377.2.0: guest now connects, but a new post-connect blocker appears

Different behaviour on this build (Snapdragon X Plus / Windows 11 build 26200). The original "guest never connects" wall is no longer absolute.

Cold-start attempts still hit the 60s guest-connection timeout (three in a row here), but on a later retry the guest actually connected for the first time:

[startVM] VM already connected
[postConnect] Installing SDK ... claude-code-vm version=2.1.197
[VM] API reachability: REACHABLE
[vmOneShot] Running: bash ... (commands running inside the guest)

So the guest connection is now intermittent rather than a hard failure. However, a new later-stage blocker then stops it from finishing:

[postConnect] Post-connect setup failed on already-connected fast path: Error: request timed out after 30s

After that it loops between VM already connected / Installing SDK / vmOneShot Running: bash and never completes startup, so the UI still shows VM connection timeout after 60 seconds.

Net: real movement on ARM64. The remaining issues on this hardware are (1) flaky/slow initial guest connection and (2) the post-connect SDK install timing out after 30s.

Lets all hit that share your debug logs and hopefully that will speed things up

<img width="729" height="163" alt="Image" src="https://github.com/user-attachments/assets/bcf89ab0-ddaf-4dcb-9596-8f4060ab69df" />

Lets all hit that share your debug logs and hopefully that will speed things up <img alt="Image" width="729" height="163" src="https://private-user-images.githubusercontent.com/290664299/616100289-bcf89ab0-ddaf-4dcb-9596-8f4060ab69df.jpg?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI5NzE0MzcsIm5iZiI6MTc4Mjk3MTEzNywicGF0aCI6Ii8yOTA2NjQyOTkvNjE2MTAwMjg5LWJjZjg5YWIwLWRkYWYtNGRjYi05NTk2LThmNDA2MGFiNjlkZi5qcGc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNzAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDcwMlQwNTQ1MzdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT01MTIzMmU2MjA0YWEzZmM4OGNkZDIwM2I3OGNhNTJhYzJhNDk2ZGM3NjdkYzRiNTVmMTNiZmRiYTM4NDJkMDhiJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZqcGVnIn0.t6kUXmuILDuJCL0lBvunYSO1se8rZGW2_TjqUq9jhYE">

have done it multiple times over this 2 months...:(

Same failure here on another Snapdragon / Windows-on-ARM machine — confirming the readiness check gives a false green.

Environment

• Device: Snapdragon (ARM64) laptop
• OS: Windows 11 Home, build 26200 (ARM64)
• RAM: 16 GB
• Claude Desktop: 1.18286.0.0 (arm64)
• WSL2: 2.7.10.0 with Ubuntu — confirmed working (so core virtualization is fine)
• HypervisorPresent: True

-
[VM:steps] vm_boot completed
[VM:steps] add_plan9_shares completed
[VM:start] Still waiting for guest connection... 10000ms elapsed
[VM:start] Still waiting for guest connection... 20000ms elapsed
...
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
[error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
[VM:start] Skipping auto-reinstall (already attempted once)
Symptom
The VM bundle downloads, decompresses, and boots, but the guest never connects. Identical every attempt:

Things tried — none changed the failure at all (byte-for-byte identical each time):

• Full uninstall + reinstall of Claude Desktop
• Enabled Windows Hypervisor Platform optional feature (was disabled) → no change
• Confirmed Virtual Machine Platform enabled, vmcompute / HvHost / hns services all Running
• Disabled Memory Integrity / Core Isolation (HVCI) and rebooted → no change (note: VBS itself stayed on because System Guard "Secure Launch" is still active)
• Multiple reboots

No hypervisor/Hyper-V error is logged in the Windows System event log when the VM start is attempted — the guest simply never establishes its connection after add_plan9_shares.

The readiness checker reports all-green on this machine, so from a user's perspective there's no signal that ARM64 isn't going to work. Either fixing ARM64 guest bring-up or having the readiness check flag ARM64 as unsupported would help.

I went down a long rabbit hole with this, I think I've identified the issue:

Title: Cowork VM guest connection timeout on Windows 11 ARM64 — NAT network (172.16.0.x vEthernet) never created
Environment: Windows 11 ARM64 (Snapdragon) · Claude Desktop 1.20186.0.0 arm64 (Store/MSIX) · VirtualMachinePlatform: Enabled · HypervisorPlatform: Enabled · hypervisorlaunchtype: Auto · systeminfo confirms hypervisor detected · CoworkVMService: Running/Automatic · hns: Running · SharedAccess: Running
Symptom: Every Cowork session fails with "VM connection timeout after 60 seconds," last completed step add_plan9_shares. Bundle staging succeeds (rootfs.vhdx/vmlinuz/initrd checksums validated).
Key findings, in order discovered:

With Memory Integrity (HVCI) enabled, the VM never executes at all — no Vmmem process appears. Disabling Memory Integrity allows the VM to start (Vmmem appears). → HVCI conflict with Cowork's VM on ARM64.
With HVCI disabled, the VM boots but the guest connection still times out.
Root cause observed: Cowork's NAT vEthernet adapter is never created. ipconfig shows only "vEthernet (Default Switch)" — no 172.16.0.x adapter exists during startup attempts, so the guest has no channel back to the host.
Earlier in the same debugging session, two other failure modes were hit and cleared: stale VM holding smol-bin.vhdx (EBUSY), and CoworkVMService failing to start (connect ENOENT \\.\pipe\cowork-vm-service).

Already ruled out: process kills, service restarts, proper OS restarts, fresh bundle re-stage, app update 1.19367→1.20186, HNS restart [confirm after trying]. Auto-reinstall attempted once by the app.
Ask: Why does the VM service fail to create its NAT network on this configuration, and can the HVCI incompatibility on ARM64 be addressed?

Regression on 1.21459.1.0: guest connection broken again (was working on 1.20186.1.0)

Snapdragon X Plus / Windows 11 build 26200. This is a backslide, verified from a clean cold start.

On 1.20186.1.0 the guest connected reliably. startVM: VM already connected every time, API reachability: REACHABLE. The only blocker was the post-connect SDK install timing out after 30s.

On 1.21459.1.0 the guest never connects at all. Back to the original 60s timeout, 101 polls with zero response:

[VM:start] smol-bin.arm64.vhdx copied successfully
[VM:steps] vm_boot completed (851ms)
[VM:steps] add_plan9_shares completed (908ms)
[VM:start] Still waiting for guest connection... 51605ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

This run was clean, to rule out local/stale state:

• Stale VM torn down first (vmwp/vmmem confirmed gone), so this was a true cold start
• Fresh VM image copied successfully, no EBUSY ... skipping copy this time
• CoworkVMService confirmed running
• Windows Defender exclusions applied to both Claude\vm_bundles and the Claude_pzs8sxrjxfjjc package cache, to rule out AV latency
• App fully quit from the tray and relaunched

So the post-connect SDK timeout previously reported is now moot on this build, because startup no longer gets that far. Whatever changed between 1.20186.1.0 and 1.21459.1.0 reintroduced the guest connection failure on ARM64.