[Regression] In-app Browser and Chrome extension still wait ~30s on ab.chatgpt.com Statsig timeouts in VPN TUN mode

Start by tracing the in-app Browser and Chrome extension operation paths and their shared Statsig initialization and event-logging requests to ab.chatgpt.com. Reproduce the example.com navigation with VPN TUN routing, then verify that non-critical Statsig timeouts no longer delay a successful page navigation or browser-call completion.

What issue are you seeing?

This appears to be a regression or an incomplete fix for #29385, which was closed as completed on 2026-07-14.

On the latest Codex/ChatGPT Desktop build, both the in-app Browser and the Chrome extension can eventually navigate to a normal webpage, but the browser-control operation still takes about 30.5–30.7 seconds. During the wait, the browser client logs 10-second Statsig request timeouts to ab.chatgpt.com.

Current measurements for https://example.com/:

The in-app Browser logged both:

ERROR [Statsig] POST https://ab.chatgpt.com/v1/initialize?... Timeout of 10000ms expired.
ERROR [Statsig] POST https://ab.chatgpt.com/v1/rgstr?... Timeout of 10000ms expired.

The Chrome extension path logged:

ERROR [Statsig] POST https://ab.chatgpt.com/v1/rgstr?... Timeout of 10000ms expired.

The requested webpage is reachable and returns the correct URL/title. However, the browser operation completes only after the ambient Statsig requests time out. Since the total duration is slightly above 30 seconds, this can still surface as a browser-call timeout even though the requested page itself is reachable.

Environment

Codex/ChatGPT Desktop: 26.715.21316 (5484)
Codex CLI: 0.145.0-alpha.18
In-app Browser plugin: openai-bundled/browser/26.715.21316
Chrome plugin: openai-bundled/chrome/26.715.21316
Google Chrome: 150.0.7871.116
macOS: 26.5.2 (25F84)
Architecture: arm64

The same approximately 30-second symptom was also reproducible before updating, with Browser/Chrome plugin build 26.707.91948.

VPN / proxy details

A VPN was already running continuously in TUN mode before Codex and Chrome were launched; it was not enabled only for this test.

The VPN connection dashboard confirms that both processes:

• codex
• Codex (Service)

created HTTPS connections to ab.chatgpt.com:443, and both connections were matched to the active proxy node. This indicates that Codex traffic to this hostname is being captured and routed by the TUN proxy.

In a normal Chrome tab, opening https://ab.chatgpt.com/ returns an HTTP response immediately:

RBAC: access denied

That response is expected for an unauthenticated direct page request, but it confirms that Chrome can resolve, connect to, and receive an HTTP response from the hostname through the current network path. Despite that, the browser-client Statsig POST requests still expire after 10000 ms.

Steps to reproduce

1. On macOS, enable a VPN in TUN mode before starting Codex.
2. Confirm that Codex traffic to ab.chatgpt.com:443 is routed through the active proxy node.
3. Start Codex Desktop with the in-app Browser and Chrome plugins installed.
4. With the in-app Browser, create a tab and navigate to https://example.com/.
5. Verify that the page eventually returns https://example.com/ and title Example Domain.
6. Observe that the operation takes about 30 seconds and logs 10-second Statsig timeouts for /v1/initialize and/or /v1/rgstr.
7. Repeat through the Codex Chrome extension.
8. Observe the same approximately 30-second completion time and Statsig timeout pattern.

Expected behavior

Non-critical Statsig initialization and event logging should not block or delay a user-requested browser operation.

If ab.chatgpt.com is temporarily unreachable from the browser-client network context, these requests should fail open quickly or run independently from the critical navigation path. If the process is expected to honor the system/TUN proxy, its privileged network path should use the same effective routing as the rest of the Codex application.

A successful navigation to a reachable target page should return well within the normal browser-call timeout.

Troubleshooting already attempted

• Updated Codex/ChatGPT Desktop to the latest available build.
• Restarted Codex.
• Restarted Chrome.
• Reinstalled the Codex Chrome extension.
• Restarted macOS.
• Repeated the test after the application/plugin update.
• Confirmed through the VPN dashboard that both codex and Codex (Service) connections to ab.chatgpt.com:443 use the proxy node.

The behavior remains reproducible on both browser surfaces.

Related issues

• #29385 — same in-app Browser/Chrome ambient timeout problem; closed as completed, but still reproducible on build 26.715.21316.
• #30841 — overlaps with the ambient ~30-second delay, but also reports a separate deep-control/CDP bridge hang. This report is limited to the shared Statsig delay that affects both normal Browser surfaces.