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.508",+ "version": "2.0.509", "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": "Fix the staging bug that made Chrome refuse nbe, and never hand Chrome an unverified folder again. tools/gen-assets.py listed only TOP-LEVEL files, so nbe's src/ and icons/ folders were dropped and the staged copy was a manifest pointing at a src/sw.js that was never written: Chrome answered with a modal 'Error Loading Extension ... Could not load background script' in John's face and loaded nothing. The generator now walks recursively, and the Rust staging creates parent directories before writing (it had ignored the failed write). Added a sanity gate: before a folder is passed to --load-extension pup checks that every file the manifest references (service worker, popup, icons) is actually on disk, and drops the folder with a log line instead of letting Chrome throw a modal."+ "changelog": "Put the nbe side-load behind pup_configure {nbeInLane}, default off, so the extension lane works again while the cause is found. Measured on AdomLapper: with nbe in the --load-extension list Chrome for Testing spawns and exits within 6 seconds, no load-error dialog, where 2.0.506 came up every time. nbe itself stages correctly now (src/sw.js and the untouched 0.2.13 manifest verified on disk, and the staging sanity gate raises no objection), so the failure is in launching Chrome with it, not in the copy. Default off is the honest state until that is understood." }
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.508",+ "version": "2.0.509", "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": "Fix the staging bug that made Chrome refuse nbe, and never hand Chrome an unverified folder again. tools/gen-assets.py listed only TOP-LEVEL files, so nbe's src/ and icons/ folders were dropped and the staged copy was a manifest pointing at a src/sw.js that was never written: Chrome answered with a modal 'Error Loading Extension ... Could not load background script' in John's face and loaded nothing. The generator now walks recursively, and the Rust staging creates parent directories before writing (it had ignored the failed write). Added a sanity gate: before a folder is passed to --load-extension pup checks that every file the manifest references (service worker, popup, icons) is actually on disk, and drops the folder with a log line instead of letting Chrome throw a modal."+ "changelog": "Put the nbe side-load behind pup_configure {nbeInLane}, default off, so the extension lane works again while the cause is found. Measured on AdomLapper: with nbe in the --load-extension list Chrome for Testing spawns and exits within 6 seconds, no load-error dialog, where 2.0.506 came up every time. nbe itself stages correctly now (src/sw.js and the untouched 0.2.13 manifest verified on disk, and the staging sanity gate raises no objection), so the failure is in launching Chrome with it, not in the copy. Default off is the honest state until that is understood." }