[Windows][Desktop] Browser tab RPCs block on unbounded request-header identity lookup

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

Codex Desktop 26.903.9818.0

What subscription do you have?

ChatGPT subscription (exact tier not relevant to the reproduction and not verified for this report).

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Additional tested components:

• @oai/browser-desktop 0.1.1
• bundled Node.js v24.20.0
• Microsoft Edge 152.0.4191.66
• ChatGPT browser extension 1.26.901.11451

What issue are you seeing?

Codex Desktop discovers the Edge extension-backed browser, but tab-level RPC calls such as openTabs() wait approximately 21 seconds and then fail with:

nodeRepl.fetch request failed

The extension installation, native host, and tab itself are not the failing boundary. During instrumentation:

• browser/provider discovery succeeds;
• getInfo reaches the extension;
• the native host is running;
• openTabs and related tab RPCs do not reach extension dispatch before the timeout.

The bundled browser service blocks before its send/request path while waiting for the caller-identity promise used by the optional request-header policy. The identity comes from:

https://chatgpt.com/backend-api/aura/identity

The vulnerable minified function in this build waits for that promise without a timeout before reading codex_browser_use_agent_request_header. If identity never settles, unrelated browser RPCs are held until the outer transport surfaces the opaque fetch error.

This is more specific than the same outward symptom reported in #44390, #44697, #44500, #44135, and #43787: this report includes a reproduced blocking dependency, a bounded workaround, and before/after measurements.

What steps can reproduce the bug?

1. Run Codex Desktop 26.903.9818.0 on Windows.
2. Enable the official ChatGPT browser extension in Edge.
3. Verify that Codex discovers Edge as an extension-backed browser.
4. In a fresh local task, select Edge and call browser.user.openTabs() or an equivalent tab-list operation.
5. Observe that the call waits roughly 21 seconds and fails with nodeRepl.fetch request failed.
6. Instrument the bundled browser service and observe that the call is blocked while resolving the agent request-header policy, before the browser RPC is sent to the extension.

A local, reversible workaround was validated by making the policy lookup bounded:

let requestHeaderPolicyPromise;

async function shouldUseAgentRequestHeader() {
  return requestHeaderPolicyPromise ??= (async () => {
    if (callerIdentityPromise == null) return false;

    try {
      return await Promise.race([
        callerIdentityPromise.then(() =>
          readPolicy("codex_browser_use_agent_request_header")
        ),
        new Promise((resolve) => setTimeout(() => resolve(false), 2500)),
      ]);
    } catch {
      return false;
    }
  })();
}

This preserves the real policy when identity resolves promptly, falls back to false after 2.5 seconds or rejection, and caches the bounded result.

Reproduction notes and an idempotent backup/restore PowerShell workaround are available here:

https://github.com/yuelinyayun-star/codex-browser-request-header-timeout-fix

The repository does not redistribute OpenAI's runtime.

What is the expected behavior?

Browser RPC dispatch should not depend indefinitely on identity telemetry or an optional request-header decision.

If the identity request stalls or fails, Codex should either:

• continue after a bounded fallback without the optional header; or
• return a specific, actionable policy/identity error.

It should not hold all tab RPCs until they become nodeRepl.fetch request failed.

Additional information

Validated results on the affected machine:

Operation	Before workaround	After workaround
Browser discovery	succeeds	about 299 ms
First openTabs()	fails after about 21 s	about 2534 ms
Subsequent tabs.list()	fails or never dispatches	about 3 ms

After the workaround:

• bundled node --check passes;
• Edge tabs can be enumerated;
• a real tab can be claimed;
• title and URL can be read;
• the prior fetch failure does not recur in this request path.

The original tested browser-service.mjs SHA-256 is:

C96DBF28F0854B00B0CF79E936ADFB3754ECB6B0714F94C50A594D3B68940E3E

A separate intermittent Debugger unattached state can still occur after a CUA kernel reset or navigation. That is not claimed to be fixed by this workaround.

Requested upstream changes:

• add a bounded timeout and rejection handling around identity-dependent request-header policy;
• avoid coupling optional header policy to all browser RPC dispatch;
• cache the resolved policy;
• report the underlying dependency failure in diagnostics;
• add a test where the identity endpoint stalls while extension discovery and tab enumeration remain healthy.

Start by inspecting the bundled browser-service.mjs and reproduce the openTabs request while the identity endpoint stalls. Trace the caller-identity promise through the request-header policy before extension dispatch. Done means tab RPCs still reach the extension with a bounded fallback, and a test covers a stalled identity request without regressing discovery or tab enumeration.