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.
909 downloads in the last 30 days
Releases 1153
Standalone per-platform binaries to download and run, no tools needed. The newest is pinned on top.
Latest release
v2.0.705
Annotate's quick colors are red, blue and green: the muddy yellow/orange third color is gone from the trio and from Multi's automatic cycle (red, blue, green, purple), so every mark has a color anyone can name to the AI. Yellow stays in the More flyout, and every swatch shows its color name on hover (John, 2026-10-07).
Stable link for websites and docs: /download/adom/pup-bridge/latest
All releases showing 401-420 of 1153
v2.0.299
2026-08-23
- v2.0.298: Settings: dashboard saves are bounded at 5s (AbortController) per settings-layout; optimistic DOM already reflects the click. (John Lauer)
v2.0.298
2026-08-23
- v2.0.297: Settings modal polish after reading the pixels: choice cards never upscale their real crops (1:1, identical zoom across the set, max 270px cards), sidebar parents carry a caret, row prose no longer duplicates the card prose, caption-bar example cropped tight to the strip itself. (John Lauer)
v2.0.297
2026-08-23
- v2.0.296: Settings dialog rebuilt to the Adom settings-layout standard (adom-ui-design 1.7.1): dismissible modal from the header cog (Escape, X, click-outside), 25% dim never blur, radius element never scrolls, house scrollbar, category sidebar with jump-to + scroll-spy over ONE continuous pane, sections > cards (3px teal accent, live status, full-sentence mechanism prose) > rows (breadcrumb names with teal last part, full key in title, Default on every row), house toggles (role=switch), dependent settings indented under a spine and dimmed never hidden, choice cards with one REAL screenshot per option for taskbar activity / grouping / icon style, two-click auto-disarming Restore defaults (new dashboard action), local-first optimistic saves that keep scroll position. Zero em-dashes. (John Lauer)
v2.0.296
2026-08-23
- ship.sh publish guard actually works now: the old 'publish | tail || die' tested tail's exit code (always 0) so a failed publish still shipped silently (how 2.0.295's row went up empty). Now captures the real exit code AND verifies the registry top row carries a tarball before the ship passes. Local repo folder renamed to pup-bridge; path refs updated. (John Lauer)
- Publish 2.0.295 (John Lauer)
- v2.0.295: pup-bridge#66 follow-up: the pup-dashboard --print-url direct-127.0.0.1 fix was pushed to the repo AFTER the 2.0.294 tarball published, so installs still got the localhost:7380/proxy form (the exact artifact-predates-fix failure shape ship.sh was just hardened against). No bridge-runtime changes; this ship exists to republish the skillpack tarball in lockstep with the fixed tools/pup-dashboard. (John Lauer)
v2.0.295
Verified
2026-08-23
v2.0.294
Verified
2026-08-23
v2.0.293
2026-08-23
- settings consolidation (2.0.292): document taskbarActivity as the single taskbar-activity control; remove openFlash/autoFlash/agentActivity/fgWatch from pup-settings; note fgWatch folded into notMineCaption; off-screen-birth intro (John Lauer)
- v2.0.292: Settings audit/consolidation (John): collapse openFlash + autoFlash + agentActivity + fgWatch into the single taskbarActivity control (progress|flash|off) + notMineCaption. fgWatch's foreground-STEAL purpose died with off-screen birth; its 20s self-foreground caption now honors notMineCaption. Fixed stale titleTag description (resolution is the SetProp tag now, not the title). Removed the 4 rows + their whitelist/defaults. (John Lauer)
v2.0.292
2026-08-23
- v2.0.291: Settings dialog: visual examples for the non-obvious settings John flagged — Taskbar activity signal (progress/flash/off, image switches with the choice), Caption bar on captures, and Adom toolbar in Chrome. Illustrations shipped in src/icons/settings-ex. Also de-em-dashed the taskbarActivity description. (John Lauer)
v2.0.291
2026-08-23
- v2.0.290: Foreground caption now shows FIRST then raises (awaited, was fire-and-forget so it trailed the window ~5s), and names the initiating AI thread + reason (John). Applies to pup_raise_os_window and the osRaiseSessionWindow choke point. (John Lauer)
v2.0.290
2026-08-23
- NEW skill pup-taskbar-progress + install/package wiring for the taskbar progress-bar feature (v2.0.289) (John Lauer)
- v2.0.289: Taskbar PROGRESS BARS instead of the orange flash (John): determinate bar on a window's taskbar button sized to the running-average duration of the operation (persisted per-op timing). Built-in for icon-apply (open until the icon lands) and screenshots; withTaskbarProgress() wraps any op. New setting taskbarActivity=progress|flash|off (default progress) gates the auto-flash. New skill pup-taskbar-progress. (John Lauer)
v2.0.289
2026-08-22
- v2.0.288: Honest log fix: the birth-resolved line said 'locked set-diff' but the capture is the unique-title method now (v2.0.287); corrected to 'unique-title capture, concurrency-safe'. No behavior change. (John Lauer)
v2.0.288
2026-08-22
- CORRECT the birth sequence: unique off-screen COORDINATES do NOT work (Windows clamps off-screen coords on-screen) - the code births at fixed -32000 and identifies by a UNIQUE TRANSIENT TITLE (v2.0.287), not coordinate. Removes a false claim I'd made to John. (John Lauer)
- v2.0.287: Concurrency fix: birth-time hwnd capture uses a UNIQUE transient title per window (set on about:blank pre-navigation) instead of the set-diff that refused when >1 window materialized at once. Fixes random per-window failures on multi-open (no handle -> window foregrounds + gets wrong/no icon; which window lost was nondeterministic). (John Lauer)
v2.0.287
2026-08-22
- pup-render-test: record the blank-occluded-thumbnail CONCLUSION - focus-emulation foregrounds (reverted), launch flags can't be leased, so occluded hover-thumbnails are left blank on purpose; pup_screenshot (CDP off-screen buffer) works on bg windows without foregrounding and reveal renders natively, so impact is only the hover preview (John Lauer)
- v2.0.286: pup_screenshot: if a capture ever brings the window to the FOREGROUND (a window-level fallback when CDP can't serve it) with no recent user input, caption ' · screenshotting' so the user always knows what put a window on their screen. No-op on the common CDP path (measured 0/101 non-foregrounding). John: uncaptioned screenshot-foregrounds are why he kept catching me. (John Lauer)
v2.0.286
2026-08-22
- v2.0.285: REVERT the focus-emulation blank-window fix (v2.0.280-284): Emulation.setFocusEmulationEnabled activated the OS window and foregrounded a background pup window (the exact focus-steal off-screen birth prevents), and did not reliably fix the blank thumbnail. Removed the birth call, the render lease, and its watchdog. Blank-occluded-window remains an open problem to solve WITHOUT touching OS focus. (John Lauer)
v2.0.285
2026-08-22
- v2.0.284: Render lease production value (5 min). Also documents the DWM-cache finding: a window renders while loading (focus-emulation on), DWM caches that frame so the taskbar thumbnail shows content thereafter; the lease keeps it fresh for 5 min then throttles for battery. (John Lauer)
v2.0.284
2026-08-22
- v2.0.283: Render LEASE (John's pick): a window keeps its render surface (thumbnail/reveal show content) for a lease after each interaction, then throttles to blank to save battery - mirrors the highFps lease. Reconciled by a watchdog. [shipped with 90s TEST lease to prove the cycle; 5min to follow] (John Lauer)
v2.0.283
2026-08-22
- v2.0.282: Blank-window fix v2: keep focus-emulation ON (retained), not a one-shot. Measured via DWM thumbnail that the one-shot failed (Chrome releases an occluded window's page surface, so the single frame is discarded). Retained focus-emulation keeps the composited surface alive so occluded thumbnails/reveals show content; static pages still idle (no continuous render). (John Lauer)
v2.0.282
2026-08-22
- NEW ralph render test (John's taskbar-hover method, automated): tools/ralph-render-test.ps1 captures the DWM thumbnail (ground truth for whether an occluded window PAINTED, without forcing a render like a screenshot does) + dev-skills/pup-render-test. Proven: DigiKey/TI render in background (distinct 13-14), a blank window ~9; pair with DOM bodyLen to tell a render bug from an empty bot-wall page. (John Lauer)
- v2.0.281: Blank-window fix is now a ONE-SHOT pulse, not continuous render (John: 'one rAF to get a rendering to occur'): pulse focus-emulation on for two animation frames then turn it OFF, so the window paints its content once (Chrome retains the last frame while occluded) then returns to throttled/idle. No ongoing CPU/battery cost. (John Lauer)
v2.0.281
2026-08-22
- v2.0.280: Blank-window fix (John's theory, measured): a window born off-screen then parked occluded had visibilityState:hidden with rAF not firing, so it never painted its first frame and looked blank. Enable Emulation.setFocusEmulationEnabled per-page at birth so the renderer composites content while occluded; static pages still idle (no issue-#14 battery drain, unlike highFps launch flags). (John Lauer)
v2.0.280
2026-08-22
- v2.0.279: Deterministic identity: tag confirmed handles via _ensureWindowTagged at every resolution chokepoint (bestSessionHwnd short-circuit + resolver cached/birth/property branches), guarded to fire once per handle. Fixes tags never being written because bestSessionHwnd short-circuited before the resolver. (John Lauer)