Adom Hydrogen
Public Made by Adomby adom
The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.
After self-update, two adom-vscode extension hosts answer /health; the selector flaps and the /exec fallback reports the wrong port
Following the 1.0.431 self-update, Hydrogen logs this every ~35 seconds, indefinitely:
[adom-vscode] 2 hosts answer /health ([8821, 8822]); using the newest, port 8821
Observed continuously from 13:51 to at least 14:15 on 2026-09-17. Related to #85 (same update), but independent of it.
Why there are two hosts
On launch Hydrogen deliberately leaves the existing code-server alone:
13:51:05.341 [wsl] code-server already active + answering, leaving it alone (no restart, no editor reload)
13:51:05.341 [wsl] code-server managed by systemd, no HD-held child
That is reasonable on its own, but it means the pre-update extension host survives while the new build brings up its own. Both answer /health, and the selector disambiguates with "use the newest" — a heuristic, not an identity check.
The selector flaps
Nothing actually moved; the selector just keeps changing its mind:
13:51:06 [ai-tabs] mirror connected to adom-vscode /tabs/events on port 8822
13:51:24 [ai-tabs] mirror connected to adom-vscode /tabs/events on port 8822
13:51:40 [adom-vscode] 2 hosts answer /health ([8821, 8822]); using the newest, port 8821
13:51:40 [ai-tabs] mirror: the extension moved off port 8822; reconnecting
13:51:43 [ai-tabs] mirror connected to adom-vscode /tabs/events on port 8821
13:51:43 [wake-heal] reload: editor reloaded: the adom-vscode extension host restarted (attached again on port 8821)
"The extension moved off port 8822" and "the extension host restarted" are both misreadings of the situation — both hosts were up the whole time.
The reporting bug
The announced port and the dialed URL disagree:
13:51:08.640 [exec] :8821 /exec unusable (adom-vscode /exec transport:
error sending request for url (http://127.0.0.1:8822/exec)), falling back to wsl.exe
13:51:09.656 [exec] :8821 /exec unusable (… url (http://127.0.0.1:8822/exec)), falling back to wsl.exe
It reports :8821 as unusable while the HTTP client's own error names http://127.0.0.1:8822/exec. Two possible readings, and the log alone cannot distinguish them:
- Cosmetic: the message is formatted from the selected port while the request used a candidate port. The log then misattributes every failure, which is what made this take a while to unpick.
- Functional: the request targeted the wrong host and a healthy one got marked dead. Hydrogen then degrades to the slower
wsl.exepath unnecessarily.
Either way the identity cross-check gives up:
13:51:11.610 [wsl-startup] :8821 not answering: iframe likely stale, reloading to reconnect
13:51:11.940 [wsl-startup] distro-identity cross-check skipped (:8821 /exec unavailable — ext <1.0.16 or editor not up yet)
Note the suggested causes in that last line ("ext <1.0.16 or editor not up yet") are both wrong here — the editor was up and answering.
Suggested fixes
- Log the port actually dialed, taken from the same value used to build the URL.
- Select the host by identity (instance id, build stamp, or the existing distro-identity value) rather than by "newest", so a stale host can be recognised and retired instead of competed with.
- When a self-update leaves a previous extension host alive, shut it down or hand off explicitly rather than leaving both to race. If keeping both is intentional, the health line should say which one belongs to the current build instead of reporting a tie every 35 seconds.
Environment
- Hydrogen 1.0.431, insiders tier, build
efa297192b87a81f251d488fd5363289c4c5e52b-dirty - Windows 10.0.26200.9457
- WSL 2.7.11.0,
networkingMode=mirrored,hostAddressLoopback=true - code_server 7380, proxy 47083, control 47084, cdp 47085 (reclaimed from drift at 63478/63479/63480 on this launch)