Browser plugins should respect proxy settings for ambient network requests
What issue are you seeing?
In managed corporate/client networks, direct access to endpoints such as ab.chatgpt.com or chatgpt.com/backend-api/aura/site_status may be blocked or very slow, while access through an approved proxy works. The Codex App Chrome plugin and in-app browser appear to make ambient requests through nodeRepl.fetch / the native fetch bridge without respecting those proxy settings.
This has shown up in two ways:
- Older behavior: Chrome plugin workflows could fail completely. Browser runtime bootstrap /
browser.user.openTabs()repeatedly timed out after 20-60s even though Chrome, the extension, and the native host were installed. - Current behavior: recent builds are functional, but still slow. Browser setup/navigation can stall while ambient requests time out.
A local diagnostic run showed:
- first Chrome open timed out around 60s
- retry connected quickly
- navigation timed out around 40s but eventually loaded
nodeRepl.fetchcalls toab.chatgpt.com/v1/initializeandchatgpt.com/backend-api/aura/site_statustimed out around 30s- the same URLs were fast through the approved proxy, while direct connections were slow or hung
- running
node_replprocesses did not appear to receiveHTTP_PROXY,HTTPS_PROXY,ALL_PROXY, orNO_PROXY
What steps can reproduce the bug?
- Use Codex App in a network where direct OpenAI/ChatGPT auxiliary endpoints are blocked or slow, but proxy access works.
- Configure a proxy, for example:
- macOS system-wide HTTP/HTTPS/SOCKS proxy in System Settings
- shell environment variables such as
HTTP_PROXY,HTTPS_PROXY,ALL_PROXY, andNO_PROXY - an enterprise/PAC/VPN-managed proxy
- a local loopback proxy forwarding to the approved network path
- Use the Codex Chrome plugin or in-app browser to open a remote site.
- Observe browser setup, navigation, or safety/status checks hanging or timing out even though tools like
curlwork through the proxy.
What is the expected behavior?
Browser plugin and in-app browser ambient network requests should respect the same proxy configuration as the rest of Codex networking, or provide a documented first-class proxy setting for this path. In particular, the native authenticated/network-aware fetch bridge used by nodeRepl.fetch should be proxy-aware.
Additional information
The duplicate-detection bot pointed to #23225 and #22623. I checked both. #22623 looks like the closest root cause report: Node/helper fetch does not honor proxy settings. This issue is meant to capture the browser-plugin and in-app-browser impact of that class of problem, including both the earlier total failure mode and the current slow-but-eventually-working behavior. Related reports also include #21704, #21722, #21705, #21878, and #21670.
This matters in FDE/client-workplace environments where we often need just enough access through an approved proxy, not direct unrestricted access.
Environment observed:
- Codex App:
26.513.31313(2867) - macOS:
Darwin 24.6.0 arm64 arm - Chrome:
148.0.7778.168 - Codex Chrome extension:
1.1.4
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