Repository navigation
[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 #39766
Description
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?
- Start Codex Desktop on Windows and open a fresh projectless task.
- Initialize the bundled in-app Browser.
- Open or navigate a controlled tab to
https://example.com/. - Measure a metadata-only
browser.tabs.list()call. It returns in a few
milliseconds. - In separate calls, measure any of the following against the controlled tab:
playwright.evaluate(() => document.title)playwright.domSnapshot()dom_cua.get_visible_dom()
- Observe that each page-touching operation takes approximately 21.4 seconds.
- Run two page-touching operations sequentially in one JavaScript execution
using the default 30-second outer deadline. - Observe
js execution timed out; kernel reset, rerun your requestand 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.comshould 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 ?? fpeThe 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:
- [Windows][26.721.4979.0] In-app Browser incident during Microsoft Store update-log lookup: startup crash loop, package remediation, and persistent deep-control timeouts #35311 reproduced approximately 21.5-second navigation and deeper-control
timeouts onexample.comin an older Windows build, but it is closed and its
primary report also covers a broader GPU/MSIX crash-remediation chain. - Intermittent Chrome plugin Node REPL kernel reset after successful setup and page control #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. - Chrome extension deep control hangs while direct chrome.debugger works; ambient network adds ~30s delay #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.
Activity
github-actions commentedon Aug 20, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xiaoliang-source commentedon Aug 24, 2026
I found a reproducible Windows workaround for this fixed ~21 s delay.
What was happening
The affected machine already had a working local HTTP(S) proxy, and ordinary browser traffic was fast. However, the bundled browser-control child did not receive the existing proxy-related environment variables. Both Chrome control and the in-app Browser showed the same pattern:
Read-only inspection of the current bundled browser service shows that remote-origin page actions perform an auxiliary privileged network status check before the page operation, while localhost origins are skipped. This matches the local-vs-remote split, but the app did not expose the HTTP status/error for that request, so this is a high-confidence diagnostic path rather than proof of one specific server-side failure.
Minimal workaround
Prerequisites:
NODE_USE_ENV_PROXY=1,HTTP_PROXY, andHTTPS_PROXYare already present there.Add this to a trusted project's
.codex/config.toml:Then completely quit and reopen Codex Desktop. This only forwards existing environment variables to the bundled browser-control child; it does not put proxy URLs or credentials in the project file.
Verified result after restart
Using fresh tabs against
https://example.com/:For both surfaces, the test clicked “Learn More”, reached
https://www.iana.org/help/example-domains, and verified the changed URL, title, and DOM. The previous fixed ~21.4 s tail disappeared.Notes
LLjpcz commentedon Oct 15, 2026
Additional evidence from Windows desktop tests (Windows-native agent) on 2026-10-14: the roughly 21-second command overhead also compounds during supported, registered file downloads. With an outer deadline long enough for the supported flow to finish, the downloads completed, and the latency remained.
Measurements
Instrumented API invocation-to-Promise-completion times, not physical click timestamps or isolated network transfer times.
Timed out after 1000ms waiting for download.download.path({timeoutMs: 15000})after a successful downloadGUI clicks stayed slow, so the targeting method did not remove the delay. In the neutral 3-second control both promises were created at about 1 ms and no download was requested, so that control measures command overhead. The helper registers
waitForEvent('download', {timeoutMs: 120000})before the click, then waits for both promises. Success was checked against a pre-download inventory and the files were confirmed as PDFs. The user reports a manual download of the same files completed in about 5–10 seconds; that duration was not instrumented.Timeout scope and the 21-second connect timeout
Read-only source excerpts from 2026-10-14 show that the download timer does not cover the whole command: setup runs before
waitForDownload, some permission-check time is excluded, and cleanup is awaited afterwards. Same-tab commands can wait for the download-setup handshake, so a 120-second inner timeout is not an end-to-end deadline. The inspected download path has no explicit 21-second timer.On 2026-10-15, on a network where chatgpt.com is reachable only through an already configured Windows system proxy, a direct TCP connection to
chatgpt.com:443timed out in 21.047 s. A direct connection to a separate unreachable address also timed out in 21.047 s, so that figure is this machine's OS connect-failure timeout. A read-only inspection the same day of desktop package26.1007.9446.0shows a remote site-status preflight (chatgpt.com/backend-api/aura/site_status) in the command/origin checks, with local origins handled differently. In that implementation a failed fetch does not create the successful cached result that would let later checks return promptly.The 1-second no-download control (observed 22.338 s) lines up with one OS connect timeout plus the configured wait. Together with the preflight above, and with the proxy-inheritance report already in this issue, this strongly indicates that the browser-side preflight is not using the configured proxy, so each remote command waits out one OS connect timeout. Download totals are longer because several commands run in sequence; an exact call count is not inferred from those totals. The browser child's actual request has not been captured. The exact package version for the 2026-10-14 timings was not independently captured; the static inspection used
26.1007.9446.0. #42454 is the related report on generatedcua_replconfiguration.Could maintainers verify whether that preflight runs in the browser child and whether the child inherits the Windows system proxy, including generated
cua_replconfiguration? Stage timing for the preflight, policy checks, download registration, input dispatch, file arrival, and cleanup would show which stage accounts for the repeated ~21 s. No policy checks, generated runtime code, proxy configuration, or download transport were modified for these tests.