[macOS Desktop] Interrupted in-app Browser call leaves task stuck and headless Chrome processes running

What version of the Codex App are you using?

• ChatGPT desktop app / Codex: 26.810.52044 (build 6662)
• Bundled Codex CLI: codex-cli 0.148.0-alpha.9
• Bundled Browser plugin cache: 26.810.52044

What platform is your computer?

• macOS 26.5.2 (25F84)
• Apple silicon / arm64

What issue are you seeing?

A Codex Desktop turn became stuck while trying to navigate the bundled in-app Browser to a local development page. Interrupting the turn did not reliably clean up the browser process tree or reset the task state.

The session had first opened a Playwright CLI browser for local visual validation, then switched to the bundled in-app Browser after the Playwright workflow encountered approval friction. The in-app Browser navigation call remained active for more than 100 seconds across repeated waits. After the user interrupted it:

• the Codex task continued to appear hung/spinning across follow-up messages;
• two separate headless Google Chrome roots remained running (one owned by the Playwright CLI daemon and one from the bundled Browser path);
• the user could not open normal Chrome until those process trees were manually terminated;
• a later attempt to terminate the reported running exec cell returned exec cell ... not found;
• a later attempt to stop a development-server session returned Unknown process id, despite the desktop UI still appearing busy.

This appears to combine a bounded-timeout problem with inconsistent cancellation/session bookkeeping and missing browser-process cleanup.

What steps can reproduce the bug?

1. Start a local web development server on 127.0.0.1.
2. In Codex Desktop, start a Playwright CLI browser session against the local page.
3. Without successfully closing that browser session, invoke the bundled Browser plugin through mcp__node_repl__js.
4. Create an in-app Browser tab and call goto for the local page.
5. If navigation stalls, wait for the tool call several times, then interrupt the turn from the desktop UI.
6. Observe that the turn/task can remain visually in progress and that headless Chrome processes may remain after interruption.
7. Attempt to open normal Google Chrome.
8. Inspect processes and observe multiple automated Chrome roots using temporary Playwright profiles and remote-debugging ports.
9. Manually send SIGTERM to the Playwright daemon, Chrome roots, helpers, renderers, and crash handlers.
10. Verify that Chrome opens normally and the automation processes are gone.

The exact localhost project and paths are intentionally omitted.

What is the expected behavior?

When a bundled Browser or Playwright-backed tool call is interrupted, times out, or loses its client:

• the tool call should fail within a bounded timeout;
• the parent Codex turn should leave the in-progress state;
• the browser session and complete Chrome process tree should be closed;
• the task UI and backend session registry should agree about whether a cell/session still exists;
• any surviving browser worker should be surfaced with a clear cleanup action;
• normal user Chrome should not be blocked by orphaned automation processes.

Additional information

There was no desktop-app crash. Manually terminating the identified browser process trees restored normal Chrome behavior.

No raw session logs are attached because they may contain private repository and prompt data. The affected session can be shared separately through the desktop app's /feedback flow if requested.

Related issues:

• #34178 — orphaned headless Chrome processes after browser visual assessment
• #35453 — stale browser/CDP session leaves a desktop turn in progress indefinitely
• #28352 — Playwright/Chrome workers remain after session close
• #32700 — system Chrome launched by a Codex browser automation path on macOS