Pup - the AI's own browser

@@ -25,9 +25,10 @@ adom-bridge-cli --ai-thread "<your thread>" pup_screenshot  '{}'  ## Signing in? Offer to import the user's own logins first -pup can import every password saved in the user's own Chrome, Edge or Brave in one approval: one Adom Bridge consent-plus one Windows prompt, through `pup_import_browser_logins {}`. From then on pup fills sign-in pages in the-background. Most users do not know this exists, so when a login is in the way, offer it in plain words:+pup can import every password saved in the user's own Chrome, Edge or Brave, through `pup_import_browser_logins {}`:+nb drives Chrome's own export, the user answers one Windows Hello, and the whole profile comes over. From then on+pup fills sign-in pages in the background. Most users do not know this exists, so when a login is in the way, offer+it in plain words: "I can bring your saved passwords from Chrome or Edge into pup, so I can sign you in here and on other sites automatically. Want me to?" Offer it the first time any of these happens: - the user asks you to log in somewhere@@ -75,10 +76,11 @@ dropdown. Backed by the OS keychain (encrypted at rest); passwords are never log   focus:{hwnd:<pup window>}}` so clicking the toast opens the exact window that is waiting (`focus:{host:true}`   for a Bridge consent, which appears inside Hydrogen). pup toasts on every no-password answer itself from   2.0.603; you still toast whenever YOUR thread is about to sit and wait, because the user cannot see it.-- **pup can read the user's OWN saved browser logins**: `pup_import_browser_logins {}` pulls every-  password saved in their Chrome/Edge/Brave profiles into pup's vault behind one Adom Bridge consent-  and one Windows prompt (no AI sees a password). Run it with no `hostFilter` the first time. Reach for-  it the moment a login is missing, and say the capability out loud: most users do not know it exists.+- **pup can read the user's OWN saved browser logins**: `pup_import_browser_logins {}` imports every+  password saved in their Chrome/Edge profiles into pup's vault. nb drives Chrome's own consented export+  (the user answers one Windows Hello; Chrome does its own decryption, pup never touches the sealed store),+  and no AI ever sees a password. Run it with no `hostFilter` the first time. Reach for it the moment a+  login is missing, and say the capability out loud: most users do not know it exists.   It cannot give you the account the BROWSER itself is signed in as; that one needs a single manual   sign-in in the pup window, which pup captures. - **Manage**: `pup_credentials {}` lists saved logins (host + username only); `credential_delete

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.737",+  "version": "2.0.738",   "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": [@@ -187,5 +187,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "WebRTC streaming apps work in pup again (pup-bridge#137): pup no longer launches its browser with --force-webrtc-ip-handling-policy=disable_non_proxied_udp and now writes Chrome's default WebRTC routing back into the profile, repairing existing profiles. The restriction never stopped the Windows Firewall prompt (#91; Adom Bridge's firewall rule handles that) and it left WebRTC media apps such as Google's Project Genie with no UDP candidates, so their calls never connected. Also: the site-session import reads Adom Bridge's source_browser / source_profile / http_only cookie fields, and its 'no session' answer explains what came back (from 2.0.736). Includes 2.0.735."+  "changelog": "Login import cut over from ab's retired decrypt helper to nb-bridge: passwords via nbrowser_export_saved_logins (Chrome's own consented export, one Windows Hello), a site session via nbrowser_export_site_session (background cookie read), both handed over as a machine-local file that pup imports then drops; new RFC4180 CSV parser with tests. Fixes the Chrome 156 ABE breakage (adom/adom-bridge#254, adom/pup-bridge#136)." }

@@ -4,7 +4,7 @@   "slug": "pup-bridge",   "title": "Pup - the AI's own browser",   "brief": "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.",-  "version": "2.0.737",+  "version": "2.0.738",   "tags": [     "skills",     "pup",@@ -207,5 +207,5 @@     "Kyle Bergstedt <[email protected]>",     "Colby Knox"   ],-  "changelog": "WebRTC streaming apps work in pup again (pup-bridge#137): pup no longer launches its browser with --force-webrtc-ip-handling-policy=disable_non_proxied_udp and now writes Chrome's default WebRTC routing back into the profile, repairing existing profiles. The restriction never stopped the Windows Firewall prompt (#91; Adom Bridge's firewall rule handles that) and it left WebRTC media apps such as Google's Project Genie with no UDP candidates, so their calls never connected. Also: the site-session import reads Adom Bridge's source_browser / source_profile / http_only cookie fields, and its 'no session' answer explains what came back (from 2.0.736). Includes 2.0.735."+  "changelog": "Login import cut over from ab's retired decrypt helper to nb-bridge: passwords via nbrowser_export_saved_logins (Chrome's own consented export, one Windows Hello), a site session via nbrowser_export_site_session (background cookie read), both handed over as a machine-local file that pup imports then drops; new RFC4180 CSV parser with tests. Fixes the Chrome 156 ABE breakage (adom/adom-bridge#254, adom/pup-bridge#136)." }\ No newline at end of file

