app

Pup - Puppeteer Bridge

Public Made by Adom

by adom

pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.

skillspuppuppeteerbrowseradom-bridgebridgepup-bridge
Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity
Closed general

pup-assist caption refresh loop keeps a 2s caption on screen indefinitely - needs backoff + real thread attribution

John Lauer · 7d ago ·closed by John Lauer

Observed live on John's desktop 2026-08-03 ~11:58, reconstructed from AD's day-scale command log (AD 1.9.216).

What happened

While a session waited for the user to focus its window, pup re-issued the SAME caption every ~4 seconds, indefinitely:

desktop_caption {id:"pup-assist", duration:2000, persist:false, position:bottom} text: "Adom is waiting: click back into THIS window when you are ready, and I will continue. (Nothing happens until you do.)" caller: thread "pup bridge (self)" (via pup)

AD's caption contract deliberately lets a same-id re-issue replace and reset the timer (so legit progress captions can update), so each 2s caption was individually compliant - but the loop turned it into a permanent on-screen nag. John's words: "an ad caption is disturbing my work." This is the second caption-disturbance report from him; the first led to AD growing day-scale logs specifically to attribute these.

Asks

  1. Backoff, not a keep-alive loop. A wait-for-focus assist should show the caption a couple of times and then STOP (or re-show only on a state change, e.g. the target window surfacing again). Compare AD's own close-to-tray toast: 3 reminders ever, then silence. If you want a persistent indicator, that is what persist:true is for - but a persistent "I am waiting" nag on the user's screen for minutes is exactly the disturbance the TTL model exists to prevent, and an unattended wait can be hours.
  2. Attribute the real thread. The refresh loop reported aiThread "pup bridge (self)". The wait is on BEHALF of a user thread (in this incident, a gallia thread named "LinkedIn" which later issued the clear). Per the AD delegation-chain contract (X-Adom-Caller-Delegate, AD 1.9.183), a caption shown while waiting for a specific thread's interaction should carry that thread as the caller with pup as delegatedBy - so the user's Activity Log answers "who is nagging me" directly.
  3. Consider honoring the user's existing fgCaption settings (fgCaptionMs, on/off) for this assist too, if it does not already.

AD-side note: we are deliberately NOT rate-limiting same-id refreshes in AD core for now (legit HUD-style captions update frequently); if bridges keep looping, that may change.

1 Reply

John Lauer · 4d ago

Fixed in 1.9.335. The wait-for-focus assist (waitForUserReady) now backs off: it shows the "Adom is waiting" caption at most 3 times then goes silent, gated on the user's fgCaption setting and honoring fgCaptionMs. No more permanent on-screen nag on an unattended (possibly hours-long) wait. The call site still shows an initial notify_user toast + caption, so fgCaption:off never leaves the user unaware.

Follow-up (ask #2, real-thread attribution): pupCaption still emits with no caller, so the caption reads as "pup bridge (self)" rather than " (via pup)". That's a small mechanical change (thread sessionCaller(...) into the desktop_caption call) tracked for a later pass.

Log in to reply.