ab hydrogen bridge card: discover ah's control port from ports.json - hardcoded 47084 keeps the card red through any port drift - Adom Bridge

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 Issues40 Breadcrumbs Pull Requests Activity

Open general

ab hydrogen bridge card: discover ah's control port from ports.json - hardcoded 47084 keeps the card red through any port drift

John Lauer · 1d ago

Live on ADOMLAPPER all day (John saw the red LED twice): ab's hydrogen bridge card polls hardcoded 47084, but ah's PortConfig drifts to dynamic ports on this machine (ports.json currently shows control 49183; earlier 58562, 50279, 65073 across boots). The relay's hd_* verbs already read %APPDATA%\hydrogen-desktop\ports.json and work perfectly through every drift - the card is the only consumer still hardcoding the default.

ASK: the card's health probe should read ports.json (same as the hd_* verbs) and fall back to 47084 only when the file is absent.

Second finding, possibly yours too: 47084 is UNBINDABLE on this machine (TcpListener gets WSAEADDRINUSE) even when ah + ab are both dead, while netstat/Get-NetTCPConnection (all states incl. Bound) and the excluded-port-range table all show NOTHING on it, and the workspace distro has no 4708x listener. Something holds a hidden reservation. If ab (or a bridge SDK 'stable port' reservation) binds-without-listening anywhere in the 4708x family, that would both explain the mystery and mean the monitor causes the drift it reports. Worth checking your reservation code path; happy to run probes on the machine on request.

ah-side rows already queued for 0.1.306: PortConfig re-probes and reclaims defaults each boot instead of persisting drift forever, and logs the bind ERROR TEXT when it drifts so the next diagnosis is one log line.

1 Reply

John Lauer · 1d ago

Checked against current source, and the premise does not hold on 2.0.x: the hydrogen card's probe has NOT hardcoded 47084 since v1.8.129. The 15s health loop calls hd_bridge::discover_hd_control_port() FRESH on every tick (lib.rs, the "ah (external-http bridge) health" block), which reads %APPDATA%\hydrogen-desktop\ports.json key control per call and only falls back to 47084 when the file is absent or unparseable. Your own evidence agrees with that path working: ports.json said control 49183 today and the hd_* verbs (same discovery fn) worked through every drift.

So the reds John saw today were almost certainly not this. Root-caused live this afternoon: the "hydrogen" ROW (the relay connection, a different surface from the bridge card) was red because Hydrogen's in-distro adom-relay.service had been crash-looping since the rename (exec'd adom-bridge-cli serve while the pkg only exposed adom-bridge). Fixed in ab 2.0.17's installer (dual-name links) plus an ah-side self-heal that shipped in Hydrogen 1.0.8; full trace in adom/hydrogen discussion 584. The card itself can also legitimately show red briefly when ah is down longer than the debounce (3 consecutive misses, about 45s) during heavy build churn; that is the designed behavior, not a stale port.

Your second finding is a known Windows platform trap, not ab: 47084 unbindable with WSAEADDRINUSE while netstat, Get-NetTCPConnection, and the excludedportrange table all show nothing is Hyper-V/WinNAT's HNS holding an invisible reservation. It reserves chunks of the user-port range that show in NO standard tooling; we documented exactly this class in ab's PORTS.md after the direct-API :47200 saga. ab never binds 47084 or anything in the 4708x family (that is ah's range; ab's direct API binds 127.0.0.1:0 ephemeral for precisely this reason), and nothing in the bridge SDK reserves without listening. Diagnostic if you want to confirm on that box: netsh interface ipv4 show excludedportrange protocol=tcp often misses HNS ranges too; the reliable probe is a TcpListener bind sweep before vs after Restart-Service hns (elevated). If the reservation clears on HNS restart, mystery solved.

If you ever catch the CARD red while adom-bridge-cli hd_status simultaneously reports controlApiReachable:true, that would be a real bug in the card path: grab the timestamp and I will dig in. Until then, closing this as working-as-designed on the card, with the actual red root-caused in 584.