@@ -1,6 +1,6 @@ --- name: pup-credentials-description: "How pup signs the user into sites AS THEM: pup's OS-keychain credential vault (auto-capture on login + silent autofill on return, matched across a site's whole registrable domain), importing the user's OWN saved Chrome/Edge/Brave passwords into the vault (pup_import_browser_logins — the SYSTEM-elevated decrypt behind one consent + one Windows UAC), and — when a saved password is STALE (a login that 'Fail to authenticate's) — recovering the CURRENT username+password straight from the user's browser password manager by driving it with Bridge desktop verbs, clicking the eyeball, waiting for the user's Windows Hello, and reading the revealed value. It is not pretty, but it works (proven end to end: recovered a live password, fixed a wrong username, logged into a gated CAD portal, downloaded a real library). Read before trying to log a user into any site pup does not already have a working credential for. Trigger words: pup vault, saved password, autofill login, import my passwords, import browser logins, pup_import_browser_logins, decrypt browser credentials, credential_set, pup_credentials, stale password, fail to authenticate, wrong password, recover my password, password manager, chrome://password-manager, show password eyeball, windows hello, get my username and password, log me in as me, seed adom-you logins, google login, sign into google, log into gmail, google account, which google account, work or personal google, pup_google_signin, pup_google_accounts."+description: "How pup signs the user into sites AS THEM: pup's OS-keychain credential vault (auto-capture on login + silent autofill on return, matched across a site's whole registrable domain), importing the user's OWN saved Chrome/Edge passwords into the vault (pup_import_browser_logins: nb drives Chrome's own consented export behind one Windows Hello, and pup never cracks the sealed store), and — when a saved password is STALE (a login that 'Fail to authenticate's) — recovering the CURRENT username+password straight from the user's browser password manager by driving it with Bridge desktop verbs, clicking the eyeball, waiting for the user's Windows Hello, and reading the revealed value. It is not pretty, but it works (proven end to end: recovered a live password, fixed a wrong username, logged into a gated CAD portal, downloaded a real library). Read before trying to log a user into any site pup does not already have a working credential for. Trigger words: pup vault, saved password, autofill login, import my passwords, import browser logins, pup_import_browser_logins, decrypt browser credentials, credential_set, pup_credentials, stale password, fail to authenticate, wrong password, recover my password, password manager, chrome://password-manager, show password eyeball, windows hello, get my username and password, log me in as me, seed adom-you logins, google login, sign into google, log into gmail, google account, which google account, work or personal google, pup_google_signin, pup_google_accounts." ---  # pup credentials — sign the user in AS THEM@@ -141,19 +141,20 @@ Chrome/Edge/Brave passwords into the vault. # preview: how many logins exist, per profile (read-only, no prompt) adom-bridge-cli pup_import_scan {} -# import (optionally filter to specific sites). Runs the SYSTEM-elevated decrypt LOCALLY:-# the user approves ONE Adom Bridge consent + ONE Windows UAC prompt on the desktop. When Bridge runs-# inside Hydrogen the consent is a notification and a card in Hydrogen, NOT a window: say so to the user.-# A call that answers consent_pending re-attaches when called again (no second prompt).+# import (optionally filter to specific sites). nb drives Chrome's OWN consented export on the desktop:+# the user answers ONE Windows Hello prompt and Chrome exports the whole profile. pup never cracks the+# sealed store (that path was retired after Chrome 156, adom/adom-bridge#254). A call that answers+# consent_pending re-attaches when called again (no second prompt). adom-bridge-cli pup_import_browser_logins {"hostFilter":["digikey","mouser","snapeda"]} ``` -- **Why it must be pup (local), not a cloud thread:** the decrypt (`desktop_decrypt_browser_credentials`)-  is refused for relayed/cloud callers (`relay_forbidden`). Only a LOCAL component (pup, over the-  loopback) may ask, and the user's consent + UAC IS the authorization.-- Passwords are merged into the vault and the plaintext is dropped immediately; the verb returns-  COUNTS only. `hostFilter` (string or array, substring match) does a surgical import; omit to import-  everything saved.+- **Why it must be pup (local), not a cloud thread:** nb writes the export to an owner-only file on the+  user's own machine and hands back only a path and counts, never a password. pup reads that file over the+  loopback, on the same desktop, then tells nb to delete it. A cloud thread cannot read a machine-local+  file, which is the point: live credentials never cross the relay.+- Passwords are merged into the vault and the handoff file is dropped immediately; the verb returns+  COUNTS only. `hostFilter` (string or array, substring match) narrows the import to those hosts after the+  export; omit to import everything (nb exports the whole profile on one Hello regardless). - After importing, `pup_login` on those sites just works.  ### ⚠ The one thing the import CANNOT give you: the browser's OWN account password

