Session wedges after navigating wiki.adom.inc/skills listing: all verbs time out

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

Closed bug report

John Lauer · 3mo ago ·closed by John Lauer

Repro, hit twice identically on AdomLapper 2026-07-26: (1) browser_open_window to any wiki.adom.inc page (renders fine). (2) browser_navigate that session to https://wiki.adom.inc/skills (the SECTION LISTING). (3) The next browser_eval times out, and from then on EVERY verb on that session (browser_eval, browser_list_tabs) returns status:timeout / 'Request timed out' (timeoutSeconds 10) indefinitely. A NEW session opened afterwards works, so the wedge is per-session/tab, not the bridge process. Individual page routes like /adom/adom-wiki-skillpack render and eval fine in the same setup; only the /skills listing triggers it. Verbatim failing response: {"durationMs":10002,"error":"Request timed out","ok":false,"status":"timeout","timeoutSeconds":10}.

1 Reply

John Lauer · 3mo ago

Cannot reproduce as of v1.9.221 — ran your exact repro and the session stayed healthy.

1. browser_open_window  → wiki.adom.inc/adom/adom-desktop-puppeteer-bridge   ok, eval fine
2. browser_navigate     → https://wiki.adom.inc/skills  (the section listing)  ok
3. browser_eval  x3     → 2, 2, 2      (issue says these time out forever)

Every verb the issue named as wedged now works on that session:

Verb	Result
`browser_eval`	`{url: "/skills", ready: "complete", links: 179}`
`browser_list_tabs`	1 tab
`browser_screenshot`	OK
6 rapid evals (the tight-loop pattern from #16)	6/6

Most likely what fixed it (none of it aimed at this issue specifically, which is why I'd rather you sanity-check than take my word):

v1.9.163 — the CDP flood fix. The console mirror wrote every page message synchronously to stdout and a requestfailed listener firehosed the shared CDP socket. A heavy listing page like /skills (179 links, React) is exactly the shape that saturated it, and once that socket was jammed every verb on the session timed out — which matches your symptom precisely, including that a new session worked while the old one stayed dead.
v1.9.172 — every per-window CDP read is now timeout-bounded, so one slow page can't hang a verb indefinitely.
v1.9.176/178 — crashed renderers are detected and auto-recovered instead of silently wedging the tab.

#26 and #27 are the same report filed twice, so closing both.

Reopen if you see it again — and if you do, browser_deps and the _degraded flag on browser_status will now tell us whether it's a jammed socket or something new.

John Lauer closed this · 3mo ago