Pup - the AI's own browser

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.659",+  "version": "2.0.660",   "type": "app",   "description": "The pup SKILL PACK: the AI skills that teach a cloud/container AI how to drive the Bridge Puppeteer (pup) bridge (pup_* 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 Bridge 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 Bridge manages for you.",   "keywords": [@@ -148,5 +148,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "pup-bridge#113/#112: the extension lane is per profile; isolated:true and profile:<name> open their own lane browser with their own staged extension, token and queue, no CDP; throwaway lanes end with their last window and are swept at boot"+  "changelog": "pup-bridge#113/#112: per-profile extension lanes (isolated:true and profile:<name> open their own lane browser, no CDP); throwaway lanes end with their last window, staging removed, swept at boot" }

@@ -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.659",+  "version": "2.0.660",   "tags": [     "skills",     "pup",@@ -168,5 +168,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": "pup-bridge#113/#112: the extension lane is per profile; isolated:true and profile:<name> open their own lane browser with their own staged extension, token and queue, no CDP; throwaway lanes end with their last window and are swept at boot"+  "changelog": "pup-bridge#113/#112: per-profile extension lanes (isolated:true and profile:<name> open their own lane browser, no CDP); throwaway lanes end with their last window, staging removed, swept at boot" }\ No newline at end of file

@@ -54,7 +54,7 @@ The toolbar: four icons is the extension lane, three is CDP (John's own spec for  - **Trusted input:** `pup_input_dispatch {type:"click"|"mouseMoved"|"mousePressed"|"mouseReleased"|"mouseWheel"|"keyDown"|"keyUp"|"rawKeyDown"|"char", x, y, ...}` works on the extension lane through the worker's DevTools driver, so the event is as trusted as the CDP lane's and lands inside cross-origin frames. Measured 2026-09-19: a click on the reCAPTCHA demo checkbox passed it and issued a token, no image grid. Captchas are driven here, never on the CDP lane and never handed to the human (the user's rule); the image-grid loop (screenshot, pick tiles, trusted tile clicks, Verify) is the caller's script on top of these verbs. - **`pup_fetch_url`** runs in the named tab on this lane, tries the fetch with credentials and then without (a wildcard CORS header refuses credentials), returns `httpStatus`, `contentType`, `bytes`, `sha256`, and the body as `bodyBase64` (binary-safe) or `text`. `saveTo` takes your container path: the CLI writes the file from the returned body and reports `savedTo` plus `savedToFilesystem:"container"`; compare `sha256` (measured: a 269669-byte PDF, identical hash to the reporter's). A cancelled HTTP auth challenge comes back as `no_credential` with the host.-- **`isolated:true`** now mints a throwaway `iso-<id>` profile (reported by `pup_window_info`) and removes it when the window closes. It still needs `lane:"cdp"`: the extension lane is one browser on adom-you (pup-bridge#113 is the per-profile lane).+- **`isolated:true`** mints a throwaway `iso-<id>` profile (reported by `pup_window_info`), opens it in its OWN extension-lane browser (2.0.659, pup-bridge#113), and ends that browser and removes the profile when the window closes. No `lane` argument, no CDP. Measured: an isolated window on the extension lane read an empty cookie jar while a default-lane window kept working beside it. - **Slow boxes:** a cold `pup_open_window` that would exceed ab's budget answers `ok:true, loading:true` with a progress frame once the window exists and finishes the navigate in the background; poll `pup_window_info` instead of opening again.  ## The CDP lane is OFF by default (2.0.652, John 2026-09-19)@@ -63,4 +63,4 @@ The toolbar: four icons is the extension lane, three is CDP (John's own spec for `pup_configure {cdpLane:"on"}`. John: "i want it almost NEVER used cuz then you may use it as a crutch instead of fixing ext lane to solve all use cases." Trusted input, HTTP auth, fetch, screenshots and recording all run on the extension lane; a feature that genuinely needs CDP is an extension-lane gap to file on adom/pup-bridge, not a reason-to open a CDP window. `isolated:true` on the extension lane is pup-bridge#112/#113 (in progress).+to open a CDP window. `isolated:true` and `profile:"<name>"` run on the extension lane too (2.0.659): each profile gets its own lane browser, its own staged extension and queue, so an isolated window is a separate browser with an empty jar, and a throwaway one ends with its last window.