app
Pup - the AI's own browser
Public Made by Adomby 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.
← Commit history
package.json+2−2@@ -1,6 +1,6 @@ { "slug": "pup-bridge",- "version": "2.0.510",+ "version": "2.0.511", "type": "app", "description": "The pup SKILL PACK \u2014 the AI skills that teach a cloud/container AI how to drive the Adom Desktop Puppeteer (pup) bridge (browser_* verbs): the everyday `pup` skill plus focused sub-skills for windows/sessions/tabs, screenshots+recording, browsers+Chrome install, and driving the Adom wiki. Installs into ~/.claude/skills + ~/.codex/skills. DOCS ONLY \u2014 this is NOT the bridge runtime. The bridge itself (the Node program that drives the browser) runs on the DESKTOP: Adom Desktop bundles it and auto-installs/updates it, and it's published separately on the Releases tab as adom-bridge-puppeteer-v<ver>.zip. The pkg version is kept in lockstep with the Release version so the page's max version row always carries BOTH a pkg tarball (skills) and a runtime zip (bridge) \u2014 a skills-only or runtime-only bump on the top row breaks constraint installs. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.", "keywords": [@@ -147,5 +147,5 @@ "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js" } ],- "changelog": "Re-attach to an extension browser that outlived the pup process. EXTDRIVE_LANE and EXTDRIVE_PIDS were in-memory only, so every bridge_install (which restarts pup) orphaned a running ext browser permanently: take_command_for rejects every poll while the token is empty, so the live extension could never re-attach, alive() stayed false, the next pup_ext_open launched a SECOND Chrome that forwarded to the running instance and exited at once (the '1 process(es)' line in the log), and pup_ext_close killed nothing because it knew no pids. Measured on AdomLapper: pup reported browserRunning:false while two of its own Chrome for Testing windows were on John's screen. This also invalidated every nbe measurement taken today, including the one that made me blame nbe for the lane being down. The lane token and pids are now parked in extlane/lane.json, restored at boot against live pids only, and cleared when the lane is closed."+ "changelog": "Fix the poisoned port.json memo that made the extension lane permanently silent. packagedPort() memoized on 'if (_pkgPort !== null)' while its catch set _pkgPort = 0, so ONE failed first read (it races service-worker startup, and sweepBadges can trigger it before the drive loop) locked the memo forever: 0 is !== null so it never retried, and _pkgLane stayed empty, which pupExtPoll treats as 'not the drive browser' and returns. Measured on AdomLapper: the lane window launched, loaded all three toolbar extensions, was stamped and sized correctly, and lastPollMsAgo was never set. Only a SUCCESSFUL read is memoized now; a failure leaves the memo unset so the next tick retries. Also correcting the record from 2.0.510's note: pup_ext_diag attaches over CDP to the adom-you browser by design and never talks to the lane, so the 2.0.506 worker it reported was not cross-talk." }
page.json+2−2@@ -4,7 +4,7 @@ "slug": "pup-bridge", "title": "Pup - Puppeteer Bridge", "brief": "pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.",- "version": "2.0.510",+ "version": "2.0.511", "tags": [ "skills", "pup",@@ -167,5 +167,5 @@ "pup-bridge verbs are invoked through the adom-bridge CLI, not through a binary this package installs, so prefix rules cannot reach them." ] },- "changelog": "Re-attach to an extension browser that outlived the pup process. EXTDRIVE_LANE and EXTDRIVE_PIDS were in-memory only, so every bridge_install (which restarts pup) orphaned a running ext browser permanently: take_command_for rejects every poll while the token is empty, so the live extension could never re-attach, alive() stayed false, the next pup_ext_open launched a SECOND Chrome that forwarded to the running instance and exited at once (the '1 process(es)' line in the log), and pup_ext_close killed nothing because it knew no pids. Measured on AdomLapper: pup reported browserRunning:false while two of its own Chrome for Testing windows were on John's screen. This also invalidated every nbe measurement taken today, including the one that made me blame nbe for the lane being down. The lane token and pids are now parked in extlane/lane.json, restored at boot against live pids only, and cleared when the lane is closed."+ "changelog": "Fix the poisoned port.json memo that made the extension lane permanently silent. packagedPort() memoized on 'if (_pkgPort !== null)' while its catch set _pkgPort = 0, so ONE failed first read (it races service-worker startup, and sweepBadges can trigger it before the drive loop) locked the memo forever: 0 is !== null so it never retried, and _pkgLane stayed empty, which pupExtPoll treats as 'not the drive browser' and returns. Measured on AdomLapper: the lane window launched, loaded all three toolbar extensions, was stamped and sized correctly, and lastPollMsAgo was never set. Only a SUCCESSFUL read is memoized now; a failure leaves the memo unset so the next tick retries. Also correcting the record from 2.0.510's note: pup_ext_diag attaches over CDP to the adom-you browser by design and never talks to the lane, so the 2.0.506 worker it reported was not cross-talk." }