[macOS app] Finder-launched Codex may miss shell proxy env and repeatedly reconnect

Codex version

• Codex App: 26.623.70822 (build 4559)
• Bundled CLI: 0.142.4
• Platform: macOS 26.4.1, Darwin 25.4.0 arm64
• Authentication: ChatGPT
• Model/provider: gpt-5.5 with the built-in openai provider

What issue are you seeing?

When Codex Desktop is launched from Finder/Dock on a Mac that requires a local proxy, conversations repeatedly show Reconnecting.... The response stream retries about every 15 seconds and eventually reaches retries 1/5 through 5/5.

In this environment:

• HTTP proxy: http://127.0.0.1:10800
• SOCKS proxy: socks5://127.0.0.1:10801
• Proxy variables originally existed only in ~/.zshrc

Terminal processes could use the proxy, but a GUI app launched by Finder/Dock did not reliably inherit the interactive shell environment. The Codex app-server therefore did not consistently route its requests through the local HTTP proxy.

Steps to reproduce

1. Use a network where Codex/ChatGPT access requires a local proxy.
2. Configure HTTP_PROXY, HTTPS_PROXY, and related variables only in ~/.zshrc.
3. Launch Codex Desktop from Finder or the Dock.
4. Start a gpt-5.5 conversation.
5. Observe repeated Reconnecting... messages and codex_core::responses_retry events.

Feedback thread ID: 019f114e-c19d-70c2-94ab-f8d9f4266761

Confirmed workaround

Export the HTTP proxy into the per-user launchd environment, then fully quit and reopen Codex:

#!/bin/zsh
set -euo pipefail

proxy_url="${1:-http://127.0.0.1:10800}"
no_proxy_value="localhost,127.0.0.1,::1"

launchctl setenv HTTP_PROXY "$proxy_url"
launchctl setenv HTTPS_PROXY "$proxy_url"
launchctl setenv http_proxy "$proxy_url"
launchctl setenv https_proxy "$proxy_url"
launchctl setenv NO_PROXY "$no_proxy_value"
launchctl setenv no_proxy "$no_proxy_value"

[[ "$(launchctl getenv HTTP_PROXY)" == "$proxy_url" ]]
[[ "$(launchctl getenv HTTPS_PROXY)" == "$proxy_url" ]]

print "Codex GUI proxy configured: $proxy_url"
print "Fully quit and reopen Codex now."

To remove the workaround:

for key in HTTP_PROXY HTTPS_PROXY http_proxy https_proxy NO_PROXY no_proxy; do
  launchctl unsetenv "$key"
done

launchctl setenv is session-scoped, so it may need to be applied again after logout or reboot.

Verification after applying the workaround

After fully quitting and reopening Codex:

• The app-server had an established TCP connection to 127.0.0.1:10800.
• App transport initialized with reconnectAttempt=0.
• New gpt-5.5 requests completed successfully.
• No new codex_core::session::turn errors appeared.
• No new codex_core::responses_retry events appeared.
• codex doctor --json reported the Responses WebSocket handshake as HTTP 101 Switching Protocols with provider openai.

Important: an HTTP-only custom provider is not a valid workaround

I also tested a custom provider with supports_websockets = false. With gpt-5.5, this caused:

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

That separate incompatibility is already tracked in #30224. Restoring the built-in openai provider and applying the launchd proxy environment was the working combination.

Expected behavior

Codex Desktop should either:

1. honor the macOS system proxy configuration,
2. expose a documented in-app proxy setting, or
3. document that Finder/Dock launches require launchd environment variables.

A missing GUI proxy environment should also produce a direct network/proxy diagnostic instead of only repeated Reconnecting... messages.