Browser plugins should respect proxy settings for ambient network requests

Resolved 💬 2 comments Opened May 19, 2026 by xc1427 Closed Jun 22, 2026

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.fetch calls to ab.chatgpt.com/v1/initialize and chatgpt.com/backend-api/aura/site_status timed out around 30s
  • the same URLs were fast through the approved proxy, while direct connections were slow or hung
  • running node_repl processes did not appear to receive HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, or NO_PROXY

What steps can reproduce the bug?

  1. Use Codex App in a network where direct OpenAI/ChatGPT auxiliary endpoints are blocked or slow, but proxy access works.
  2. 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, and NO_PROXY
  • an enterprise/PAC/VPN-managed proxy
  • a local loopback proxy forwarding to the approved network path
  1. Use the Codex Chrome plugin or in-app browser to open a remote site.
  2. Observe browser setup, navigation, or safety/status checks hanging or timing out even though tools like curl work 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

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