›_ Codex Issues
Codex Issues / #35924

VS Code extension: Statsig initialization fails through SOCKS5 but succeeds through HTTP on the same proxy core

Open 💬 0 comments Opened Jul 29, 2026 by lengmh

What version of the IDE extension are you using?

openai.chatgpt@26.721.41059

The issue was reproduced in both extension contexts:

  • Windows: openai.chatgpt-26.721.41059-win32-x64
  • Remote-WSL2: openai.chatgpt-26.721.41059-linux-x64

The bundled Codex CLI reports 0.146.0-alpha.3.1. The installed Gallery extension itself is on the regular release channel, not VS Code's pre-release channel.

For comparison, the older openai.chatgpt@26.5707.91948 extension bundled Codex CLI 0.144.5 and could access the service directly in the same environment, without any proxy configuration. This establishes a practical regression boundary between the two integrated extension builds. It does not by itself prove that the CLI executable is the failing component, because the Statsig request is issued through the extension webview/Extension Host network path.

What subscription or authentication mode are you using?

  • Codex API key authentication: successful
  • Custom model provider: enabled
  • ChatGPT account/plan authentication: successful

A comparison machine using the same API-key/custom-provider arrangement initializes Statsig normally, so the authentication mode alone does not explain the failure.

The older extension/CLI integration also worked locally over the direct network path, providing a second control against API-key authentication being the cause.

Which IDE are you using?

VS Code 1.130.0 (1b6a188127eeaf9194f945eb6eb89a657e93c54c).

What platform is your computer?

  • Windows 11 x64
  • VS Code Remote-WSL2, Linux x64
  • VS Code Server Extension Host runtime: Node.js 24.18.0
  • Local proxy core: xray, exposing both SOCKS5 and HTTP inbound listeners; the verified successful HTTP test used a US-region outbound

What issue are you seeing?

With the current extension, Statsig initialization fails on the direct network path. Routing through the tested local SOCKS5 listener also fails with TypeError: fetch failed, even though Codex's ambient webview requests demonstrably reach that listener.

The Statsig provider still mounts and reports Ready, while no gate values are loaded:

  • loadingStatus=Ready
  • values status=Ready
  • refresh flow success=true
  • hasValues=false
  • error={}

This silently disables Statsig-backed Codex UI, even though Codex API-key/custom-provider authentication and model calls work. Observed missing UI included localization, Model Features settings, and Subagent activity surfaces.

The only configuration verified to restore Statsig was a US-region route exposed through xray's HTTP listener, followed by Reload Window:

  • hasValues=true
  • success=true
  • error=null
  • no /v1/initialize fetch errors

The successful result therefore has two observed conditions: a US-region outbound and the HTTP proxy transport. Other geographic regions have not been tested broadly, so this report does not claim that the US region is universally required. The SOCKS5 failure remains independently reproducible with the tested route and appears related to the current experimental SOCKS5 fetch path.

The behavior is also version-sensitive: the older 26.5707.91948 extension with bundled CLI 0.144.5 could use the direct route and did not require a proxy. The affected 26.721.41059 extension bundles CLI 0.146.0-alpha.3.1 and, in this environment, requires the verified US-region HTTP route. Because the AB request itself runs through webview and Extension Host code, this comparison identifies an extension-integration regression window but does not isolate the regression to the CLI binary alone.

What steps can reproduce the bug?

  1. With openai.chatgpt@26.721.41059, leave VS Code http.proxy unset and use the direct network route. Open Codex and observe that Statsig initialization does not load values.
  1. Run a local proxy core with SOCKS5 and HTTP listeners. In this environment:
  • SOCKS5 example: socks5://127.0.0.1:10808
  • HTTP example: http://127.0.0.1:10809
  1. Select the tested US-region outbound and set VS Code User Settings to its SOCKS5 listener:

``json
{
"http.proxy": "socks5://127.0.0.1:10808"
}
``

http.proxySupport is left at its default (override), and http.electronFetch is not set.

  1. Reload VS Code and open the Codex extension.
  1. Inspect the active window's Codex.log. The initial Statsig request and later interval refreshes fail. A cold reload produces the same result, ruling out a stale Extension Host process.
  1. Keep the tested US-region outbound, but change the VS Code proxy setting to the HTTP listener:

