[BUG] Claude Desktop (macOS): chat MCP tool calls time out with zero network activity when a system PAC is configured; configured MCP server stays connected and never receives tools/call

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest are #53869, #44032, #43791; none match this failure mode, see "Related issues" below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

What's Wrong?

On macOS with a system proxy auto-config (PAC) URL set on the network adapter, invoking any MCP tool from a Claude Desktop chat spins for several minutes and then fails with a tool-timeout result ("no response", the assistant then reports the MCP server "isn't running or has crashed").

The remarkable part is where the failure does NOT happen:

1. The MCP server configured in claude_desktop_config.json (via npx mcp-remote <https url>) starts fine, completes initialize and tools/list, and stays healthy for the whole session, answering server keepalive pings every 30 seconds. Its per-server log (~/Library/Logs/Claude/mcp-server-<name>.log) shows that no tools/call is ever sent to it, in any session.
2. Chat tool calls are evidently executed by a separate, on-demand MCP client that Desktop spawns per conversation (consistent with the two independent MCP subsystems described in #56873). We verified this at the server side: when things work, the server's load balancer access logs show a burst from a fresh client (initialize, tools/list, tools/call within one second, user-agent node) that is not the long-lived configured instance.
3. With the PAC configured, that per-chat executor produces zero network traffic. During a timed reproduction we captured the MCP server's ALB access logs for the entire 7-minute window: the only entries are the healthy keepalive ping/pong pairs (202) of the long-lived instance. No initialize, no tools/call, no failed or aborted request arrives from anywhere. The executor appears to hang before making any connection.
4. Remove the PAC from the network adapter, restart Desktop, and the same chat tool call works immediately (the fresh-client burst appears in the ALB logs).

The PAC contents appear irrelevant: our PAC returns DIRECT for the MCP server's host (it only proxies a handful of unrelated hosts). Merely having a PAC configured triggers the hang. The PAC is served from loopback (http://127.0.0.1:<port>/proxy.pac), which may matter if the executor runs in a sandboxed utility process that cannot reach loopback to evaluate the PAC.

Ruled out:

• The MCP server and command: driving the exact configured command (npx mcp-remote <url> --header ...) manually over stdio works perfectly, both direct and with HTTPS_PROXY pointed at the local proxy (70 tools listed, sub-second tools/call responses).
• npx/npm: no npm error logs are produced during failing attempts; the startup spawn resolves from cache in ~135 ms.
• General networking: normal chat (no MCP tools) works fine in the same session; Desktop background API calls work; the configured MCP instance's pings flow throughout.

What Should Happen?

Chat MCP tool calls should work when a system PAC is configured, or at minimum the per-chat MCP executor should fail fast with a diagnosable error instead of silently producing no network activity and timing out after minutes. Ideally Desktop would route chat tool calls through the already-connected configured server instance, which remains healthy the entire time.

Steps to Reproduce

1. macOS: System Settings > Network > adapter > Proxies > enable "Automatic proxy configuration" with any PAC URL (ours is served on loopback and returns DIRECT for the MCP host; the failure does not depend on PAC routing decisions).
2. Add a remote MCP server to claude_desktop_config.json:

``json
{
"mcpServers": {
"my-tools": {
"command": "npx",
"args": ["mcp-remote", "https://<your-mcp-server>/mcp", "--header", "Authorization: Basic ${AUTH_TOKEN}"],
"env": { "AUTH_TOKEN": "..." }
}
}
}
``

1. Restart Claude Desktop. Observe in ~/Library/Logs/Claude/mcp-server-my-tools.log that the server connects and lists tools successfully.
2. In a chat, ask Claude to use one of the tools.
3. The tool call spins for several minutes, then fails with a timeout. The per-server log shows pings only, never a tools/call. Server-side access logs show no connection attempt from the executor.
4. Disable the PAC, restart Desktop, repeat step 4: the tool call succeeds.

Environment

• Claude Desktop 1.18286.0, macOS 26.3.2 (arm64)
• Node v22.22.2 (nvm), npm 10.9.7, mcp-remote 0.1.37
• MCP server: Streamable HTTP behind an AWS ALB, Basic auth header
• PAC served on loopback by a local helper (corporate managed-endpoint setup); PAC returns DIRECT for the MCP host

Evidence excerpts

Per-server log during a failing chat tool call (healthy connection, pings only, no tools/call ever):

18:52:26 Message from client: method="initialize" id=0
18:52:26 Message from server: id=0 result
18:52:26 Message from client: method="tools/list" id=1
18:52:26 Message from server: id=1 result
18:52:56 Message from server: method="ping" id=1
18:52:56 Message from client: id=1 result
... (ping/pong every 30s for the entire 5+ minute spin; nothing else)

Server-side ALB access log for the same window: only POST /mcp 202 ping acknowledgements from the long-lived instance; zero requests from any new client.

Working control (PAC off), same server, ALB access log: burst of POST /mcp 200s (initialize, tools/list, tools/call) from a fresh node user-agent client completing in under a second.

Related issues

• #53869: macOS + PAC, but the app cannot reach claude.ai at all; here chat works and only MCP tool execution breaks.
• #44032: silent MCP tool timeout on Windows, but there the server receives and completes the call; here the executor never opens a connection.
• #56873: documents the independent MCP subsystems whose split behavior we observe here.