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

[Bl0ck154]

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: Codex Desktop leaves orphaned agent-browser headless Chrome processes consuming ~400% CPU #34178 (orphaned agent-browser cleanup after task end) and Codex hangs on agent-browser background sessions for websites with blank pages #14755 (background agent-browser hang on blank pages).

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Windows Desktop: shell tool timeout does not release agent when a headless Chrome child survives #35193

Powered by Codex Action

[Bl0ck154]

Consolidated Windows reproduction update

Scope

This is reproducible across independent Codex Desktop tasks on Windows. It is not specific to one project, Etsy, Chrome, TLS, SPA behavior, or networkidle.

Browser/CDP manifestation

Two separate agents launched fresh agent-browser QA sessions with unique names. agent-browser doctor --offline --quick reported healthy daemons (PID/socket present; 0 failures), but a read-only agent-browser --session <name> get url immediately failed with Auto-launch failed: CDP response channel closed. Closing the affected session released the corresponding Codex tool call as failed. New session names did not reliably recover.

Updating agent-browser from 0.26.0 to 0.33.0 did not remove the failure: a new diagnostic session running only agent-browser --session codex-cdp-probe-20260726 open about:blank did not return within 11 seconds and had to be terminated.

Non-browser reproduction

The same turn-hang occurred with no Chrome or agent-browser involved. A PowerShell shell tool started a local Node server through System.Diagnostics.ProcessStartInfo, waited 2 seconds, then called curl.exe --max-time 4 against http://127.0.0.1:4321/. The request returned HTTP 200, yet the Codex turn remained in progress. The Node child was still listening on that port; terminating only that exact listener immediately released the stuck shell tool, which Codex then marked completed.

Expected behavior

A shell tool must return control at its declared timeout or once its launcher exits, even when a long-lived descendant survives. Codex should report the timeout/failure, clean up its owned process tree, and keep the agent steerable. doctor should distinguish a live PID/socket from a usable CDP connection.

This appears consistent with #35193: a broader Windows shell child-process lifecycle/ownership bug, with agent-browser as one visible manifestation.