First-run install could never succeed on a box with a half-downloaded Chrome for Testing (puppeteer postinstall); fixed in 2.0.397

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Measured on arav-rog 2026-09-05 (fresh Adom install, standard user, Node 24.16, ab 2.1.31), reported by John: the KiCad thread found pup unusable and nobody told it why.

Chain: ab installs pup's source-only zip and runs npm install. All 132 packages install, then the puppeteer package's postinstall (node install.mjs) downloads Chrome for Testing and REFUSES because ~/.cache/puppeteer/chrome/win64-148.0.7778.97 already exists without chrome.exe (3 files, left by a download interrupted in July; a 196 MB folder named chrome sat next to it). Exit 1, spawn failed, 11 installs, 496 spawn attempts, backoff. pup's own half-populated-folder repair (v1.9.75) never ran because pup never started. The calling thread saw only 10 s timeouts (adom-bridge#142, fixed ab-side in 2.1.30 with bridge_installing_deps).

Fixed in 2.0.397: .puppeteerrc.cjs + package.json puppeteer.skipDownload forbid the postinstall download for good (pup fetches Chrome itself, with progress); chrome.js prunes every cache folder without an executable at warmup and before an install. Verified on arav-rog (install 8 s, pruned both folders, CfT downloaded in 15 s, window opened) and winvm (planted junk folder pruned). The Rust port plan gained a first-run contract section (docs/PLAN-rust-port.md 6b).

2 Replies

John Lauer · 2mo ago

Shipped and verified in pup 2.0.397 (insiders). Closing for the record; the ab-side half is adom-bridge#142.

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

Second finding on the same box, fixed in pup 2.0.398 (insiders): after 2.0.397 got pup running, the Chrome for Testing archive downloaded to 100 % in 15 s (190,733,480 bytes, valid: Windows tar extracted all 308 files), then puppeteer's in-process unzip (extract-zip) wrote three files (manifest, ABOUT, a 0-byte D3DCompiler_47.dll) and never wrote another byte, with the bridge idle (5 s CPU), no error, nothing to kill. That is exactly how the July half-populated folder was born.

2.0.398: pup downloads only (install({unpack:false})) and unpacks in a supervised child process (OS tar first, src/unpack.js extract-zip worker as fallback) with a stall watchdog (90 s without bytes, or 15 min, kills it and tries the next method), into <build>.partial, verifies the exe, renames atomically, deletes the archive. Readiness shows a real phase: "unpack" row. Verified on arav-rog: restart pruned the stuck folder, reused the archive, unpacked via tar (432,272,765 bytes), Chrome for Testing 148.0.7778.97 ready, and a background window opened on chrome-for-testing with the toolbar. Gate: tests/check_unpack.js.