Codex extension startup deadlocks when account identity requests remain pending instead of falling back offline

[Kurayuri]

What version of the IDE extension are you using?

openai.chatgpt-26.803.41515-linux-x64

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code 1.132.0

What platform is your computer?

Linux 6.8.0-111-generic x86_64 x86_64

What issue are you seeing?

The Codex sidebar fails to start when the Remote Extension Host inherits an HTTP proxy that accepts the TCP connection but leaves CONNECT requests to ChatGPT/OpenAI endpoints pending.

After approximately 30 seconds, the sidebar displays:

Codex could not start
The extension couldn't load its resources.

This does not appear to be an incomplete extension installation or a literal static-resource loading failure:

• the extension activates successfully;
• the bundled Codex app-server starts and returns Initialize;
• the webview JavaScript reaches React root render requested;
• the same installed extension starts normally through a working proxy;
• the same version starts in degraded/offline mode when the network requests reject quickly instead of remaining pending.

The result depends on how the network request fails:

Network condition	Observed result
Working proxy	Codex starts normally.
No proxy and requests fail quickly	Account lookup reports an error, then the webview starts in degraded/offline mode.
Proxy accepts TCP but leaves CONNECT pending	Account lookup never settles, routes never mount, and the 30-second webview watchdog displays the generic resource error.

Representative log from the hanging-proxy case:

2026-08-08 04:00:32.406 [info] Activating Codex extension
2026-08-08 04:00:32.406 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-08 04:00:32.588 [info] [CodexMcpConnection] Initialize received id=1
2026-08-08 04:00:33.633 [info] [statsig-refresh-diagnostics] React root render requested windowType=extension
2026-08-08 04:00:39.221 [error] Statsig: error while bootstrapping post-login client attemptNumber=1 error={}
2026-08-08 04:01:02.599 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

The following messages never appear in the failing startup:

[chatgpt-account-lookup] completed
Features enabled
[startup][renderer] app routes mounted
[statsig-refresh-diagnostics] ready provider mounted

For comparison, on another Remote-SSH host using the same VS Code commit and extension version, direct access to ChatGPT is also unavailable but fails quickly. That startup logs:

React root render requested
Statsig bootstrap failed
[chatgpt-account-lookup] completed ... result=failed status=432 authenticatedAccountPresent=false
Features enabled
[startup][renderer] app routes mounted after 8954ms
[statsig-refresh-diagnostics] ready provider mounted

The sidebar therefore opens in degraded mode even though the backend network calls failed.

What steps can reproduce the bug?

1. Connect to a Linux host using VS Code Remote-SSH.

2. Install or enable openai.chatgpt-26.803.41515-linux-x64.

3. Configure the Remote Extension Host to inherit an HTTP proxy, for example:

   HTTP_PROXY=http://<proxy-host>:7890
   HTTPS_PROXY=http://<proxy-host>:7890
   ALL_PROXY=http://<proxy-host>:7890
   

4. Configure the proxy so that connecting to the proxy itself succeeds immediately, while CONNECT requests for chatgpt.com:443, api.openai.com:443, or ab.chatgpt.com:443 remain pending instead of returning an error.

5. Restart the Remote VS Code Server/Extension Host so that it inherits the proxy environment.

6. Open the Codex sidebar.

7. Observe that React rendering is requested, but account lookup never completes and application routes never mount.

8. After approximately 30 seconds, observe the generic resource-loading error.

9. Remove the hanging proxy and use a network condition where the same requests reject quickly.

10. Restart the Remote Extension Host and open Codex again.

11. Observe that account lookup reports an error, but the routes mount and the sidebar opens in degraded mode.

What is the expected behavior?

A pending account/identity request should not block the complete IDE extension until the outer webview watchdog fires.

Account bootstrap requests should have a bounded deadline shorter than the 30-second webview startup watchdog. A timeout should be treated as a recoverable network error, allowing the existing degraded/offline startup path used when the same request rejects quickly.

In particular:

• pending account identity and /wham/accounts/check requests should be aborted after a bounded timeout;
• timeout should transition the query from loading to error;
• the identity provider should render its fallback children;
• the webview should send ready and display an offline/network warning;
• the outer watchdog should report a bootstrap/network timeout rather than the misleading The extension couldn't load its resources message.

Additional information

I inspected the minified bundle shipped with extension version 26.803.41515.

The identity provider in webview/assets/app-initial-Ge3MuNyY.js contains a gate equivalent to:

if (
  accountInfo.isLoading ||
  (accountsCheck.isLoading && !accountsCheck.hasEverErrored)
) {
  return <Loading debugName="CodexStatsigProvider.async.identity" />;
}

return <Provider>{children}</Provider>;

Relevant observations from the packaged implementation:

1. /wham/accounts/check is queried without an explicit timeout.
2. Its safeGet() call does not pass an AbortSignal.
3. The account-info query sent through vscode://codex/account-info also has no query deadline.
4. The global QueryClient retries only after a query promise rejects. A CONNECT request that remains pending never reaches retry or error handling.
5. The Statsig bootstrap is different: it has an explicit five-second Promise.race timeout, and its error branch renders a fallback provider.
6. The webview sends ready only after the application routes mount.
7. out/extension.js contains an independent 30-second watchdog that waits for ready. When it expires, it replaces the webview HTML with the generic resource-loading error page; it does not abort the pending account requests or trigger offline fallback.

This creates a timeout-budget mismatch:

Statsig bootstrap: bounded five-second timeout and fallback
Account/identity bootstrap: no deadline shorter than the webview watchdog
Webview startup watchdog: 30 seconds, but only replaces the page

In other words, the extension currently fails open when a request rejects, but fails stuck when the same request remains pending.

Related reports showing the same generic watchdog screen include:

• # Codex extension fails to start: "The extension couldn't load its resources" #37458
• Codex sidebar fails with "couldn't load its resources", webview font blocked by CSP (font-src) #37517
• Codex extension fails to load resources on VS Code 1.101.2 / macOS 11.7 #37508

Those reports discuss installation, compatibility, or font CSP as possible causes. This report provides a separate network-controlled reproduction and identifies the account identity loading gate that prevents the renderer from sending ready.

[syusukexrj]

Additional proxy-specific evidence:

• Extension version: openai.chatgpt-26.803.41515
• Codex sandbox network_proxy is configured, but Extension Host fetches do not use it.
• Extension Host starts with --useHostProxy=false and has no HTTP_PROXY/HTTPS_PROXY.
• ab.chatgpt.com fetch failures have no matching CONNECT entry in the proxy log.
• Direct connectivity to ab.chatgpt.com fails.
• Explicit HTTP proxy connectivity succeeds and reaches the endpoint.
• Node.js 22.21 fetch still bypasses HTTP_PROXY/HTTPS_PROXY by default.
• Starting Node with --use-env-proxy makes the same fetch use the proxy successfully.

Expected:
Codex Extension Host and webview-bridged fetch requests should consistently
honor VS Code http.proxy/system proxy settings, or expose a documented
extension-specific proxy setting. Network initialization failure should not
prevent the webview from sending the ready handshake.

[alexr-oai]

We fixed the separate watchdog issue that replaced a running webview with an incorrect resource-loading error. Release details are posted on #37458.

That change does not add deadlines to account requests or make a permanently pending account request fall back to offline mode. Leaving this issue open to track the unresolved account initialization and proxy behavior.