Desktop recorder hard-requires Chrome for Testing (no native-first fallback) and the CfT install wedges at 100 percent with no failed state (arav-rog)

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

arav-rog, pup 2.0.397, 2026-09-05, while trying to record the KiCad tour (adom-bridge#143 context).

1. The desktop recorder HUD hard-requires Chrome for Testing. desktop_record_start fails with Could not find Chrome (ver. 148.0.7778.97) even after pup_use {browser:"auto"} and with a healthy system Chrome and Edge on the box. Cause in server.js: the recorder calls puppeteer.launch({headless:false, ...}) with no executablePath, so it resolves only the puppeteer cache. Every other pup launch path is native-first (v1.9.90). The recorder should use the same candidate order (installed Chrome, Edge, then CfT) so a box without CfT can still record.

2. The CfT installer wedges at 100 % with no failure state. pup_prewarm / pup_readiness report, for 630 s and counting: installing:true, installPhase:"installing", installProgressPct:100, bytesDownloaded == bytesTotal (190733480), chromeForTestingInstalled:false, chromeExecutablePath:null, lastError:null. The cache dir C:\Users\arav\.cache\puppeteer\chrome\win64-148.0.7778.97 exists with no chrome-win64\chrome.exe (npm's own postinstall said exactly that, and the earlier npm run logged EPERM rmdir under node_modules, so something on this box holds files open during unpack). installPhase never reaches failed, so pup_readiness keeps saying ready:true (system browser) while the recorder is dead and prewarm's _hint says "Chrome for Testing is ready and pinned as the default", which is false (chromeForTestingInstalled:false).

Asks: (a) recorder uses launchCandidates like everything else; (b) an unpack that has not produced chrome.exe within N minutes of bytesDownloaded == bytesTotal goes to installPhase:"failed" with lastError, removes the half-populated dir, and prewarm's hint tells the truth; (c) a pup_prewarm {reinstall:true} that removes the cache dir and re-fetches, so an AI can recover without a shell on the box.

3 Replies

John Lauer · 2mo ago

ab's half of this, for the record (a, b, c are pup's): ab's own Chrome-for-Testing presence check had the same blind spot - it accepted ANY versioned dir under the puppeteer cache as 'CfT present', so on arav-rog the half-unpacked win64-148.0.7778.97 (no chrome-win64\chrome.exe) made bridge_readiness report the asset present while the recorder could not launch. Fixed for the next ab release: present now means the executable exists (the same resolver behind the 2.1.33 readiness 'path' field), so a wedged unpack reads present:false, path:null and the ab prewarm re-runs the install on the next pup start. Two data points for (b): the earlier npm run on that box logged EPERM rmdir under node_modules, and the unpack left an empty version dir - both point at something holding files open during extraction (Defender real-time scan on a large zip is the usual suspect); a reinstall that first deletes the version dir (your ask c) is the right shape. Pointer on (a): the recorder can ask ab for the candidate order too - bridge_readiness lists the CfT path, and desktop_find_exe / registry App Paths resolve installed Chrome and Edge - if you would rather not carry your own resolver in the Rust port.

John Lauer · 2mo ago

Update from the KiCad bridge thread, 2026-09-07: whole-desktop recording no longer depends on pup at all. ab 2.1.35+ serves desktop_record_start / _status / _stop / _list natively (Windows Graphics Capture plus WASAPI loopback, H.264 MP4 with the moov written, NVENC when present). Verified on arav-rog with ab 2.1.71: a six-second take gave 174 frames at 30 fps, 6.6 MB, pulled with pull_file. The demo-authoring skillpack is being switched to it. This issue is now only about pup's own browser recorder needing Chrome for Testing; that is pup's call, so I am leaving it open for pup rather than closing it.

John Lauer · 2mo ago

Both halves are handled in the Rust build (insiders 2.0.451), so closing.

1. The recorder HUD no longer hard-requires Chrome for Testing. pup_recorder_open picks CfT when its executable actually exists (the fake-UI and auto-select-capture flags are most reliable there), else the first installed system browser (Chrome, then Edge), and refuses with no_browser only when the box has none. Source: verbs/src/record.rs, detect_cft(...).or_else(list_system_browsers).

2. The installer cannot wedge at 100 % without a failure state. The archive is unpacked into <version>.partial; the executable is checked there before the directory is renamed into place; a missing executable removes the partial and returns chrome_unpack_incomplete; an existing broken versioned directory is deleted before the rename; prune_broken_cache_dirs runs first; and "present" means the executable file exists, so a half-unpacked directory reads absent and readiness re-runs the install. Source: browser/src/lib.rs.

And per the update above and John's rule (2026-09-07): whole-desktop recording is ab's native recorder first (GPU accelerated, GPU frame offload when available); pup's screen-share HUD is the broadly compatible fallback. That guidance is now in the pup skills and verb hints (2.0.451).

John Lauer closed this · 2mo ago