Pup - the AI's own browser

@@ -25,11 +25,15 @@ does NOT attach to the user's running browser and does NOT run headless. It:    preinstalled — so on a Mac with no Chrome, pup falls through to downloading Chrome (or cached Chrome    for Testing). Don't promise the user "no download" off Windows; check `browser_readiness` instead. It    uses their *browser binary*, never their *profile*.-2. **…with its own isolated `--user-data-dir` + a CDP debugging port** (`--remote-debugging-port`). That's-   a **fresh, empty profile** — no cookies, no logins, no extensions, its own cookie jar keyed by your-   `profile` name — and pup drives it over the Chrome DevTools Protocol. It is never the user's signed-in-   Chrome/Edge. (Need their real profile/cookies/SSO? That's the **Adom extension** `nbrowser_*` — see-   below.)+2. **…with a pup-managed `--user-data-dir` + a CDP debugging port** (`--remote-debugging-port`), driven over+   the Chrome DevTools Protocol. This is a profile **pup owns and persists**, never the user's own signed-in+   OS Chrome/Edge profile. By default every window shares ONE durable profile (`adom-you`), so logins,+   cookies and localStorage **accumulate and are shared across all pup windows** — sign into a site once and+   every pup window is signed in; app state (localStorage) survives between windows. Sharing a profile does+   NOT merge windows: each window is still its own OS window with its own taskbar identity. For a private,+   throwaway window (a fresh-login test, or acting as a different user) pass `{isolated:true}`, or pass an+   explicit `{profile:"<name>"}` for a separate durable jar. (Need the user's REAL signed-in profile/SSO?+   That's the **Adom extension** `nbrowser_*` — see below.) 3. **Renders a REAL window, but keeps it in the BACKGROUND.** It is *not* headless — a real GPU-composited    window, so `browser_screenshot` / recording are true-to-life and canvas/WebGL/media render correctly.    But pup immediately z-orders it to the **bottom** (Windows: Win32 `SetWindowPos` with@@ -42,8 +46,9 @@ does NOT attach to the user's running browser and does NOT run headless. It:    Chromium at all fetches **Chrome for Testing** (~150 MB, last resort). 5. **Is driven by `sessionId`**, and **one session = one window that holds many tabs**. -Keep this model in mind and every verb makes sense: it's a disposable, isolated, backgrounded copy of the-user's own browser, driven by CDP.+Keep this model in mind and every verb makes sense: it's a pup-managed, persistent, backgrounded browser+(the machine's own Chrome/Edge binary, a profile pup owns) driven by CDP — durable and shared by default,+isolated only when you ask.  ## When pup — vs the Adom extension (`nbrowser_*`) @@ -52,8 +57,10 @@ user's own browser, driven by CDP. | Screenshot / scrape / test / demo a page; drive an app you're building; anything that does NOT need the user's logins | **pup (this)** | | Log into a site, use saved passwords, fill a form on a signed-in page, download behind a login, sail past captchas | **Adom browser extension** (`nbrowser_*`, the `adom-browser-extension` skill) — drives their REAL signed-in Chrome/Edge | -pup is **generic only** — a fresh empty profile every time. It cannot use the user's cookies/SSO. That's by-design; the extension is its counterpart for the real profile.+pup drives the machine's browser binary in a profile **pup manages** — durable and shared across pup windows,+but never the user's own signed-in OS Chrome/Edge profile, so it can't borrow logins the user already has+there. pup accumulates its OWN logins over time (sign in once inside pup, it sticks). The extension is the+counterpart when you need the user's REAL profile/SSO directly.  ## Skill map — this is a pack 

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.9.122",+  "version": "1.9.123",   "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. So the pkg version (skills, bumps often) and the Release version (runtime, bumps rarely) differ on purpose. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.",   "keywords": [

@@ -4,7 +4,7 @@   "slug": "adom-desktop-puppeteer-bridge",   "title": "Adom Desktop - Puppeteer Bridge",   "brief": "The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.",-  "version": "1.9.122",+  "version": "1.9.123",   "tags": [     "skills",     "pup",