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 bug report

Wiki sign-in races first paint in pup windows: some windows render signed-out, others signed-in, all actually authenticated - make session injection deterministic

John Lauer · 1d ago ·closed by John Lauer

Wiki login state is inconsistent across pup windows at first paint: some threads' windows render signed-in, a just-opened one renders signed-out, yet visiting the pages they are ALL signed in. Observed by John across fusion/kicad/nb threads' windows, 2026-08-09.

Facts observed on one desktop (AdomLapper), same wiki (wiki.adom.inc), three AI threads' pup windows:

  • A fusion-thread pup window, just opened, rendered the wiki header signed OUT.
  • kicad and nb thread pup windows rendered signed IN (as John).
  • When John then looked at the actual pages, ALL of them were signed in.
  • The taskbar hover thumbnails preserve whatever the FIRST PAINT was, so the stale signed-out frame keeps being shown on hover even after the live page has authenticated - which is what makes the inconsistency so visible.

Also notable: a brand-new pup profile ("nb-show", first ever use) rendered wiki.adom.inc signed in as John on first load - so pup profiles are NOT actually cold for *.adom.inc. Something injects or exchanges John's Adom session (ab-side cookie injection? wiki device/session trust?), and it appears to be ASYNC relative to the first navigation: windows that win the race paint signed-in, windows that lose it paint signed-out and silently fix themselves on the next render.

The doctrine says "cold profiles = LOGGED OUT by design", so either the doctrine or the behavior is wrong - and the race makes it LOOK nondeterministic, which reads as broken to the user.

Asks:

  1. Make it deterministic: if adom-session injection into pup profiles is intentional, complete it BEFORE the first navigation resolves (or delay first paint), so a wiki page never renders a signed-out header that is about to be wrong.
  2. Document it: the pup skill/doctrine should say exactly which origins get session injection and when - "cold by design" is currently false for *.adom.inc.
  3. If it is NOT intentional for all profiles, scope it: which profiles get it and why did a fusion-thread window miss it while kicad/nb got it.

1 Reply

John Lauer · 1d ago

Fixed in pup 2.0.29, verified live on ADOMLAPPER. Root cause: auto-sign from the desktop wiki token only ran when wikiView:"authed" was EXPLICITLY passed, so the common omitted-view case (the shared adom-you profile, meant to be signed in) never auto-signed and a fresh window whose shared cookie had not landed painted signed-out while siblings showed signed-in. Fix: auto-sign now covers ANY adom URL that is not the deliberately-anonymous public/isolated view; it fires only on a definite 401 (never a probe timeout, so an already-signed-in window is not re-navigated) and schedules an overlay repaint so the taskbar hover thumbnail drops the cached signed-out frame. Test: fresh window, wikiView omitted, /auth/me on the page returns SIGNED-IN:John Lauer at first look; open hint reports 'auto-signed'.

Log in to reply.