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.
← Commit history
CHANGELOG.md+23@@ -2,6 +2,29 @@ ## UNRELEASED (rides the next version) — AD-base re-discovery + self-guarded powershell primitives +### Recorded WHY the desktop_taskbar gates stay (the obvious reading is wrong)++Raised with AD as an open question — pup gates every `desktop_taskbar` call on `win32`, and if mac+AD had gained the capability those gates would be silently suppressing a shipped feature. AD+answered from source: **it is not a no-op on macOS.** `requestUserAttention` really bounces the+Dock and `NSDockTile` really sets badge text.++The gates stay anyway, for a reason neither side predicted: **the capability is real but the+addressing model is incompatible.** macOS has no per-window taskbar button, so AD's mac path+ignores `titleContains`/`hwnd` (it reports `hwnd:0`) and paints **AD's own Dock tile**. pup's use is+inherently per-session-window — *which of these five pup windows is this thread driving* — so+un-gating would badge Adom Desktop instead of the pup window, with every session fighting over one+tile. AD also skips `overlay.icon` on mac outright, which is what these calls pass.++The guard now carries that reasoning in full, because "Windows-only" was an imprecise rationale+that invites a future un-gate the moment someone learns `desktop_taskbar` works on a Mac. It does;+it just cannot address what pup needs addressed. The per-window equivalent of this cue on macOS is+`browser_alert_window`'s toast-and-unhide path.++Method note worth keeping: both ABE and I initially read "returns success on macOS" as "works on+macOS". It does work — but our evidence established dispatch and arg validation, not effect, and+the *real* answer turned out to be a third thing neither reading covered.+ ### The RUNTIME describe catalog and hints still said "taskbar" after the docs were fixed KICAD's finding, reproduced in pup: after fixing the shipped SKILL.md entries I had not touched
src/server.js+12@@ -2445,6 +2445,18 @@ async function dualBadgeB64(wins, tabs) { // once), never one call per verb, so a chatty thread costs 2 AD calls, not 200. const _busyState = new Map(); // sessionId -> { busy, timer } const BUSY_IDLE_MS = 2500;+// v1.9.86 — WHY THIS IS GATED, recorded precisely because the obvious reading is WRONG and would+// invite a future un-gate. desktop_taskbar is NOT unsupported on macOS: AD really calls+// NSApplication.requestUserAttention (Dock bounce) for flash and NSDockTile for badge text, and+// every arg shape returns success here. The blocker is the ADDRESSING MODEL, not the capability.+// macOS has no per-window taskbar button, so AD's mac path ignores titleContains/hwnd (it reports+// hwnd:0) and paints AD's OWN Dock tile. pup's use is inherently PER-SESSION-WINDOW — "which of+// these five pup windows is this thread driving" — so un-gating would badge Adom Desktop rather+// than the pup window, and every session would fight over one tile. AD also skips overlay.icon on+// mac outright (no Dock equivalent), which is what this call passes.+// So: capability real, semantics incompatible. Do not un-gate on learning "desktop_taskbar works+// on mac" — it does; it just cannot address what pup needs to address. The mac equivalent of this+// cue is browser_alert_window's toast-and-unhide path, which IS per-window. async function setSessionProgress(sessionId, busy) { if (process.platform !== 'win32') return; try {