kind:exe bridge: ab still runs the node dependency install against the bundled seed on recover_not_listening (pup Rust exe)

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 Issues20 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

What happens

pup's package is now a spawn.kind: "exe" bridge (Rust, adom-pup-bridge.exe, pup-bridge 2.0.403 candidate). ab's bundled seed of the same bridge name (%LOCALAPPDATA%\Adom Bridge\bridges\puppeteer, bridge.json 2.0.1, kind node) still exists on the box. Whenever ab's recover_not_listening path runs for the bridge (the exe was killed or died), ab starts the NODE dependency install against the seed before spawning the exe from the cache:

[ab 2026-09-05 18:05:53] process GONE (exited or was killed ...): port Some(8851) unserved, nothing to reap ...
[ab 2026-09-05 18:05:57] spawned process pid 11380 (adom-pup-bridge.exe)
[ab 2026-09-05 18:05:58] dependency install STARTED (source-only cache; npm install runs detached with its own budget - verbs return bridge_installing_deps until it completes)
[ab 2026-09-05 18:06:11] dependency install FAILED: npm install failed: npm error code 1 | npm error path C:\Users\azureuser\AppData\Local\Adom Bridge\bridges\puppeteer\node_modules\puppeteer | npm error command failed

(from ~/.adom/bridge-logs/puppeteer.ad.log on winvm, ab 2.1.34). The cache dir (bridges-cache\puppeteer) holds only adom-pup-bridge.exe, bridge.json (kind exe), BRIDGE_VERSION. The npm run is against the seed's node_modules\puppeteer and fails in puppeteer's postinstall, the same first-run trap that broke arav-rog.

Effect

For 10 to 15 s after every unexpected exe death, every pup verb answers bridge_installing_deps ("installing its dependencies for the first time") although the bridge has no dependencies at all, and a failing npm run touches the seed's node_modules each time. A fresh install through bridge_install does not show this; only the not-listening recovery does.

Ask

When the installed bridge's spawn.kind is exe, skip ensure_node_modules and the bundled-seed node path entirely on every spawn path (install, respawn, recover_not_listening). The seed for a bridge whose cache is kind exe should not be consulted for dependencies. A bridge_list row that shows the effective spawn.kind would make this visible.

Repro: install the pup candidate on a box that has the bundled pup seed, taskkill /IM adom-pup-bridge.exe /F, then call pup_status a few times and read ~/.adom/bridge-logs/puppeteer.ad.log.

3 Replies

John Lauer · 2mo ago

Confirmed from the code: the exe spawn at 18:05:57 came from the generic bridge path (recover_not_listening -> ensure_bridge_running, which runs the cache's entrypoint), but one second later the BROWSER route's own retry (browser_bridge_request -> 'bridge not listening' -> start_browser_bridge) ran the bundled node start path, whose server.js lookup falls back to the seed when the cache has no server.js - and that path runs the seed's npm install unconditionally. Two spawners, one of them blind to the installed kind.

Fix (ab 2.1.39, insiders shortly): start_browser_bridge now reads the INSTALLED puppeteer bridge from the registry first; if its spawn.kind is anything but node it delegates to the generic spawn path and returns - no seed lookup, no ensure_node_modules, no npm, on every route (install, respawn, recover_not_listening, the browser route's retry). bridge_list rows gain spawnKind (the effective kind of the bridge ab will actually spawn) so this is visible. A fresh bridge_install never showed it because that path already went generic; the recovery retry was the leak.

John Lauer · 2mo ago

Shipped in ab 2.1.39 (insiders): start_browser_bridge now reads the installed puppeteer bridge from the registry first; when its spawn.kind is not node it delegates to the generic spawn path and returns, so the browser route's not-listening retry can no longer run the bundled seed's npm install behind the exe the generic path already spawned. bridge_list rows now carry spawnKind (the effective kind ab will run; on this box every bridge reports correctly, including fusion360 as exe over its old python seed). Verified here that a node-kind pup still starts through the unchanged path.

On winvm, once it converges to 2.1.39: kill the exe, call pup_status, and the puppeteer lifecycle log should show only the exe spawn and no "dependency install STARTED" line. Closing; reopen with the log if that line reappears.

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

More evidence (winvm, ab 2.1.34, pup candidates 2.0.403 to 2.0.408): the stall also fires on a bridge_install of a LIVE kind:exe bridge (ab reaps it for holding its cache dir, then the recover path runs the seed's npm install), and it lasted over two minutes once (every pup verb answered bridge_installing_deps for a whole tools/ab-smoke.sh run). puppeteer.ad.log now counts 8 'dependency install STARTED' lines for a bridge whose package has no package.json at all. The same happened on AdomLapper (ab 2.1.38) when it took the 2.0.407 and 2.0.408 insiders builds: the first pup_status after each install timed out, then everything answered.