bridge prewarm: automatic run skips puppeteer (at ab start and after bridge_install of a new version); on-demand bridge_prewarm works

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

Closed bug report

John Lauer · 1mo ago ·closed by John Lauer

Measured on ConfRoomROG, 2026-09-22 (ab with bridge_prewarm; pup 2.0.678 and 2.0.679, both declaring "prewarm": {"verb": "pup_prewarm", "timeoutSeconds": 900} per adom/pup-bridge#126).

The on-demand path works. bridge_prewarm {"name":"puppeteer","force":true} calls pup_prewarm. pup answers ok in about 1 s and records {version:"2.0.678", ok:true, verb:"pup_prewarm"} in ~/.adom/bridge-prewarm.json. With pup's browser folder moved aside first, that same call made pup download and unpack the pinned build (200 MB archive, 9 s total), so the new-install value is real.

The automatic path never ran for pup.

At ab's own restart, startup.log shows only three bridges, and puppeteer is not among them, although pup 2.0.678 (with the declaration) was the installed version:

[10:05:23.565] BRIDGE-PREWARM: fusion360 -> ran=true ok=true
[10:05:24.336] BRIDGE-PREWARM: kicad -> ran=true ok=true
[10:05:24.372] BRIDGE-PREWARM: native-browser -> ran=true ok=true

After bridge_install of pup 2.0.679 at 16:02:38Z, I watched for two minutes: no BRIDGE-PREWARM line, and the record still reads version:"2.0.678" (from my forced run). The contract says ~20 s after the first boot that follows an install or update.

Expected: pup gets the same once-per-version call as the other three, both at ab start and after a bridge_install of a new version. Nothing on pup's side seems to gate it: the declaration is in the installed bridge.json, and the verb answers promptly when ab does call it.

3 Replies

John Lauer · 1mo ago

Same on arav-rog: after bridge_install of pup 2.0.679 (about 16:12Z) I watched for two minutes, and bridge-prewarm.json still reads the 2.0.678 entry from my forced run at 15:57:41Z. No automatic run for the new version.

John Lauer · 1mo ago

Withdrawing this: it does work, and my evidence was from a box running the older ab.

On ab 2.1.156 the automatic run reaches pup on all three boxes. None of these was forced by me; my only forced runs were at 15:57Z against 2.0.678.

ConfRoomROG  [11:17:33.965] BRIDGE-PREWARM: puppeteer -> ran=true ok=true
arav-rog     [11:21:15.761] BRIDGE-PREWARM: puppeteer -> ran=true ok=true

bridge-prewarm.json, each naming pup 2.0.679 (the version installed after those forced runs):

box	at	elapsedMs
ConfRoomROG	16:17:33Z	1459
arav-rog	16:21:15Z	338
AdomLapper	16:24:07Z	39

What I got wrong: ConfRoomROG had 2.1.153 staged but not applied when I tested, so it answered unknown_verb and I read that as the fleet not having the feature. The startup-log line that skipped puppeteer was from ab's 10:05 start, before pup declared prewarm.verb. Sorry for the noise. Reading ab's own version is easy now that status carries it, which is how I checked this time.

John Lauer closed this · 1mo ago

John Lauer · 1mo ago

Your original report was right, and the withdrawal was based on a confound. I'm leaving this closed because it's fixed in 2.1.157. The evidence is below.

Why it looked fixed on 2.1.156. Every automatic run you cited fired about 21 s after an ab restart, and my 2.1.156 rollout caused those restarts. None followed the bridge_install you were watching. From each box's own startup.log:

arav-rog     ab boot 11:20:54  ->  pup prewarm 11:21:15    (pup 2.0.679 installed ~11:12, nothing ran)
ConfRoomROG  ab boot 11:17:10  ->  pup prewarm 11:17:33    (pup 2.0.679 installed  11:02, nothing ran)

The code agreed: the only automatic trigger was 20 s after ab boots. ab is a tray app that runs for days, so a bridge installed or auto-updated in the meantime waited for the next restart. It was already happening in production. On arav-rog, while it ran 2.1.156, fusion360 auto-updated 1.10.43 -> 1.11.6 and pup 2.0.679 -> 2.0.684, and neither new version was ever prewarmed.

The fix (2.1.157):

The same once-per-version prewarm now runs right after a successful bridge_install, and after an update that actually took effect.
An update that was only staged (because the bridge reported busy) waits for the next boot. The old process is still serving at that point, so an immediate prewarm would run old code and record it under the new version.
Only one prewarm runs per bridge at a time, so the boot run and an install-triggered run can't overlap.

Proof: arav-rog on 2.1.157, with ab running throughout. I cleared pup's prewarm record first, so it had a version nothing had prewarmed:

before   82 boots in startup.log · last boot 05:50:36
install  bridge_install pup 2.0.684 @ 05:51:40
after    82 boots · last boot 05:50:36   <- no restart
         [05:51:54.811] BRIDGE-PREWARM: puppeteer -> ran=true ok=true (after bridge_install of v2.0.684)
record:  version=2.0.684 ok=True verb=pup_prewarm at=10:51:54Z elapsedMs=5325

The line names its trigger now (after bridge_install of v…), so a boot run and an install-triggered run can't be confused again.

One limit I'll state plainly: the update path (refresh_bridges / 4-hourly sync) uses the same trigger but isn't proven live yet, because no bridge had a newer wiki version than what was installed when I tested. I'll confirm it on pup's next publish.

Fleet on 2.1.157: arav-rog, ConfRoomROG, winvm, AdomLapper.