app

Adom Hydrogen

Public Made by Adom

by 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.

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity
Closed bug report

ad_supervisor STALE AB RECLAIM kills the Adom Bridge CLI (any adom-bridge.exe not at the installed path) every poll tick, silently

John Lauer · 1mo ago ·closed by John Lauer

Hydrogen's ad_supervisor::check_ad_version_drift ("STALE AB RECLAIM") kills every running adom-bridge.exe whose path is not the installed GUI exe, on each health-poll tick. It cannot tell the Adom Bridge CLI from a stale GUI copy: the CLI crate's cargo bin is named adom-bridge, so any CLI run from a build tree (or any copy not at %LOCALAPPDATA%\Adom Bridge\adom-bridge.exe) is killed within a poll interval, silently, with exit code 1. Measured on AdomLapper (Hydrogen current, ab 2.1.137/138), 2026-09-20:

16:29:02 [ad-supervisor] STALE AB RECLAIM: killing shadow adom-bridge.exe pid=32328 ('C:\Github\adom-bridge\cli\target\release\adom-bridge.exe' v): it is NOT the installed exe ('C:\Users\john\AppData\Local\Adom Bridge\adom-bridge.exe' v2.1.137) and is holding ports ...
16:30:03 ... pid=45648 ...   16:31:04 ... pid=41068 ...   16:32:05 ... pid=29904 ...
16:34:07 ... pid=66116 ...   16:35:08 ... pid=4528 ...    17:11:55 ... pid=64704 ...   17:15:57 ... pid=57624 ...

Each of those pids was a CLI invocation (send_files --target arav-rog streaming a 49 MB build over the mesh, then a plain shell_execute that waits 70 s); each died mid-call with no output. A byte-identical copy of the CLI renamed ab-test-cli.exe ran the same 70 s call to completion, which isolates the image-name match as the trigger. The reclaim message also says the process "is holding ports"; no port check is made (the CLI holds none), and the doc comment above the function still says it "NEVER kills anything", which is no longer true.

Who is affected: any developer or script running the Windows CLI from a build tree on a Hydrogen box (installed users get adom-bridge-cli.exe from the installer, which never matches). ab's tracking issue: adom/adom-bridge#208.

Suggested fix, any one of:

  1. Only reclaim a process that actually HOLDS an ab port (relay 47081/47082 or the direct API 24680..24689): Get-NetTCPConnection -OwningProcess $pid -State Listen. That is the stated reason for the kill, so make it the test.
  2. Skip console-subsystem executables (the CLI is one; the GUI is not): the PE optional header's Subsystem field, or $_.MainWindowHandle/SessionId are cheap proxies.
  3. Match the GUI by ProductName / FileDescription from the version resource ("Adom Bridge") rather than by image name; the CLI's resource is empty (the log prints v with no version).

Until then, a warning: the current check turns "run the CLI from your checkout on a Hydrogen box" into a silent kill every ~60 s.

1 Reply

John Lauer · 9d ago

Fixed in Hydrogen 1.0.533 (Sept 30); closing it now, late.

STALE AB RECLAIM now kills only an adom-bridge.exe that is not the installed exe and is listening on a port, which is the stale-install port holder it was written for. The CLI never listens, so a CLI run from a build tree is logged once ("listens on no port (likely the Adom Bridge CLI): leaving it alone") and left running. The respawn guard (ab_process_running) also counts only the installed exe now, so a CLI call in flight no longer blocks respawning a dead ab, and the doc comment says what the function actually does.

Log in to reply.