Webview never starts when a system proxy (VeePN/privoxy) is active — 30s startup timeout fires, "Codex could not start"

Resolved 💬 2 comments Opened Aug 11, 2026 by mongo-driver Closed Aug 13, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt version 26.803.41515 (latest)

What subscription do you have?

plus

Which IDE are you using?

vs code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex sidebar webview fails to start whenever a system HTTP proxy is running (in my case the VeePN VPN, which registers privoxy as the Windows system proxy at 127.0.0.1:8080). The extension logs Webview did not finish starting and replaces the UI with the Codex could not start fallback page, even though the webview does eventually load if given enough time.

Environment
OS: Windows 10/11
VS Code: (add your version)
Extension: openai.chatgpt version 26.803.41515 (latest)
System proxy: VeePN VPN with local privoxy proxy (ProxyServer=127.0.0.1:8080, ProxyEnable=1)
Without the proxy running, the webview starts fine.
Steps to reproduce
Enable a system HTTP proxy (e.g. VeePN/privoxy) so ProxyEnable=1 and ProxyServer=127.0.0.1:8080.
Open VS Code, open the Codex sidebar.
Wait ~30 seconds. The sidebar shows the Codex could not start error page.
Expected behavior
The Codex webview should load normally regardless of whether a system proxy is configured, or the startup timeout should be long enough (or non-blocking) so a slow but successful load isn't killed.

Actual behavior
After ~30s the extension log shows:
Webview did not finish starting extensionVersion=26.803.41515 role=sidebar
The webview is replaced with fallback HTML (default-src 'none', "Codex could not start").
Observed mount times when the proxy is active: routes mounted at ~26.7s / 30.1s (still flagged as failed), and in one session at ~3.5 min. With no proxy, routes mount in ~9s.
Additional notes / suspected cause
The extension's webview readiness timeout is hard-coded to 30 seconds (the XP class in out/extension.js uses setTimeout(..., 3e4)).
The webview only sends the ready message after its initial app data queries resolve (app routes mounted log). Through the system proxy those queries take much longer (30s to 3+ minutes), so the 30s timer fires first, disposes the load, and swaps in the fallback page.
Manually extending that timeout to 10 minutes (6e5) makes the webview start reliably even with the proxy active.
The webview appears to block startup on network-backed queries instead of rendering with local/cached state and loading data in the background.
Logs
Failure (2026-08-11 session, exthost window log):
`
[CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

Webview renderer (successful-but-too-slow case):

[statsig-refresh-diagnostics] React root render requested
[startup][renderer] app routes mounted after 26700ms
`
Suggested fix
Please consider:

1.Raising the webview startup timeout well above 30s (or removing the hard timeout and relying on the ready handshake).
2.Not replacing the webview content with the "could not start" fallback when the load is merely slow.
3.Making the initial data queries non-blocking / fail-fast so the UI mounts with cached or empty state and hydrates in the background.

What steps can reproduce the bug?

you just need a slow proxy

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 16 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37521

Powered by Codex Action

mongo-driver · 14 days ago

yep bro this is same but i give you some options for fix it.this is not just a issue .issue and how to fix it