app

Hydrogen Desktop

Public Made by Adom

by adom

The full Adom Hydrogen workspace as a native Windows app — AI-driven electronics design, running locally.

Overview Files Skills Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests Activity
Open general

v0.1.95: opening Codex sidebar locked up VSCode UI — required laptop reboot to recover

Drew Owens · 20d ago

Version: HD v0.1.95

Repro: Opening the Codex sidebar caused the VSCode UI to lock up. It wasn't a total HD freeze — I could still resize the Wiki webview — but VSCode itself became unresponsive and left a black empty region in the VSCode area.

Severity — escalated: I could not recover in-app:

  • Refreshing HD did not fix it.
  • Closing HD left it unable to reopen.
  • I ultimately had to reboot my laptop to recover.

After reboot: HD opened automatically and the Codex panel was running fine. I can now open/close Codex without issue — so the lock-up is not consistently reproducible, but the fact that it required a full OS reboot (HD couldn't relaunch) is the serious part.

Ask: Investigate the Codex-sidebar lock-up path and, separately, why HD couldn't be reopened after being closed in that state (a stuck process / lock file should not block relaunch).

1 Reply

Drew Owens · 20d ago

Log diagnostics (pulled from the host by Claude via adom-desktop).

Files on disk:

  • HD: %APPDATA%\hydrogen-desktop\hydrogen-desktop.log (159 KB, sha256 524430e8…)
  • AD: %LOCALAPPDATA%\inc.adom.desktop\logs\Adom Desktop.log (sha256 3597b75c…)

Environment: HD v0.1.95, build ec8551c5ed2353c5408435d44ebc6d3b3c85ef01-dirty (built Jun 29 5:57 PM), tao 0.35.2. Frozen session started 2026-06-30 16:42:52.

Smoking gun — panic on exit (tao event-loop teardown):

16:49:03.889 [heartbeat] alive 370s
16:49:13.890 [heartbeat] alive 380s
16:49:18.132 [focus] hd Focused(false)
16:49:18.207 [focus] sync toolbar on_top=false ...
16:49:21.502 [app] Exiting
16:49:21 [PANIC] panicked at C:\Users\john\.cargo\registry\src\index.crates.io-...\tao-0.35.2\src\platform_impl\windows\event_loop\runner.rs:371:25:
cannot move state from Destroyed

What the logs tell us:

  1. The Rust main loop never died — [heartbeat] alive ticks continued right up to exit (…360s → 370s → 380s). So the lock-up was a UI/webview-thread freeze, not a process hang. This matches the report: the Wiki webview stayed resizable while the VSCode/Codex area went black and unresponsive.
  2. The crash is on teardown. [app] Exiting is immediately followed by the tao panic cannot move state from Destroyed (runner.rs:371) — a known tao Windows event-loop teardown race. A panic while destroying the window/event loop is a very plausible reason HD couldn't be relaunched afterward (leftover window state / zombie process) and needed a full reboot to clear.
  3. Logging gap: the string codex appears 0 times in the entire HD log. The Codex-sidebar open (the reported trigger) is not logged, so we can't correlate the trigger to the freeze from logs alone. Worth adding instrumentation around sidebar/panel open + webview health so the next occurrence is diagnosable.

After the reboot, HD restarted cleanly at 2026-07-01 06:39:17 (same build), consistent with "it works fine now."

Full logs available on request (they're mostly [focus]/[heartbeat] noise outside the excerpt above).

Log in to reply.