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.506",+ "version": "2.0.507", "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": "A fourth teal toolbar button on the extension-driven lane (John: 'i want a 4th icon showing in this bar that's teal and looks similar to your 3 browser extensions you load already so that i can differentiate between CDP lane pup windows and nbe lane pup windows'). New src/extension-lane: an MV3 tile in the existing toolbar family (the same teal rounded square and ink glyph as the dots, pen and identity marks), drawn as a browser window, with a popup saying what the lane is. It stages ONLY when a lane token is set, so three buttons means the CDP lane and four means the extension lane. Note for the record: pup loads no nb extension, so nothing of nbe's was involved; the buttons on a pup window are pup's own four extensions."+ "changelog": "Load the REAL nbe into the extension lane instead of my placeholder. John, correctly: 'i thought that was the whole point of me saying to you, just use the nbe inside pup'. On 2026-08-22 I agreed to add nbe as the 4th --load-extension and then wrote a 259-line control channel of my own instead; measured against nbe it has no click, type, dialog, upload, console or full-page capture at all, so it was a weak duplicate of code we already own. pup now stages nb's extension folder verbatim (src/extension-nbe, synced by tools/sync-nbe.sh, nb's repo stays the source of truth) and adds exactly one file: toolbar.json {toolbarIcon:on}, the packaged default nb built for pup on 2026-09-12 so the icon shows in a pup window while the user's own Chrome keeps Chrome's unpinned default. pup pins it, since an extension cannot pin itself and pup owns the profile. nbe's manifest is deliberately NOT version-stamped the way pup's own extensions are: nb's readiness compares per-profile extension versions and a rewrite would report the user's browser stale. Open question this ships to answer: whether Chrome for Testing finds the inc.adom.native_browser native-messaging host at all." }
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.506",+ "version": "2.0.507", "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": "A fourth teal toolbar button on the extension-driven lane (John: 'i want a 4th icon showing in this bar that's teal and looks similar to your 3 browser extensions you load already so that i can differentiate between CDP lane pup windows and nbe lane pup windows'). New src/extension-lane: an MV3 tile in the existing toolbar family (the same teal rounded square and ink glyph as the dots, pen and identity marks), drawn as a browser window, with a popup saying what the lane is. It stages ONLY when a lane token is set, so three buttons means the CDP lane and four means the extension lane. Note for the record: pup loads no nb extension, so nothing of nbe's was involved; the buttons on a pup window are pup's own four extensions."+ "changelog": "Load the REAL nbe into the extension lane instead of my placeholder. John, correctly: 'i thought that was the whole point of me saying to you, just use the nbe inside pup'. On 2026-08-22 I agreed to add nbe as the 4th --load-extension and then wrote a 259-line control channel of my own instead; measured against nbe it has no click, type, dialog, upload, console or full-page capture at all, so it was a weak duplicate of code we already own. pup now stages nb's extension folder verbatim (src/extension-nbe, synced by tools/sync-nbe.sh, nb's repo stays the source of truth) and adds exactly one file: toolbar.json {toolbarIcon:on}, the packaged default nb built for pup on 2026-09-12 so the icon shows in a pup window while the user's own Chrome keeps Chrome's unpinned default. pup pins it, since an extension cannot pin itself and pup owns the profile. nbe's manifest is deliberately NOT version-stamped the way pup's own extensions are: nb's readiness compares per-profile extension versions and a rewrite would report the user's browser stale. Open question this ships to answer: whether Chrome for Testing finds the inc.adom.native_browser native-messaging host at all." }