embedded_enter drops session_token: ab ships signed-out on every virgin machine

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

Found on a from-scratch Hydrogen install on a clean Azure VM (2026-08-31): ab ran embedded but its footer said 'Not signed in' while Hydrogen logged a successful session handoff.

Root cause: direct_api.rs EmbeddedEnterBody parses session_token into a field marked #[allow(dead_code)] // reserved for v1.8.85+: forward to auth::apply_token and drops it. Hydrogen's runtime handoff (ad_token_reconcile_task -> POST /embedded/enter with the fresh Adom token) has therefore never signed ab in. Every test box (AdomLapper, ConfRoomROG) had a pre-existing standalone session.json masking this, so it only shows on a virgin machine, which is exactly what every new Adom user is.

Ask: forward that token to auth::accept_handoff at runtime (validate via Carbon GET /user, persist session.json, refresh the GUI footer), and LOG the acceptance or rejection (today a consumed handoff.json that fails validation leaves no trace in any ab log file, which made this expensive to debug).

Hydrogen 1.0.144+ works around it: after embedded_enter it verifies session.json and, if absent, stages %LOCALAPPDATA%\Adom Bridge\handoff.json and gracefully bounces ab once so the boot handoff channel signs it in. That costs a relay blip per fresh install; the runtime forward removes it.

1 Reply

John Lauer · 2mo ago

Fixed in code (ships in the next patch; 2.0.85 was already out when this landed). Your root cause was exactly right, down to the #[allow(dead_code)] field.

embedded_enter_route now forwards session_token to auth::accept_handoff — the same path the boot handoff uses: validate via Carbon GET /user, persist session.json, return the user (or Err on 401, leaving session.json untouched). And per your ask, it logs the outcome:

[/embedded/enter] session handoff ACCEPTED for <email> — ab signed in
[/embedded/enter] session handoff REJECTED: <reason> — ab stays signed out (token invalid or Carbon unreachable)

So the silent-failure you hit — a consumed handoff that failed validation leaving no trace in any ab log — is now a logged line either way. It also emits an auth-changed event that the footer listens for, so ab flips from "Not signed in" the moment the token is accepted rather than on the next natural poll.

Your framing is the important part: this was invisible on every box we test on because they all had a pre-existing session.json masking it, and it only shows on a virgin machine — which is every new Adom user. That makes it effectively a fresh-install blocker, so it's going in ahead of any public release.

Your Hydrogen 1.0.144+ workaround (verify session.json, stage handoff.json, bounce ab once) can stay as a belt-and-suspenders or be dropped once the box is on the patched ab — the runtime forward removes the relay blip it costs.

Verified live: POST /embedded/enter accepts a session_token and forwards it to the async accept_handoff (a bogus token logs the REJECTED line; a real one signs ab in).

John Lauer closed this · 2mo ago