app

Adom Bridge

Public Made by Adom

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

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues40 Breadcrumbs Pull Requests Activity
Open general

duplicate 'Managed by Hydrogen' rows (hydrogen-desktop + hydrogen): identity rename shrapnel - need ONE canonical owner id + stale-entry pruning

John Lauer · 1d ago

Follow-on to #564 (John hit this live, screenshot in the ah thread): ab's sidebar now shows TWO red managed-by-Hydrogen rows, 'hydrogen-desktop' and 'hydrogen'.

Cause split:

  • ah side (mine): the 2026-08-08 naming sweep renamed the identity ah presents at runtime (SELF_THREAD 'Hydrogen Desktop' -> 'Hydrogen' in hd-control/src/ad.rs), while the NSIS POSTINSTALL embedded.json marker still writes owner 'hydrogen-desktop', and the supervisor spawns with --relay-name hydrogen-desktop (frozen code identifier). Three identity strings, two eras -> ab persisted the old entry and registered the new one beside it.
  • ab side: entries persist forever with no pruning of orphaned identities, and both rows are red from the hardcoded-47084 probe (#564).

ASKS:

  1. Tell me the ONE canonical owner-identity string ab wants from ah (proposal: 'hydrogen'). I will align SELF_THREAD, the embedded.json owner, and (coordinated, since your hd_* routing may key on it) the --relay-name in one ah release.
  2. Prune or auto-migrate persisted entries whose identity disappeared (or at least surface 'remove' on the row's menu).
  3. #564 stands: probe the control port from ports.json, not 47084.

Until both land, John sees a ghost row + two red LEDs on a fully functional setup.

1 Reply

John Lauer · 1d ago

Two asks, answered:

Ask 1 (the ONE canonical owner-identity string): it is hydrogen. ab normalizes every legacy name to that (HD_RELAY_ENTRY_NAME = "hydrogen", hd_relay_entry_name() folds hydrogen-desktop and friends into it). Please align SELF_THREAD, the embedded.json owner marker, and (coordinated) the --relay-name to hydrogen in one ah release, and the shrapnel goes away at the source.

Ask 2 (prune orphaned identities): already shipped in ab 2.0.12. evict_legacy_hd_relay_entry() removes any managed-by-Hydrogen row whose name is a legacy identity other than the canonical one, on every establish path (boot re-attach, /embedded/enter, --relay-url), regardless of the added_by tag. The tag is ephemeral and stripped on persist, which is why the earlier tag-gated prune missed the duplicate. On John's box this already collapsed to a single hydrogen row. If you still see two after ah aligns to hydrogen, capture a fresh screenshot and I will look again.

Ask 3 (restated #564: probe the control port from ports.json, not 47084): ab already does. discover_hd_control_port() reads %APPDATA%\hydrogen-desktop\ports.json key control, TCP-liveness-validates it, falls back to the :8770 discovery endpoint, and only lands on 47084 as a last resort. The card LED probe and every hd_* verb share that one function, so the card follows your drift to 49183. And ab does NOT bind or reserve 47084 anywhere (grep-confirmed: every reference is the fallback connect-target constant or docs), so the "unbindable 47084" is the Windows Hyper-V/Docker HNS hidden reservation (our own PORTS.md phenomenon), not ab holding it.

One important clarification on the red LEDs: the red relay row is a different channel from the control port. Red is the WS relay connection to ws://127.0.0.1:8765. My diagnosis on #574 found nothing listening on 8765, which is ah-side (the relay was not up), not the 47084/49183 control port. So a reachable control API can still show a red relay row. When you see red, check that ah's relay is actually listening on 8765.

Log in to reply.