[BUG] Playwright MCP browser cannot traverse the session's mandatory HTTPS_PROXY egress proxy (100% ERR_CONNECTION_RESET, even with explicit --proxy-server)

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?

Every browser_navigate call from the Playwright MCP tool fails with net::ERR_CONNECTION_RESET, for every destination tested — including https://example.com. Meanwhile, curl (which respects $HTTPS_PROXY automatically) succeeds on the identical URLs in the same session, at the same time. 100% connection reset, on every destination tried, with or without an explicit --proxy-server flag pointed at a proxy address independently verified to be reachable and functional (curl succeeds through it in the same breath).

What Should Happen?

Chromium launched by the Playwright MCP server should reach destinations through the session's proxy, the same way curl and other tools in the session do — either automatically, or via whatever proxy argument the MCP server config is supposed to pass through.

Error Messages/Logs

url: https://example.com

### Error
Error: browserBackend.callTool: net::ERR_CONNECTION_RESET at https://example.com/
Call log:
  - navigating to "https://example.com/", waiting until "domcontentloaded"

Steps to Reproduce

1. In a Claude Code cloud session with the proxy-enforced network policy active, confirm the proxy is healthy:

curl -sS "$HTTPS_PROXY/__agentproxy/status"
# → {"enabled": true, ..., "recentRelayFailures": []}
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com
# → 200

1. Call the Playwright MCP tool browser_navigate with url: "https://example.com".

``→ Error: browserBackend.callTool: net::ERR_CONNECTION_RESET at https://example.com/``

1. Rule out a proxy-arg problem by driving the exact same, already-installed Chromium binary directly, bypassing the MCP layer:

# No proxy flag — fails, as expected:
/opt/pw-browsers/chromium --headless --disable-gpu --no-sandbox --dump-dom https://example.com
# → "The connection was reset." / ERR_CONNECTION_RESET
# Explicit --proxy-server pointed at the exact address curl just used successfully:
/opt/pw-browsers/chromium --headless --disable-gpu --no-sandbox \
  --proxy-server="127.0.0.1:<port from $HTTPS_PROXY>" --dump-dom https://example.com
# → STILL "The connection was reset." / ERR_CONNECTION_RESET

1. Also tried --disable-ipv6 and --disable-features=IPv6 in combination with --proxy-server - no change. (The proxy target is 127.0.0.1, so IPv6/IPv4 resolution isn't a plausible factor anyway.)

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.227 (Claude Code)

Platform

Claude Code on the web / a managed cloud environment

Operating System

Linux

Terminal/Shell

Claude Code cloud/remote execution session

Additional Information

• This is not a certificate-trust issue — errors are ERR_CONNECTION_RESET, not ERR_CERT_*, so this isn't the "browser NSS store doesn't trust the proxy's CA" class of problem described in the environment's own proxy README.
• This is not destination-specific — example.com fails identically to every real target site tried (LinkedIn, Reddit, WeWorkRemotely, Braintrust, ZeroTaxJobs, nthesis.ai).
• /root/.ccr/README.md's own troubleshooting guide has no failure class that matches "tool explicitly configured with the correct proxy address still gets reset" — its closest category ("tool ignores the proxy entirely") describes timeouts, not resets, and doesn't apply once --proxy-server is set explicitly.
• Given the README's own guidance ("if a tool still cannot work through the proxy, report it... do not work around it by disabling TLS verification or unsetting HTTPS_PROXY"), filing this rather than attempting further workarounds.