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.517",+ "version": "2.0.518", "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": "The extension lane runs on adom-you. One profile, the user's real jar, which is what John has said all along should never be anything else: the separate adom-you-ext jar carried none of his cookies, logins or history (measured, 0.2 MB of History against adom-you's 6.3 MB), which is both a pointless divergence and the empty-profile shape bot walls score against. It was only ever separate because Chrome allows ONE process per --user-data-dir and this lane must run with NO debug port, so it cannot coexist with a CDP browser on the same directory. The lane now TAKES the profile: any CDP browser holding adom-you is closed first (otherwise the portless launch forwards to it and exits, silently handing back a window that still carries a debug port), and a CDP launch on adom-you while the lane owns it is refused with a hint to drive pup_ext_* instead of failing 30 seconds later on a missing DevTools port. Nothing is refused once the lane is closed."+ "changelog": "Complete the adom-you handover, and stop the portless launch from dumping tabs into another thread's window. 2.0.517 closed the CDP browser only if it was in ctx.browsers, which is EMPTY right after a pup restart while a Chrome from before the restart is still holding the directory (pup reconnects to those lazily). So the handover no-opped, the portless launch forwarded to that browser, and Chrome opened the lane's URL as a tab inside the kicad-bridge thread's window: John saw a tab appear in someone else's pup window, which is the exact discourtesy this project has a rule about. The profile's own DevToolsActivePort is the source of truth, so the lane now closes whatever is on that port and waits for SingletonLock to clear before launching. Also fixed pup_ext_status still reporting the retired adom-you-ext profile name." }
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.517",+ "version": "2.0.518", "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": "The extension lane runs on adom-you. One profile, the user's real jar, which is what John has said all along should never be anything else: the separate adom-you-ext jar carried none of his cookies, logins or history (measured, 0.2 MB of History against adom-you's 6.3 MB), which is both a pointless divergence and the empty-profile shape bot walls score against. It was only ever separate because Chrome allows ONE process per --user-data-dir and this lane must run with NO debug port, so it cannot coexist with a CDP browser on the same directory. The lane now TAKES the profile: any CDP browser holding adom-you is closed first (otherwise the portless launch forwards to it and exits, silently handing back a window that still carries a debug port), and a CDP launch on adom-you while the lane owns it is refused with a hint to drive pup_ext_* instead of failing 30 seconds later on a missing DevTools port. Nothing is refused once the lane is closed."+ "changelog": "Complete the adom-you handover, and stop the portless launch from dumping tabs into another thread's window. 2.0.517 closed the CDP browser only if it was in ctx.browsers, which is EMPTY right after a pup restart while a Chrome from before the restart is still holding the directory (pup reconnects to those lazily). So the handover no-opped, the portless launch forwarded to that browser, and Chrome opened the lane's URL as a tab inside the kicad-bridge thread's window: John saw a tab appear in someone else's pup window, which is the exact discourtesy this project has a rule about. The profile's own DevToolsActivePort is the source of truth, so the lane now closes whatever is on that port and waits for SingletonLock to clear before launching. Also fixed pup_ext_status still reporting the retired adom-you-ext profile name." }