[Bug]: Codex agents get no T3 Code MCP tools when a macOS system proxy returns 502 for loopback #30194

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On macOS, enable a system HTTP proxy that answers 502 for loopback destinations. Here, scutil --proxy shows HTTPProxy: 127.0.0.1, HTTPPort: 7897 and ExceptionsList: *.local, 169.254/16. No *_PROXY variables are set in the app's environment.
2. Start T3 Code and start a new Codex thread.
3. Ask the agent to call any T3 tool, for example t3_thread_send.

Expected behavior

Codex connects directly to T3's local MCP endpoint and the agent gets the T3 tools. A system proxy should not affect a connection between two local processes.

Actual behavior

t3-code and t3-code-direct both fail at session start, so the agent has no T3 tools. The call fails with tools.t3_thread_send is not a function. Codex did not recover during the session: ALL_TOOLS still had no match 24 minutes later.

T3's server trace has no initialize request from Codex for either failed startup. A Claude thread's POST /mcp returned 200 in the same window.

Cause: Codex's MCP HTTP client uses the macOS system proxy for T3's http://127.0.0.1:3773/mcp URL. T3 does not exempt loopback: the Codex app-server it spawned has no NO_PROXY in its environment.

I confirmed this without T3 by running a throwaway codex app-server (empty CODEX_HOME, no model turn) against a minimal local MCP server:

In the third row, the host matches the *.local exception and has no DNS record. A direct curl fails to connect, and curl through the proxy gets the same 502. So Codex appears to ignore the macOS ExceptionsList, and adding 127.0.0.1 to it would likely not help. I did not test that change directly.

Suggested fix: merge 127.0.0.1,localhost,::1 into NO_PROXY and no_proxy when T3 spawns the Codex app-server. T3 owns both the URL and the spawn environment. The second row shows this works with Codex 0.166.0, but I have not tested it through T3's spawn path.

Side effect: the URL is plain HTTP, so routing it through the proxy also exposes T3's MCP bearer token to the proxy.

Regression status: the same Codex 0.166.0 reached ready on T3 nightly 20261031.4004 on 2026-11-01. I can't tell whether the system proxy was on at that time, so I am not calling this a regression.

Related:

• [Bug]: Codex 0.160 agents get no T3 Code MCP tools: /mcp answers server/discover with HTTP 400 #16067 has the same symptom but a different cause: the request reaches T3, which answers 400.
• Provider maintenance subprocesses don't inherit macOS system proxy settings #2709 and fix(server): provider updates on macOS use the system proxy #25747 cover provider updates and the system proxy.
• fix(desktop): use shell proxies for provider and backend requests #15852 covers T3's own backend requests and loopback bypass.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261103.4119

Environment

macOS 27.0.1 (arm64), T3 Code Nightly desktop app, Codex CLI 0.166.0

Logs or stack traces

# Provider event log
mcpServer/startupStatus/updated  name: t3-code  status: failed
MCP client for `t3-code` failed to start: MCP startup failed: handshaking with MCP server failed:
... error: unexpected server response: HTTP 502: , when send initialize request

# Same MCP initialize request, sent without credentials
$ curl -x http://127.0.0.1:7897 ... http://127.0.0.1:3773/mcp
HTTP/1.1 502 Bad Gateway
Content-Length: 0

$ curl --noproxy '*' ... http://127.0.0.1:3773/mcp
HTTP 401

Workaround

Neither option has been tested through T3:

• Turn off the macOS system proxy before starting a Codex thread.
• Set NO_PROXY and no_proxy with launchctl setenv, then fully restart T3 Code.

Threads that are already running probably need a new session to get the tools.