pup orphans all its windows on bridge restart: list=0 while live CfT windows persist with a bare Chrome taskbar button, no re-adoption path

by 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.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Open bug report

John Lauer · 9d ago

Symptom (John, AdomLapper, 2026-11-01)

pup windows keep showing the bare Chrome taskbar button (no thread tile, no AI-thread name), stuck offscreen, not clickable to the foreground. John hates it and sees it often lately.

Root cause: pup orphaned ALL its windows while they stayed alive

On AdomLapper (pup 2.0.738):

pup_list_windows returns 0, but the OS has three live pup Chrome-for-Testing windows on the adom-you profile (confirmed by process: --user-data-dir=...\pup-profiles\adom-you, CfT exe):
- "Can Gemini 4 Argon Design a PCB? - YouTube" (maximized, visible)
- "Setup stopped at Setup didn't finish - Adom Hydrogen" (maximized, visible)
- "Adom Investor Deck" (blank shell parked at -32000; I closed this one)
pup_rescan answers All known sessions are live: []. It only checks lanes pup already knows; it does not discover or re-adopt stray OS windows.

So pup lost its entire in-memory lane registry (most likely on the bridge restart when 2.0.738 installed) and has no path to re-adopt the windows that survived. An orphaned window gets no identity stamp (hence the bare Chrome button) and is drivable/foregroundable by nobody.

Why re-adoption fails

pup binds a window by its birth title PUPBIRTH-<token>. Once the page navigates, that title is gone. When the lane mapping is also lost (restart), there is no durable marker left on the window to map it back to a lane/owner. adopt_stray_windows can't catch these because nothing on the live window says which lane/thread it was.

Proposed fix

Durable per-window identity that survives navigation and a bridge restart. The extension stamps a hidden marker (e.g. a window.name / storage key) carrying {lane, owner, bornAt}, and/or pup persists a lane registry keyed by the CfT window id + profile to disk and re-reads it on startup.
Active re-adoption on startup and in the health tick. Enumerate pup-profile CfT windows; any not in a lane gets re-adopted, its taskbar identity re-stamped (thread tile with the AI-thread name recovered from the marker). If the owner is truly unknown, assign a generic pup identity, never a bare Chrome button (ties into #70).
Never leave a pup window unreachable. On adoption, a window parked offscreen with no monitor under it is pulled into the work area so the user can always reach it.

Secondary finding (different culprit, same user pain)

An earlier offscreen "Adom Investor Deck" window John screenshotted was not pup at all: it was plain Google Chrome launched with a temp debug profile (--user-data-dir=...\Temp\deck-share-test8, remote-debugging) by some automation/test, left offscreen with no identity. It has since closed. That is a different thread's litter, but it shows the same bad shape (an AI-opened browser window with a stock icon and no identity), so whatever ran that deck-share test should identify and clean up its windows too (built-in desktop_set_window_identity exists for non-pup windows).

1 Reply

John Lauer · 9d ago

Correction after reading the live state: it recovers, the bug is the GAP

I over-called the first diagnosis. Watching AdomLapper longer, pup self-healed: it re-adopted all three windows with their real owners recovered from the persisted session files (hydrogen-ship, Linux-test-box, SAFE-financing), the control channel came back (extensionLane.connected:true, worker 2.0.738, 3 sessions, 3 windows), and the icon audit reported all three correctly stamped. So owners DO persist and re-adoption DOES work. "Stuck forever, no re-adoption path" was wrong.

The real defect is the recovery GAP. For the window between a bridge restart (or a worker-reload cycle, or a crash-restore) and the moment adopt_stray_windows + the identity stamp catch up, a pup-profile Chrome-for-Testing window exists with no session, so:

its taskbar button wears the bare Chrome icon (no thread tile, no AI-thread name), and
pup_list_windows is empty, so no thread can drive or foreground it.

It lasts seconds to minutes and then heals. The reason John sees it "a lot lately": every insiders bridge update triggers a worker-reload cycle on his laptop, so the gap recurs on each ship.

The fix (scoped to the gap, away from the lane/kill minefield)

A health-tick "never a bare Chrome button" safety net: enumerate pup-profile CfT windows; any one whose Windows AUMID is not already Adom.Pup* gets a pup identity stamped immediately, independent of full session re-adoption. If the hwnd matches a live session, stamp its real thread tile; otherwise stamp a generic grouped Adom Pup identity with the window title, which upgrades to the real thread tile once adopt_stray_windows re-adopts it a few seconds later. Strictly filtered to CfT windows on pup profiles (never the user's own Chrome, never a non-pup debug Chrome), and it only reads + stamps, so it never touches the kill/lane paths that caused the 2.0.723 and 2.0.646 regressions.

This guarantees John's actual requirement: no pup window ever wears a bare Chrome taskbar button, even mid-recovery.

Separate: the non-pup debug-Chrome litter (not this bug)

The offscreen window John first screenshotted was plain Google Chrome on a throwaway deck-share-test8 debug profile, launched by some other automation and abandoned offscreen. It is not pup and will never carry pup identity. Whoever runs that deck-share test should identify and clean up its windows (desktop_set_window_identity exists for exactly that). Tracking that separately, not here.