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.513",+ "version": "2.0.514", "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": "Publish the lane token AFTER the stale-browser kill, not before. 2.0.510 taught kill_extdrive to clear EXTDRIVE_LANE, which is correct on its own, but launch_extdrive set the token first and called the kill afterwards, so every launch wiped the token for the launch it was preparing: the extension polled with the correct lane and pup compared it against an empty string and refused, forever. That is why the lane looked dead since 2.0.510 and why I wrongly blamed nbe, then the port.json memo. The /exthello line added in 2.0.512 printed the mismatch in one line: 'carrying lane ext-... (pup wants \"\")'."+ "changelog": "Adopt a running extension browser pup has lost track of. When nothing has been served since this pup launched and a browser on pup's own profile says hello with a lane token, pup takes that token instead of fighting it. That case is unwinnable otherwise: the browser is unkillable because pup no longer knows its pids (a restart, or a close whose kill missed the main process and deleted lane.json on the way out), and each new launch simply forwards to it and exits, which is the '1 process(es)' line that has haunted this lane all day. Adoption cannot hijack a working lane, because a working lane has served at least one poll." }
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.513",+ "version": "2.0.514", "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": "Publish the lane token AFTER the stale-browser kill, not before. 2.0.510 taught kill_extdrive to clear EXTDRIVE_LANE, which is correct on its own, but launch_extdrive set the token first and called the kill afterwards, so every launch wiped the token for the launch it was preparing: the extension polled with the correct lane and pup compared it against an empty string and refused, forever. That is why the lane looked dead since 2.0.510 and why I wrongly blamed nbe, then the port.json memo. The /exthello line added in 2.0.512 printed the mismatch in one line: 'carrying lane ext-... (pup wants \"\")'."+ "changelog": "Adopt a running extension browser pup has lost track of. When nothing has been served since this pup launched and a browser on pup's own profile says hello with a lane token, pup takes that token instead of fighting it. That case is unwinnable otherwise: the browser is unkillable because pup no longer knows its pids (a restart, or a close whose kill missed the main process and deleted lane.json on the way out), and each new launch simply forwards to it and exits, which is the '1 process(es)' line that has haunted this lane all day. Adoption cannot hijack a working lane, because a working lane has served at least one poll." }