Windows: Connected Chrome tab enumeration fails with request-header policy error after ~20 seconds #50847

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

26.930.31730

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Connected Chrome in the Windows Codex desktop app can discover the Chrome extension provider and my target profile, but cannot retrieve actual tab data. Ordinary text conversations complete normally with TUN disabled.

The most recent browser-read failure occurred during a controlled diagnostic experiment, before its verified rollback:

Error: Unable to load browser request-header policy. Retry the browser command.

Elapsed time: 20,019 ms.
Tool completion time: 2026-10-04 18:36:04.723, UTC+08:00.

An earlier native invocation also failed:
mcp__cua_repl.js -> cua.getState()

That response discovered Chrome (type=extension, browser ID 3), but its built-in tab enumeration returned:

Browser 3: Error: nodeRepl.fetch request failed
Error: nodeRepl.fetch request failed

The entire getState() call took 23.4066 seconds. The internal tab-RPC duration was not separately exposed. No actual tab count was obtained; tabs: [] in an errored response must not be interpreted as a verified zero-tab result.

These failures occurred during native browser state/tab access, without navigating to any website. This is not a TikTok-specific page-loading issue.

The failing request URL, HTTP status, underlying connection error, actual proxy route, and root cause remain unknown.

What steps can reproduce the bug?

Feedback ID: 01a1062f-0798-7230-8291-3a1f254d2eab

What is the expected behavior?

When the required connection, authentication, and policy checks succeed, native Connected Chrome should return actual tab data.

If request-header policy loading fails, the app should provide an actionable, sanitized error and a supported diagnostic method to identify the failing request and underlying cause.

An unsuccessful read should not be presented as a successful zero-tab result.

Authentication, TLS verification, and browser policy enforcement should remain enabled.

Additional information

Network and environment findings:

• The local HTTP proxy is listening on 127.0.0.1:1081.
• Windows system proxy is enabled and points to that address.
• TUN is currently disabled.
• User-level NODE_USE_ENV_PROXY=1, HTTP_PROXY=http://127.0.0.1:1081, and HTTPS_PROXY=http://127.0.0.1:1081 remain configured.
• Before the controlled experiment, the Codex app-server had those variables, but the actual CUA/native host processes did not.
• No temporary proxy values remain in the audited config.toml section or active generated CUA MCP configuration.

Controlled experiment and rollback:

A temporary, single-file change to the actual cua-repl.mjs entry point passed the proxy variables, plus NO_PROXY=localhost,127.0.0.1,::1, to subsequently launched processes.

After a cold restart, both the patched entry point and the specified environment variables in the actual native node_repl.exe process were verified. The browser read still failed with the request-header policy error.

This proves that environment injection alone was insufficient in this experiment. It does NOT establish whether the failing request actually used the proxy.

The single-file patch has now been fully removed:
ROLLBACK: VERIFIED.

The restored entry point matches the original SHA-256. Post-restart checks also confirmed the original runtime path and unchanged launch.js, node.exe, and node_repl.exe hashes. Ordinary text chat works. Browser access was not retested after rollback.

Runtime evidence from the inspected installation:

• Runtime manifest: 0.0.27/20260927214556-b77d38801cca
• node.exe PE version: 24.21.0
• @oai/cua-repl package metadata version: 0.1.0
  These are runtime/package identifiers, not the Codex desktop app version.

Request for assistance:

Please provide a supported diagnostic procedure for the current Windows App-managed CUA runtime to identify the failing policy/authenticated-fetch request, HTTP status or underlying error chain, timeout stage, and actual proxy route.

Please also clarify the supported proxy configuration for these requests.

Sanitized invocation records, experiment records, and verified rollback evidence are available. No authentication, TLS, or policy checks were disabled.