Runtime handoff sign-in does not trigger the cloud server sync: relay list stays empty until the user clicks Refresh

by 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

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

ab 2.0.86 on a virgin Azure VM (2026-08-31), Hydrogen 1.0.144 fresh install. The #104 fix works: ab accepted Hydrogen's session handoff at runtime and the footer showed [email protected]. But the Servers list stayed at 1/1 (only Hydrogen's local relay) even though the user's cloud profile lists the galliaApril relay. Nothing happened until John clicked the Refresh button, which logged 'Refreshed connections: 2 cloud server(s) synced, relays re-dialed' and then CONNECTING/CONNECTED/AUTH to wss://john-galliaapril-...adom.cloud/proxy/8765/.

So the boot path (restore_on_boot -> cloud sync -> connect) runs the sync, but the runtime handoff path (accept_handoff) does not. Ask: after a runtime handoff is accepted, run the same server_sync + connect the boot path runs, so a freshly installed machine becomes a --target for the user's cloud AI without a manual click. Until then every virgin install needs a human to press Refresh before the cloud can reach it.

1 Reply

John Lauer · 2mo ago

Fixed in code (ships in the next patch). Your diagnosis is exactly right, and it's the missing half of the #104 fix.

The #104 fix made accept_handoff sign ab in and persist session.json, but it stopped there. The boot path does more after auth: restore_on_boot -> cloud-server sync -> immediate connect. The runtime handoff path skipped the sync, so a freshly-signed-in virgin box sat at "1/1 (Hydrogen only)" and the user's galliaApril relay never came up - which is why a cloud AI couldn't --target it until someone pressed Refresh.

embedded_enter_route now, right after a successful handoff, calls the same sync_cloud_servers_now the boot path and the Refresh button use. It pulls the user's cloud servers, merges, saves, and ends with connect_enabled_now (immediate connect, not the 30s supervisor). So the log you'd see on a virgin box goes from:

[/embedded/enter] session handoff ACCEPTED for [email protected] — ab signed in

to that plus:

[/embedded/enter] post-handoff cloud sync: 1 server(s) merged + connect kicked
... CONNECTING/CONNECTED/AUTH to wss://john-galliaapril-...adom.cloud/proxy/8765/

with no Refresh click. That closes the loop your #104 report opened: a virgin install signs in AND becomes reachable as a --target hands-off.

Nice catch running this on an actual virgin Azure VM - that's the exact box class where both this and #104 were invisible on our dev machines.

John Lauer closed this · 2mo ago