DiviOps MCP server subprocess fails all outbound fetch calls in the desktop app's Code tab specifically ("Connection failed: fetch failed") — works fine from the standalone terminal CLI

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

An MCP server's outbound HTTPS requests fail universally when the server is spawned by the Claude desktop app's Code tab — even against a previously-working, genuinely public production domain — while the identical config, run via a standalone terminal claude session, connects successfully every time. The MCP connection/handshake itself succeeds (tools list fine, tool calls execute) — it's specifically the running MCP server's own downstream network call to an external site (WordPress, in this case) that fails, only when that server was spawned by the desktop app's Code tab.

### What Should Happen?

The MCP server's outbound network requests should succeed in the desktop app's Code tab the same way they do in a standalone terminal claude session, since the server, its config, and its target are all identical in both cases.

### Error Messages/Logs

```shell
{"ok":false,"error":{"code":"wp_error","message":"Connection failed: fetch failed"}}
```

### Steps to Reproduce

Configure an MCP server (tested: @diviops/mcp-server, versions 1.5.51 and 1.5.52) with mcpServers env vars pointing at a real, reachable HTTPS site.
In the Claude desktop app's Code tab, call a tool that makes an outbound request to that site — fails with "Connection failed: fetch failed", regardless of destination (tested: loopback URLs, .local hostnames, public tunnel services, and a genuine public production domain — all fail identically).
Open a standalone terminal, run cd && claude, and call the same tool with the identical config — connects successfully immediately.
Ruled out as causes: WordPress-side config/credentials (independently verified via direct curl/Python requests), Little Snitch (allow-all rule confirmed, no denials logged), session permission mode (tested both Auto and Manual/default — no difference), VPN (installed but confirmed disconnected), package version (both 1.5.51 and 1.5.52 fail identically in-app).

### Claude Model

Sonnet (default)

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

Claude 2.110.0 (dfb2ba)

### Platform

Other

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Start by reproducing the same MCP tool call in the desktop app's Code tab and in a standalone terminal claude session, using the identical configuration. Compare the MCP subprocess environment and outbound networking behavior; done means the server can fetch the tested public HTTPS site from the desktop app without returning “fetch failed.”

Written by the indexing model from the issue text.