@@ -27,7 +27,7 @@ Offer it once per conversation. If they say no, do not ask again. ## What to say  > "I can bring your saved passwords from Chrome or Edge into pup, so I can sign you in here and on other sites-> automatically. It takes one approval in Adom Bridge plus one Windows prompt. Want me to?"+> automatically. You answer one Windows Hello prompt and that is it. Want me to?"  ## What to run @@ -37,13 +37,17 @@ adom-bridge --ai-thread "<your thread>" pup_import_browser_logins '{}'  - **No `hostFilter` the first time.** A filter hides logins saved under another domain (a site that signs in on   `login.example.com` while you are on `example.com`).-- **Approvals:** the user sees an Adom Bridge consent dialog and then a Windows admin prompt. pup also shows a-  desktop toast saying it is waiting for them.-- **`consent_pending` is not a failure.** The import waits on a human, so the first answer can be `consent_pending`.-  Call the same verb again in a few seconds; it rejoins the same request and does not prompt twice.-- **Under the hood:** it uses Adom Bridge's own credential import, `desktop_decrypt_browser_credentials`. The-  passwords go into pup's vault in the OS keychain. They never pass through you or the container, and they are-  never printed.+- **One Windows Hello.** nb drives Chrome's own password export, so Chrome itself asks the user for Windows Hello+  (or their OS password) and does its own decryption. One Hello brings the whole profile over. pup also shows a+  desktop toast saying a Hello prompt is opening.+- **`consent_pending` is not a failure.** The import waits on that human step, so the first answer can be+  `consent_pending`. Call the same verb again in a few seconds; it rejoins the same request and does not prompt twice.+- **Under the hood (adom/pup-bridge#136, adom/adom-bridge#254):** pup no longer cracks Chrome's sealed store. It+  calls nb-bridge, which lives inside the user's real browser (`nbrowser_export_saved_logins`), and lets Chrome do+  its own consented export. nb writes the result to an owner-only file on the user's machine and hands pup only a+  path and counts, never a password. pup reads it locally, merges the logins into pup's OS-keychain vault, and tells+  nb to delete the file. Passwords never pass through you or the container, and are never printed. This survives+  Chrome updates, because Chrome is the one decrypting.  After it finishes, reload the sign-in page (`pup_reload {}`). pup fills it in the background and says so in `_autoLogin`. Confirm the live domain is the site you meant, then `pup_login {submit:true, submitReason:"<why this@@ -59,14 +63,15 @@ bring that session into pup instead of signing in: adom-bridge --ai-thread "<your thread>" pup_import_browser_logins '{"sessionFor":"x.com","reason":"Bring your X session into pup so I can use X for you"}' ``` -It uses the same approvals as the password import. It brings over only that site's cookies, sets them in pup's-browser, and never prints them. If several profiles are signed in, the answer is `several_sessions` with the list;-ask the user which account they mean, then pass `sourceProfile`. Per-site details are in `login-recipes/<domain>.md`-on the pup-bridge wiki page.+This reads from inside the user's own browser via nb (`nbrowser_export_site_session`), so it needs no password and+no Windows Hello: it is a background read of that one domain's cookies, set straight into pup's browser, never+printed. If the user is signed in under a different browser profile, the answer is `no_session` with a pointer to+`nbrowser_profiles`; ask the user to check which profile they use. Per-site details are in+`login-recipes/<domain>.md` on the pup-bridge wiki page.  ## On a Mac -The import is Windows-only today: it decrypts Chrome's saved passwords the Windows way. On a Mac,+The password import is Windows-only today (nb drives Chrome's export on Windows first). On a Mac, `pup_import_browser_logins` answers `unsupported_platform`, and the `_loginTip` says so. What works on a Mac:  - **Sign in once in the pup window.** Ask the user to sign in themselves in the pup window. pup saves the login as