[Windows Desktop] stale agent-browser CDP session leaves Codex turn in progress indefinitely

What version of the Codex App are you using?

Codex Desktop on Windows. The Microsoft Store package path recorded in the Windows event log during this incident was OpenAI.Codex_26.721.4979.0_x64.

What platform is your computer?

Windows 10 Pro 22H2, build 19045.6466, x64.

What issue are you seeing?

A Codex task can remain active for hours after an external agent-browser session loses its Chrome DevTools Protocol (CDP) response channel.

This was not only a slow page or a networkidle wait. The session daemon was still reported as active, but even simple read-only session commands failed with:

Auto-launch failed: CDP response channel closed

The Codex turn that invoked the browser sequence remained inProgress for roughly two hours instead of receiving a bounded tool failure and continuing or reporting the error.

The affected browser sequence was equivalent to:

agent-browser --session <redacted> open https://<redacted>
agent-browser --session <redacted> wait --load networkidle
agent-browser --session <redacted> snapshot -i -u

The target was an authenticated SPA/dashboard. networkidle is potentially unbounded for pages with persistent connections, but the important finding is that the stale session could no longer answer get url, tab, or snapshot after the failure. This is therefore not just a page-readiness problem.

Local diagnostics before cleanup:

• agent-browser doctor --offline --quick reported Session <redacted> (pid 8720) as an active daemon.
• agent-browser session list reported the same active session.
• A separate read-only call to agent-browser --session <redacted> get url failed with CDP response channel closed.
• The session had an associated headless Chrome process, while the Codex task still showed the tool operation as in progress.

Recovery was only possible by explicitly closing the stale session:

agent-browser --session <redacted> close

After that:

• agent-browser session list returned No active sessions.
• agent-browser doctor --offline --quick reported No active daemons.
• The associated agent-browser and headless Chrome processes exited.

What steps can reproduce the bug?

The exact trigger that disconnects the CDP response channel is not yet known, but the stale-session failure mode is reproducible enough to diagnose:

1. Run a Codex Desktop task on Windows that uses external agent-browser with a named session.
2. Navigate to an SPA/dashboard and wait using --load networkidle.
3. Let the CDP connection/session become invalid or the browser process disappear while the session daemon is retained.
4. Observe that Codex can keep the browser tool operation active instead of surfacing a recoverable error.
5. In another terminal, run agent-browser --session <same-session> get url or snapshot -i.
6. Observe CDP response channel closed.
7. Run agent-browser --session <same-session> close; the stale daemon and Chrome child process are removed and subsequent fresh sessions work.

What is the expected behavior?

When an agent-browser session has lost CDP connectivity, Codex should:

• fail the current tool call within a bounded timeout;
• expose the CDP response channel closed error to the agent;
• clean up the session and its browser process tree;
• allow at most a controlled fresh-session retry; and
• never keep the parent Codex turn active indefinitely.

Codex should also avoid using wait --load networkidle as a generic readiness check for SPAs with persistent connections. A DOM readiness, expected URL, text, or selector condition is safer.

Additional information

• External agent-browser version: 0.26.0.
• I did not include private URLs, session names, browser state, or project paths.
• Related but not identical: #34178 (orphaned agent-browser cleanup after task end) and #14755 (background agent-browser hang on blank pages).