[Windows][26.814.5517.0] In-app Browser page commands consistently stall for ~21 seconds, causing the 30-second Node REPL deadline to reset the control session

What version of the Codex App are you using (From “About Codex” dialog)?

26.814.5517.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Every in-app Browser operation that touches a page consistently takes about
21.4 seconds, including on https://example.com/. Browser metadata-only calls
such as browser.tabs.list() return in 2–4 ms, but navigation, DOM CUA,
Playwright DOM snapshots, and a minimal title evaluation all take 21.3–23.5
seconds.

The Node REPL execution tool has a default outer deadline of 30,000 ms. Two
sequential page-touching Browser operations therefore exceed that deadline. The
result is not a catchable Browser error; the entire JavaScript control session
is reset:

js execution timed out; kernel reset, rerun your request

All Browser bindings are then lost and must be initialized again. Browser tabs
may survive the reset.

Measured results:

| Operation | Page | Elapsed time |
| --- | --- | ---: |
| browser.tabs.list() | Browser metadata | 2–4 ms |
| goto() | example.com | 23,432 ms |
| goto() | OpenAI Help Center | 23,501 ms |
| dom_cua.get_visible_dom() | example.com | 21,381 ms |
| playwright.domSnapshot() | example.com | 21,381 ms |
| playwright.evaluate(() => document.title) | example.com | 21,377 ms |

Affected components observed:

• Codex desktop package: 26.814.5517.0
• Bundled Browser plugin: 26.814.41957
• Browser client SHA-256: 3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87
• Node REPL runtime bundle: 84464046935436b8

What steps can reproduce the bug?

1. Start Codex Desktop on Windows and open a fresh projectless task.
2. Initialize the bundled in-app Browser.
3. Open or navigate a controlled tab to https://example.com/.
4. Measure a metadata-only browser.tabs.list() call. It returns in a few

milliseconds.

1. In separate calls, measure any of the following against the controlled tab:

• playwright.evaluate(() => document.title)
• playwright.domSnapshot()
• dom_cua.get_visible_dom()

1. Observe that each page-touching operation takes approximately 21.4 seconds.
2. Run two page-touching operations sequentially in one JavaScript execution

using the default 30-second outer deadline.

1. Observe js execution timed out; kernel reset, rerun your request and loss

of all JavaScript Browser bindings.

The same latency reproduced on both:

• https://example.com/
• https://help.openai.com/en/articles/6614161-how-can-i-contact-support

This makes page complexity and the Help Center page itself unlikely to be the
cause.

What is the expected behavior?

• A minimal page operation on example.com should complete promptly rather

than waiting approximately 21 seconds.

• A Browser command timeout should reject as a bounded, catchable Browser error

before the outer Node REPL deadline.

• One or two Browser operation failures should not destroy the entire

JavaScript kernel or discard unrelated Browser bindings.

• Diagnostics should identify whether time was spent in debugger

synchronization, CDP dispatch, WebView scheduling, or response propagation.

Additional information

Read-only inspection of the installed desktop bundle found a 20,000 ms default
CDP command timeout:

fpe = 2e4
this.cdpCommandTimeoutMs = n.cdpCommandTimeoutMs ?? fpe

The page-command path also waits for pending debugger synchronization before
issuing the CDP operation:

await r?.waitForPendingDebuggerSync?.(n.browserTabId)

The remote Browser WebView path appears to retain Electron's default background
throttling; explicit disabling was found only for URLs classified as local:

ve(LL(se)) && (o.backgroundThrottling = false)

These snippets identify code paths worth checking; they do not by themselves
prove which one causes the fixed approximately 21-second delay.

A temporary local mitigation is to use an outer execution deadline of at least
60 seconds and allow at most one potentially page-touching Browser operation
per JavaScript tool call. Final verification under that rule completed a title
read in 21,400 ms and a Help Center DOM read in 21,378 ms without resetting the
kernel. This prevents the destructive reset but does not repair the underlying
latency.

During diagnosis, many node_repl.exe supervisors without child processes were
observed. Codex recreated 18 after an earlier set was stopped, so childlessness
is not sufficient evidence that they are leaked. This observation is included
only as an unconfirmed correlation and should not be treated as a proven process
leak.

Related reports:

• #35311 reproduced approximately 21.5-second navigation and deeper-control

timeouts on example.com in an older Windows build, but it is closed and its
primary report also covers a broader GPU/MSIX crash-remediation chain.

• #28290 reports intermittent Node REPL resets in the Chrome-extension download

path; the current report is deterministic, uses the in-app Browser, and
reproduces on a neutral public page.

• #30841 covered an approximately 30-second macOS Chrome-extension delay tied to

a local network-routing path; it is closed after that reporter's network fix.

No usernames, local filesystem paths, task IDs, authentication data, cookies,
or private page contents are included in this report.