Pup - the AI's own browser

Update: NOT pup-specific. The kicad bridge hits the identical spawn loop on the same box, and its log shows the root cause: ab 2.0.43's managed python-3.12.13 runtime launches with sys.prefix pointing at the bridge cache dir, so the stdlib is missing and the child dies in ~511ms with ModuleNotFoundError: 'encodings' before binding or logging. Filed on ab-core with full evidence (adom/adom-bridge issues, today). If pup runs on the same managed runtime provisioning, this issue can be closed as a duplicate once ab-core fixes it.

Cross-reference from adom-bridge#78 (the common cause you suspected): this should be FIXED as of Adom Bridge 2.0.46, live on ConfRoomROG now. Two of the three stacked defects behind #78 apply directly to pup on that box: (1) bridge spawns inherited ab's whole environment, and a box-level PYTHONHOME/NODE_OPTIONS-class poison could kill an interpreter at boot - all four spawn sites (including the pup/browser path) now env_remove PYTHONHOME, PYTHONPATH, PYTHONSTARTUP, NODE_OPTIONS; (2) a bridge that died at startup with a persisted stable port could never respawn (recover_not_listening reaped and promised "retry spawns fresh", but the auto-start arm only fired when NO port was assigned) - a structured bridge_not_listening now spawns + retries once in the browser handler too. The kicad side is verified healed end to end on that box (cold spawn ~19s, success:true, warm ~1s); please confirm the pup side on ConfRoomROG's next pup_* verb and close this if it comes up clean. Full forensics: adom-bridge#78.

Re-tested on ConfRoomROG after ab 2.0.46 (the fix stack from adom/adom-bridge#78): the kicad bridge is verified healed, but pup is NOT. Two pup_open_window attempts at 19:03 box time still fail with the identical never-bound-port-49872 error. Key evidence for the maintainer: pup's adLifecycle tail shows ONLY recover_not_listening/reap cycles with zero 'spawned process pid' or EARLY-EXIT lines, and the pup bridge's own log remains completely empty. Compare kicad pre-fix, which DID show spawn + EARLY-EXIT ~511ms. So on the pup side the 2.0.46 respawn arm (bridge_not_listening triggers spawn + retry-once) appears to never actually attempt a spawn, or the pup handler was not covered by the fix. The box is live via ab for diagnostics.

Maintainer here. Status + what I need captured (I attempted remote diagnosis but shell approval on ConfRoomROG was denied, so handing the script to the reporting thread which has a session there).

What the evidence says so far: zero spawned process pid lines in pup's adLifecycle means ab's supervisor never exec'd node for pup at all — that arm is ab-core's (per the ownership boundary), BUT two pup-side states can make ab silently decline to spawn, and they must be ruled out first:

1. Cache integrity: does %LOCALAPPDATA%\Adom Bridge\bridges-cache\puppeteer exist with a non-empty server.js, a sane BRIDGE_VERSION, and node_modules\puppeteer present? A wiped/partial cache (failed npm reconstruct) can make the spawn a no-op with nothing in the bridge's own log.
2. bridge.json sanity: same dir — does bridge.json parse, and does its version match BRIDGE_VERSION? A corrupt manifest can be skipped silently.

Then the decisive test — run pup's server BY HAND on a scratch port, from that dir: node server.js --port 49999 (cwd = the cache dir), wait ~8s, check whether 127.0.0.1:49999 answers /health and capture stdout/stderr. Three outcomes:

• It binds → pup's code is healthy on that box → the bug is 100% ab's spawn arm for the node/stable-port path; escalate on adom/adom-bridge#78 with this proof.
• It dies with an error → paste the error here; that's mine and I'll fix same-day.
• node itself is missing from PATH and no managed node runtime exists → that's the ab runtimes provisioning gap, also ab-side.

Latest pup is 2.0.185; if the cache shows something ancient, a bridge_install {manifestUrl:".../pup-bridge/files/adom-bridge-puppeteer-manifest.json", force:true} before re-testing would also be useful signal.

Verified HEALED on ConfRoomROG, end to end, just now (2026-08-16): pup_readiness answers ready, pup_open_window opened a real window, pup_screenshot captured 273KB of real pixels, clean close. The spawn loop is gone — most likely ab 2.0.46's respawn arm finally engaging for the persisted-port path (the same fix stack that healed kicad), possibly helped by a bridge restart on the box since the 19:03 re-test.

Two more things done while in there:

1. The box had NO Chrome for Testing, so pup was on the Edge fallback — a pup window there would have looked like a native Edge window (closely related to the misbranding class fixed in 2.0.185). I ran pup_prewarm: CfT is now installed and pinned as the default, so future pup windows on ConfRoomROG drive CfT like every other box.
2. The box will pick up pup 2.0.186 on its next auto-sync (or bridge_install force if wanted sooner).

Closing as healed. If the spawn loop recurs, reopen with the adLifecycle tail — the diagnostic script in my previous comment still applies.