[Codex App][Chrome] Timed-out DOM evaluation leaves Chrome at 160–176% CPU for several minutes

What version of the Codex App are you using?

Codex App 26.715.21425 (build 5488)

Bundled CLI/runtime: codex-cli 0.145.0-alpha.18

Bundled Chrome extension: 1.2.27221.15725

What subscription do you have?

Not provided.

What platform is your computer?

macOS 26.5.2 (build 25F84), Apple Silicon / arm64

Google Chrome: 150.0.7871.128

What issue are you seeing?

A read-only DOM evaluation through the bundled extension-backed Chrome browser control can time out and leave Chrome consuming very high CPU for several minutes.

The high CPU continues after the Codex browser session is finalized/released, then eventually recovers without restarting Chrome.

This is not ordinary idle CDP overhead. In the clean reproduction below, the Chrome main process stayed around 89–94% CPU, an extension process used roughly 35–42%, and two renderer processes used roughly 40% combined.

What steps can reproduce the bug?

1. Fully quit and relaunch Chrome.
2. Confirm the running Chrome executable, Framework, and Helper processes all use the same version.
3. Open a complex canvas-heavy SPA in regular Chrome.
4. Use Codex's bundled Chrome extension backend to claim the existing tab.
5. Leave the connection idle for 20 seconds.
6. Run this read-only DOM evaluation with a 10-second timeout:

await tab.playwright.evaluate(
  () => ({
    title: document.title,
    elementCount: document.getElementsByTagName("*").length,
    iframeCount: document.getElementsByTagName("iframe").length,
    canvasCount: document.getElementsByTagName("canvas").length,
  }),
  undefined,
  { timeoutMs: 10_000 }
);

1. The evaluation times out.
2. Finalize/release the Codex Chrome browser session.
3. Observe Chrome CPU usage for the next several minutes.

This path uses the extension-backed Chrome integration. Chrome was not launched with --remote-debugging-port or --remote-debugging-pipe.

Measurements

Each row is a 20-second sample unless noted otherwise. RSS is the sum reported for Chrome processes and is included only as a same-machine differential signal because shared pages may be counted more than once.

| Stage | Mean CPU | Median CPU | CPU range | Aggregate RSS | Process count |
|---|---:|---:|---:|---:|---:|
| Clean Chrome baseline | 12.9% | 0.8% | 0.1–134.9% | 6.61 GB | 40 |
| Chrome backend attached and idle | 27.8% | 11.7% | 5.3–162.0% | 6.47 GB | 39–40 |
| Immediately after DOM evaluation timeout | 159.3% | 163.3% | 110.9–172.5% | 8.01 GB | 43 |
| After browser session finalization | 176.6% | 173.6% | 142.6–245.8% | 7.61 GB | 41 |
| Following 30-second window | 166.9% | 173.4% | 109.9–180.5% | 7.61 GB | 40–41 |

CPU eventually returned to below 10% after waiting several minutes without restarting Chrome.

The issue was reproduced twice. Before the clean reproduction, Chrome had previously updated in place and had a mixed old/new runtime until restart. The second reproduction above was performed after a full Chrome restart, with all running Chrome components verified as 150.0.7871.128, so the pending-update state is not required to trigger it.

Expected behavior

If a read-only DOM evaluation times out, Codex should detach and clean up promptly. Chrome CPU should return near its pre-request baseline shortly after the timeout or after browser-session finalization.

Actual behavior

The timed-out request leaves the Chrome main process, an extension process, and renderer processes consuming roughly 160–176% aggregate CPU for several minutes. Finalizing the browser session does not immediately stop the high-CPU state.

Additional context

There are related reports involving browser workers or Chrome processes remaining active after Codex browser work, including #33319 and #28352, but I did not find an existing report with this specific sequence: successful extension-backed Chrome connection, read-only DOM evaluation timeout, sustained high CPU after finalization, and eventual delayed recovery.

---

Follow-up control and closure (2026-07-17)

A stricter control run did not reproduce the sustained high-CPU behavior:

| Stage | Samples | Mean CPU | CPU range |
|---|---:|---:|---:|
| Chrome at rest before the controlled tab | 30 s | 0.3% | 0.0–2.7% |
| Extension-backed Chrome attached to the only controlled about:blank tab | 30 s | 1.2% | 0.5–5.3% |
| Intentionally timed-out, non-CPU-consuming Runtime.evaluate window | 35 s | 1.0% | 0.4–2.1% |
| After finalizing and closing the controlled tab | 90 s | 0.1% | 0.0–2.4% |

The controlled evaluation timed out as expected, but Chrome returned to idle immediately and no delayed spike appeared during the 90-second observation window.

A separate observation also found an ordinary page renderer reaching 20–106% CPU without an active Codex Chrome backend or an explicit CDP action. This means the original report overstates causality: the earlier measurements show a temporal association, but do not isolate Codex or the evaluation timeout as the root cause.

Closing this report as inconclusive / not planned. It can be reopened if the sustained behavior is reproduced with a controlled page and a clean no-Codex comparison.