``json
{
"http.proxy": "http://127.0.0.1:10809"
}
``

  1. Reload VS Code again. Statsig initializes successfully and the gated UI returns.

The two local listeners are served by the same xray process. In the verified proxy comparison, success required the HTTP listener; the SOCKS5 listener did not work.

  1. As a version comparison, install/activate openai.chatgpt@26.5707.91948 with its bundled CLI 0.144.5 under the same local network conditions. That integrated build works directly, without configuring an HTTP or SOCKS5 proxy.

What is the expected behavior?

  • A newer integrated extension build should not lose direct connectivity when the older build works on the same machine and network.
  • Codex Extension Host requests should also work reliably when VS Code http.proxy points to a valid SOCKS5 proxy.
  • Statsig /v1/initialize should not depend on an undocumented geographic egress region. At minimum, failures should expose whether they are caused by endpoint policy, routing, or the local proxy transport.
  • A failed AB request should expose a useful underlying network cause instead of leaving the provider superficially Ready with refresh success=true and no values.
  • Local fetch failures should not be represented as if they were real upstream HTTP responses.
  • API-key/custom-provider users should not silently lose otherwise usable UI because ambient AB initialization failed.

What is the actual behavior?

Representative redacted log sequence on the failing current-version paths, including the tested SOCKS5 setting:

[statsig-refresh-diagnostics] React root render requested windowType=extension
[statsig-refresh-diagnostics] ready provider mounted instanceId=1 windowType=extension
Error fetching error="TypeError: fetch failed" url=https://ab.chatgpt.com/v1/initialize?[REDACTED_QUERY]
[statsig-refresh-diagnostics] refresh started loadingStatus=Ready status=Ready
[statsig-refresh-diagnostics] values updated hasValues=false
[statsig-refresh-diagnostics] refresh finished success=true error={}
sa_server_request_failed routePattern=/wham/tasks/list status=432

All observed refresh groups completed with success=true, but all had hasValues=false and error={}. The log did not preserve the underlying DNS/TLS/socket error behind the top-level TypeError: fetch failed.

Representative result after switching to the HTTP listener:

[statsig-refresh-diagnostics] values updated hasValues=true
[statsig-refresh-diagnostics] refresh finished success=true error=null
Error fetching httpStatus=401 routePattern=/wham/tasks/list

The 401 is the real upstream response for cloud tasks without ChatGPT account authentication. The earlier 432 was a locally synthesized fetch-failure status, not a server permission response.

Related diagnostics and root-cause evidence

The observed request path is:

Statsig webview networkOverrideFunc
  -> Codex webview request bridge
  -> VS Code Extension Host fetch()
  -> VS Code @vscode/proxy-agent
  -> local proxy listener
  -> xray outbound

Evidence:

  1. Extension Host socket monitoring showed the active Extension Host PID connecting to 127.0.0.1:10808 during a failed Statsig refresh. The extension was therefore not bypassing the configured SOCKS proxy.
  2. VS Code logged that SOCKS5 proxy support is experimental.
  3. The same cold reload also showed TLS-before-handshake disconnects for other Extension Host network traffic, so the failure was not isolated to the Statsig endpoint.
  4. With the tested US-region outbound, switching the local proxy transport from SOCKS5 to HTTP on the same xray process changed Statsig from hasValues=false to hasValues=true in both Windows and Remote-WSL extension contexts.
  5. After the switch, /wham/tasks/list changed from synthetic 432 to the real upstream 401, independently confirming that Extension Host requests were reaching the service.
  6. A separate comparison machine on the same extension release can use SOCKS5 successfully. Therefore, this should not be described as a universal SOCKS5 failure in VS Code. The narrower hypothesis is a compatibility or connection-lifecycle issue between the current experimental VS Code/Undici SOCKS5 dispatcher and this xray SOCKS ingress/environment.
  7. The older 26.5707.91948 extension, whose embedded CLI is 0.144.5, works directly in the affected environment without any proxy. The current failing integrated build is 26.721.41059 with embedded CLI 0.146.0-alpha.3.1. This narrows the regression window, although it does not establish whether the responsible change is in Codex extension JavaScript, the bundled integration stack, VS Code proxy interaction, the CLI, or the service request profile.
  8. A US-region HTTP route is the only successful current-version route verified so far. Geographic variants have not been tested broadly, so region causality remains a bounded observation rather than a universal conclusion.

