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.
Releases 1148
Standalone per-platform binaries to download and run, no tools needed. The newest is pinned on top.
The taskbar progress bar is requested for every page load: open, navigate, new tab, reload, back and forward now run it on the window being worked on (only screenshots did before). A leftover safety setting (Minimal-touch, on by default) had switched it off for everyone, and on the extension lane it was aimed at whichever pup window Windows listed first (John, 2026-10-05). Note: Adom Bridge 2.1.168 does not render taskbar progress at all yet (adom/adom-bridge#224), so the bar appears once that is fixed. Includes 2.0.698: restored windows keep their videos paused for 30 s.
Stable link for websites and docs: /download/adom/pup-bridge/latest
All releases showing 81-100 of 1148
The extension reports which path a navigate used, and pup logs a fallback to Chrome's tab API with the reason, because that path surfaces the window and the failure was invisible.
A navigate no longer surfaces the window. Measured with a window pinned in front: the pup window sat behind it, and one chrome.tabs.update({url}) moved it to the very top, which every later call then inherited. That is what flashed a pup window at the user several times per sign-in. Navigation now goes over the DevTools channel (Page.navigate), which does not touch Chrome's tab or window UI.
The cold start is invisible and the consent prompt is gone. The lane launches with --no-startup-window so Chrome never draws or activates a window of its own, plus --keep-alive-for-test which holds a windowless browser open: without it the browser exited within 6 seconds on John's laptop, which is why 2.0.611 had to revert the first flag. The first pup window is now created by the extension like every other one, minimized and shown already at the bottom.
The screen goes back to the user ONCE, at the end of the open and at the end of a Google sign-in, instead of in the middle where the rest of the flow walks over it. Measured on John's laptop: a consented cold start held his screen for 40 seconds because every navigation re-activates the window and Windows will not lower an active window.
The cold-start consent prompt reads ab's answer fields instead of searching the response text. ab echoes both button labels back, so the old contains("not now") check turned every 'Open it' click into a decline and pup opened nothing three times in a row.
Windows will not send the ACTIVE window to the bottom, which is why every park call succeeded while the pup window stayed on top: z-order and focus are one problem. A warm open is invisible. A cold one cannot be, so pup now ASKS the user with a two-button toast and waits for the answer before starting the browser, and afterwards raises the window they were working in so the park finally sticks.
Either invisible or warned, never a surprise. A warm open is invisible: the window is created minimized and made visible already at the bottom of the z-order. A cold open has to start the browser, which draws its own window before pup owns anything, so pup now TOASTS THE USER FIRST and waits a beat before launching.
A pup window is never drawn in front of the user. The keyboard-restoring code is gone: it treated the symptom. Windows are created minimized, the cold-launch watcher HIDES anything new before it is drawn, and the window is then made visible ALREADY at the bottom of the z-order in one call. Foreground happens only when the user is warned or clicks the toast.
Windows pup creates are born minimized and shown without activation, so they never take the keyboard. The cold start keeps its startup window: an extension-lane Chrome launched with --no-startup-window exits before its worker calls home, which broke three opens in a row on John's laptop. The focus guard covers that one case.
pup windows can no longer take the keyboard. The extension creates every window MINIMIZED and pup shows it with SW_SHOWNOACTIVATE before dropping it to the bottom, and the cold lane launches with --no-startup-window so Chrome never makes a window of its own. The CDP lane has carried --no-startup-window since the Node build called it THE fix for the focus-steal war; the extension lane, which is the default, never got it.
The focus guard WATCHES instead of peeking. Checking once right after the park is a race: Chrome can take the keyboard a beat later, after the check has passed, which is how the third of three windows stole it while the first two did not. pup now holds the user's focus for the whole open and for several seconds after a navigate, and hands it back every time a window it owns takes it.
pup gives the keyboard back. Pushing a new window behind the user's work was never enough: Chrome's startup window ACTIVATES, so the user loses whatever they were typing. pup now remembers which window held focus before it opens anything and hands focus straight back the instant a pup window takes it, on both the cold launch and the per-window birth.
A window an AI navigates while the user never asked to see it goes straight back behind their work. It came forward on the navigate, which is how a pup window landed in front of John with the explaining toast 21 seconds behind it. Never applies to a window that is foreground or that he has touched recently.
The cold-launch window watcher now outlives the launch call, which returns as soon as the process ids appear, seconds before Chrome paints its startup window. The first cut of this parked nothing at all.
A cold browser launch no longer throws its startup window over the user's work: pup watches from the instant it spawns the browser and puts any new window behind within 25ms, which is the one case the birth park could not cover.
A new pup window goes behind the user's work the instant its handle exists, instead of after the identity, fit and jump-list work: measured 4 seconds of every new window sitting on top of what the user was typing in. Raising now warns first and the warning is clickable: the toast carries the window, is a warning not an info, and the raise waits a beat behind it.
pup toasts the user the moment it needs them for a password, and the toast carries the window: clicking it opens the exact pup window that is waiting. Covers the Google sign-in answers, a site with no saved login, and the browser-login import's consent wait, which arrives as a Hydrogen notification and was being missed.
Login capture works on the DEFAULT lane. It only ever existed on the CDP lane, so a password typed into a normal pup window was thrown away and pup kept asking for it (John, 2026-09-17). The extension now injects the same capture rail and forwards the credential to pup over loopback, and on a Google password page, which has no username field, it takes the address Google prints on the page.
mac: hide and raise a pup window through NSRunningApplication instead of System Events, so macOS never prompts to control System Events (Kyle's PR #2, merged). Node shell for the public tier. Promoted to public on 2026-09-17.
pup's own kill is no longer read as the user closing a window: a browser pup ends itself (profile handover, lane relaunch, restart) has its windows restored, and only a browser that exits on its own with code 0 is forgotten. Lane adoption no longer learns the pids of a CDP browser pup already owns on another profile, which made a lane relaunch kill it.