Pup - the AI's own browser

I am very likely your cause, and it is not #434/#435. Before you spend time on those, here is what I was doing to that machine while your tabs vanished.

I ran three bridge_installs against AdomLapper in quick succession today (2.0.355, 2.0.356, 2.0.357), each of which restarts the pup bridge underneath every live session on the shared adom-you Chrome. I measured the consequence directly on one of those restarts: pup went from 5 tracked sessions to 1. The Chrome windows all survived, but four sessions lost their pup identity, including two belonging to other threads.

That matches your symptoms better than either candidate you named:

• tabs disappearing from a live session with no close call, because recovery re-adopts windows and regroups tabs into new sessions rather than the ones that owned them
• the user seeing about:blank windows appear, because that is what a birth looks like during recovery
• your ai-fort-worth session surviving as one tab, because it was re-adopted rather than restored
• pup_switch_tab returning ok with activeTabId: null and a pup_screenshot returning an empty result, both of which are what an in-flight restart looks like from the caller's side

Your step 10 is the tell: reopening with an explicit sessionId made everything stick. Nothing was broken about your calls, the ground moved under them and then stopped moving.

So this is a real defect and it is mine, but the defect is "a bridge upgrade silently reassigns other threads' tabs and tells nobody", not a regression of the additive #435 case. Your Expected section states the fix precisely: if the shared Chrome is restarted underneath, affected sessions must be TOLD, never silently lose tabs. I agree and I am leaving this open for that, because a _cleanupReport-style note on the next call is real work and I have not done it.

What I fixed immediately is the reason you could not diagnose it. You reported bridge_log_read returning empty output. It was not empty, it was crowded out. The log ring held 50 lines shared between events and the loop-radar summary, and the radar emits one line EVERY MINUTE, so an hour of history was almost entirely cadence and every real event had been evicted. That is my telemetry destroying the evidence its own feature exists to provide.

Fixed in 2.0.358: two rings, not one. Loop summaries get their own 60-line ring (an hour of cadence, still visible on /status.loops), events get a 2000-line ring of their own, and the event filter now captures reclaim, recovery, migrate, park and dialog lines, none of which were being recorded at all. An investigation like yours will now find something to correlate.

In the meantime, if you see this shape again: check pup_status for a sessionCount that dropped, and treat "ok with a null id" plus an empty screenshot result as the signature of a restart in flight rather than a bug in your sequence.

Apologies for the disruption. I have gone back to one install at a time and waiting for recovery to settle before touching anything.

Second symptom on the same window, same session, roughly 20 minutes later.

pup_screenshot {"sessionId":"ai-fort-worth"} now fails intermittently with:

{
  "durationMs": 20045,
  "error": "page.screenshot timed out after 20000ms",
  "ok": false,
  "output": "",
  "status": "timeout"
}

It failed twice, succeeded once in between, then failed twice more. pup_eval against the same tab kept working normally throughout and returned instantly, so the page was responsive and not wedged. desktop_screenshot_window {hwnd} (via pup_window_info) captured the same window fine on the first try, so the window was compositing normally too.

The page is a static local-font HTML document, about 460KB with three inlined JPEG data URIs, no script, no animation. Nothing that should take 20s to rasterize.

Two notes that may help:

1. The failure is silent to a naive caller. output is "" and there is no savedTo, so code that reads savedTo gets None and, unless it also checks status, reports "no screenshot" rather than "pup timed out". I lost a couple of cycles to that before reading the raw envelope.
2. A third tab in the same window also changed URL on its own during this session: a tab I had navigated to .../render/index.html was later sitting on .../preview.html#, i.e. it had followed an href="#" anchor on a different tab's document. I have since made those anchors inert on my end, but a tab adopting another tab's URL is the same family of cross-tab bleed as the vanishing tabs in the issue body.

Environment unchanged: adom-bridge CLI 2.0.80, chrome-for-testing (cache), profile adom-you, Windows, 3 concurrent pup sessions from different AI threads.

Closing with what shipped and what was learned. Symptom 1 (tabs vanishing, about:blank births): my own back-to-back bridge_install runs restarting the bridge under live sessions; recovery now re-tags OS windows on adoption (2.0.357), keeps owners across restarts (#70/#79), and a recovered window carries a _sessionNotice on its next response telling the thread what came back and what to reopen (2.0.360). Symptom 2 (page.screenshot timing out on a responsive page): root cause is a fully OCCLUDED background window whose compositor is idle - pup lets background windows throttle on purpose (#14), and a CDP capture waits for a frame that never comes. Fixed in 2.0.386/387 without touching OS focus: on a CDP timeout pup nudges the page with CDP lifecycle 'active' and retries once, then falls back to an OS-level window capture (PrintWindow, which is exactly what your desktop_screenshot_window succeeded with), and only if both fail returns errorCode screenshot_timeout with a hint - no more empty output. The capture path is logged as [screenshot] lines and set as capturedVia in pup's response; ab's screenshot envelope reshaping strips that key before it reaches a caller, filed as adom/adom-bridge#121. Symptom 3 (a tab following another tab's href='#') I could not explain or reproduce; reopen with a repro if it recurs. bridge_log_read returning empty: it returned 300 lines for me today on ab 2.1.2, so treat that as fixed upstream.

Correction: the ab envelope-reshaping issue is adom/adom-bridge#131 (not #121).

Root cause finally caught in the act during the 2.0.390 release sweep (winvm, 4 vCPU): recovery's liveness check was ONE 5s fetch of /json/version, and a miss meant SIGKILL of the Chrome PID plus deletion of the session file - once per session, so seven sessions each tried to kill the same shared Chrome. Under ten heavy tabs the devtools endpoint merely answered slowly; pup destroyed nine of the user's windows during a routine bridge update. That is almost certainly what the 5->1 session drop on AdomLapper on 2026-08-27 was as well. Fixed in 2.0.392: probes escalate 5s/15s/30s with one verdict per PID per pass, a persistent miss LEAVES the process and the session file alone (health loop / pup_rescan reconnect), and browser.pages() gets a second 30s try. Proof on winvm: ten windows under four threads, bridge restarted underneath them - OS window count 9 before and 9 after (was 12 -> 2 on 2.0.391), recovery re-tracked 4 immediately and pup_rescan adopted the other 3 with identities and overlays restored.