Session wedges after navigating wiki.adom.inc/skills: 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, both times identical): browser_open_window to any wiki.adom.inc page, then browser_navigate the session to https://wiki.adom.inc/skills (the section LISTING). The next browser_eval times out, and afterwards EVERY verb on that session (browser_eval, browser_list_tabs) returns {"status":"timeout","error":"Request timed out","timeoutSeconds":10} indefinitely. Other sessions opened later work fine, so it is the session/tab that wedges, not the bridge process. Verbatim failure: {"_hint": "status:timeout - the desktop didn't respond in time...", "durationMs": 10002, "error": "Request timed out", "ok": false, "status": "timeout", "timeoutSeconds": 10}. Individual page routes (/adom/) render fine in the same setup; only the /skills listing triggers it. Bridge version: whatever shipped with AD 1.9.191-era on AdomLapper, 2026-07-26.

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