Lane died mid-session: pup_click/pup_eval time out (13-25 s) while screenshot/open still work; reopen does not recover

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 · 21d ago

What happens

pup 2.0.727 (Rust shell), Chrome for Testing 152.0.7977.82, Windows 11, 4K, driven from a WSL container through adom-bridge. 2026-10-20, about 14:30 to 14:40 local.

A pup window that had worked all day for pup_eval and pup_click on a local dashboard (a Babylon 3D page) stopped answering input and script, while window, navigation and screenshot verbs kept working:

pup_eval -> the pup extension did not answer within 25s
pup_click {selector} -> Runtime.evaluate failed: 0 the pup extension did not answer within 13s
After pup_close_window and pup_open_window with a new sessionId, the page loaded and rendered (screenshots show it), but the first pup_click -> Input.dispatchMouseEvent failed: 0 the pup extension did not answer within 13s
Before that, the old session answered pup_navigate and pup_open_window with errorCode: browser_gone ("the extension-driven browser behind this window is not running", hint "pup_close_window then pup_open_window"). The close and reopen worked, but input did not come back.
pup_screenshot, pup_open_window and pup_close_window kept working throughout.

Afterwards pup_readiness reports orphanedBrowser with 24 Chrome PIDs on the adom-you profile and "no live lane owns it (left over from a pup restart)". So the lane that took input had probably died while the browser stayed up, and the replacement window did not get a working lane.

Related, but not the same: #129 (the tab stays on birth.html; here the page did load) and #121 (an orphaned lane browser holding the profile lock).

What would help

When the lane is gone, pup_click and pup_eval should fail fast with browser_gone (or say that the lane is orphaned) and a hint that works, instead of a 13 to 25 s timeout.
pup_open_window should not report OK on a window whose input lane cannot answer, or it should reclaim the orphaned browser first (readiness says the next open would, but it did not here).

Found by a Claude Opus 5.5 thread on 2026-10-20. The work finished without pup (the check was done through the page's server), so this is not blocking.

1 Reply

John Lauer · 21d ago

Where this stands (2026-10-20).

What the symptoms say. orphanedBrowser in pup_readiness means the extension had not polled pup for 20 s while its browser kept running. Every verb that goes through the extension timed out: pup_eval, pup_click, and both of their DevTools paths. Screenshots kept working because they don't depend on that poll. So the extension's background worker stopped talking to pup, or a command it was running never came back.

What I ruled out.

The worker's poll loop gives every step a deadline (50 s per step, 12 s per fetch, 20 to 45 s per command), and a 30 s alarm restarts it. A single hung Chrome call cannot keep it silent for long.
This is not the 2.0.723 bug, where closing an isolated window wiped the main lane's record. That fix is in 2.0.727, which you were on.

Two candidates left.

The page's own main thread was saturated. A Babylon 3D dashboard rendering continuously can do this. Runtime.evaluate and Input.dispatchMouseEvent wait for the page's main thread; screenshots come from the compositor. A reopened window on the same page would hit the same wall, which matches "the page rendered but the first click timed out".
The worker was ended or hung in a way the alarm did not recover. The browser_gone answers fit this one.

What I need to pin it down: the box name, and pup's log around the incident. The evidence on ConfRoomROG rotated away with today's installs. Next time it happens:

run pup_status and save its extensionLane block (lastPollMsAgo, workerVersion)
run pup_devtools {method:"Runtime.evaluate", params:{expression:"1"}} on the stuck window. If this answers, the worker is alive and the page is the problem.
note the time, so the matching lines in %USERPROFILE%\.adom\pup-log\pup.log can be found

Since 2.0.727, pup_devtools exists for exactly this check. Leaving this open until it reproduces with logs.