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 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

{"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 <same project directory> && 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_