Impact

Normal Codex API-key/custom-provider model calls continue to work, but several user-facing surfaces disappear or degrade at the same time:

  1. Localization does not load. The webview remains in English even when the VS Code locale and chatgpt.localeOverride are already set to zh-CN. With no Statsig values, the enable_i18n path falls back to disabled and the locale message bundle is not loaded.
  2. Settings → Configuration loses the entire Model Features section. The card containing model capability controls is not mounted. This removes controls previously shown as Available reasoning efforts and Ultra in model picker slider rather than merely disabling a single option.
  3. The conversation model picker/reasoning slider loses Ultra. gpt-5.6-sol and gpt-5.6-terra, which support Ultra in this setup, no longer expose it in the conversation UI. gpt-5.6-luna is intentionally excluded and its lack of Ultra is not part of this bug.
  4. Subagent execution loses its dedicated UI surfaces. A spawn_agent call may still run, but the conversation does not show the normal inline Subagent activity/call card, and the toolbar above the conversation does not show the “N background agents” dropdown used to inspect running agents.
  5. The cloud-tasks surface shows a misleading network error. /wham/tasks/list is represented as synthetic status 432, which can produce an error banner instead of the expected empty/no-cloud-tasks state. After connectivity is restored, the same API-key/no-ChatGPT-account setup receives the real upstream 401, which the UI handles without the false 432 banner.
  6. The failure looks like an account entitlement restriction. The Statsig provider says Ready and each refresh says success=true, while hasValues=false silently applies default-false gates. API-key users can therefore conclude incorrectly that localization, Model Features, Ultra, or Subagent UI require a ChatGPT subscription.

The following locally driven paths were checked and did not show the same Statsig dependency in this incident: ordinary model conversations, local/recent task history, standard tool-call cards, MCP call cards, approval prompts, and worktree-related UI. Review Mode was not evaluated. This boundary matters because the bug disables a specific set of gated surfaces rather than breaking the whole Codex extension.

The combined impact encourages users to patch minified webview gates individually. Those patches can restore visible symptoms, but they are version-specific and mask the failed Extension Host/Statsig network route rather than fixing it.

Workaround

Configure VS Code to use a working local HTTP proxy listener backed by the tested US-region route, then reload the window. For this machine only:

{
  "http.proxy": "http://127.0.0.1:10809"
}

The port is only an example; users must select an HTTP listener actually exposed by their own proxy application. Only the US-region route has been confirmed here; this report does not establish which other regions work or fail.

Local edits that force individual webview gates can restore visible symptoms, but they are version-specific temporary mitigations and do not repair failed Extension Host requests.

Suggested changes

  1. Compare direct-connect behavior and Extension Host/webview networking changes between the 26.5707.91948 + CLI 0.144.5 integration and the 26.721.41059 + CLI 0.146.0-alpha.3.1 integration.
  2. Verify the Codex ambient/webview request bridge against VS Code's current SOCKS5 http.proxy path and xray-compatible SOCKS5 listeners.
  3. Clarify whether ab.chatgpt.com or the current request profile has any intended geographic availability policy; if not, investigate why only the tested US-region route succeeds in this environment.
  4. Preserve and log the underlying fetch cause/code where possible, while continuing to redact credentials and query identifiers.
  5. Do not report a refresh as unqualified success=true when Statsig initialization produced no values because of a network error, or add a separate explicit network/result field.
  6. Distinguish locally synthesized fetch-failure statuses from actual upstream HTTP responses in diagnostics.
  7. Consider a visible degraded-state diagnostic when AB values cannot load, so missing gated UI is not mistaken for an account limitation.

Possibly related reports

This report differs from older "proxy ignored" reports: the current Extension Host demonstrably connects to the configured SOCKS listener. The failure occurs after routing reaches that listener, while the tested US-region HTTP path succeeds. Other regional HTTP routes have not yet been compared systematically.

View original on GitHub ↗