Adom Bridge
Public Made by Adomby adom
Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl
2.0.91 exits at launch: PANIC carbon_runtime.rs:113 'there is no reactor running' (every auto-upgraded box loses ab)
Severity: every box that auto-upgraded to 2.0.91 has no Adom Bridge at all. Confirmed on the Azure winvm (fresh 1.0.147 Hydrogen, Windows 11, WebView2 151.0.4129.107) and matching symptoms on ConfRoomROG.
Repro (plain launch, user session):
C:\Users\azureuser\AppData\Local\Adom Bridge\adom-bridge.exe (ProductVersion 2.0.91, uninstall.exe stamped 2.0.91 at 23:57)
Exits within a few seconds. stderr:
[2026-09-01 00:13:24] PANIC: panicked at src\carbon_runtime.rs:113:5:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
[0901/001324.561:ERROR:ui\gfx\win\window_impl.cc:172] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
stdout's last line before the panic: [app_lib::notifications][INFO] Boot: swept stale approval toasts from a prior instance. No Windows Application-log crash event (it is a clean process exit after the panic), no ab log written.
How it spread: Hydrogen's ad-install resolved latest ab = 2.0.91 via version.json (released_at 2026-08-31T17:45:00Z), saw installed ab 2.0.90 < published 2.0.91 -> upgrading, installed it (exit 0), and from then on the ad-supervisor loop is: health probe fails 3x, spawned AB detached pid N, dies, repeat every ~47s. The box drops off the relay (winvm vanished from adom-bridge targets; ConfRoomROG too), and in Hydrogen the taskbar jump-list task and the Adom menu item "Adom Bridge" appear to do nothing, because both are a window_show_intent request to an ab that is not running. 2.0.90 and 2.0.89 launch fine (the laptop on 2.0.89 is unaffected).
Ask: publish a fixed 2.0.92 (something in the 2.0.91 boot path calls into carbon_runtime from outside the Tokio runtime). Hydrogen pulls latest automatically on its respawn loop, so every affected box heals itself within a minute of the publish, no user action needed. Until then, a manual downgrade to 2.0.90 is undone by Hydrogen within a minute, so please do not advise users to downgrade.