Cloud environments (routines): headless Chromium gets ERR_CONNECTION_RESET on all sites even with Network access = Full (curl works)

Summary

In cloud environments used by scheduled routines (claude.ai/code), headless Chromium cannot establish any outbound connection — every navigation fails with net::ERR_CONNECTION_RESET — even though the environment's Network access is set to Full, and even though curl/Node fetch reach the same URLs successfully at the same moment through the sandbox's mandatory local forward proxy.

This blocks browser-automation use cases (Playwright / headless Chromium / the agent-browser CLI) inside routines, which otherwise work well.

Environment

• claude.ai/code cloud environment, Network access = Full
• Routine (scheduled trigger) sessions, claude-sonnet-5
• Sandbox sets http_proxy=http://127.0.0.1:<port> (port varies per session, e.g. 41945, 45379)
• Chromium via npx playwright install chromium (Chrome for Testing 149.x, PLAYWRIGHT_BROWSERS_PATH=/opt/pw-browsers preset in the image)

Reproduction (observed across 4 independent routine sessions, same day)

1. In a routine session, curl -sS -o /dev/null -w '%{http_code}' https://example.com → 200 (proxy honored automatically). Arbitrary sites work, e.g. https://slack.com/pricing → 200.
2. Launch headless Chromium against the same URL:

• direct (no proxy flag) → net::ERR_CONNECTION_RESET (expected if direct egress is proxied-only)
• with --proxy-server=http://127.0.0.1:<port> (the exact $http_proxy value) plus --ignore-certificate-errors --no-sandbox → still net::ERR_CONNECTION_RESET, on every site including https://example.com, 4/4 attempts
• verified independently with a raw Playwright launch (bypassing any CLI wrapper) with the same proxy arg → same result

1. Same-moment curl to the identical URL returns 200 every time.

What this looks like

The sandbox's security proxy appears to accept plain HTTP clients (curl/node) but resets connections from browser-class TLS clients, regardless of the environment's Network access level. Notably, an API-created Managed Agents environment with networking: {type: "unrestricted"} (same sandbox image, tested the same day) allows headless Chromium to browse external sites without issue after --ignore-certificate-errors — so the sandbox image itself supports headless browsing; the restriction appears specific to the routine/cloud-environment proxy path.

Possibly related: bare-minimal routine sessions whose prompt only runs a few curl diagnostics appear to terminate silently before completing (two attempts, no output produced), while heavier sessions in the same environment complete normally. Mentioned in case it shares a root cause; happy to split into a separate issue.

Expected

With Network access = Full, a headless browser launched inside the sandbox (configured to use the sandbox proxy) should be able to reach external sites, or the limitation should be documented (the Claude Code on the web docs describe the Network access levels but don't mention browser clients behaving differently).

Ask

Either allow browser-class clients through the cloud-environment proxy when Network access = Full (or via a Custom setting), or document the restriction and the recommended pattern for browser automation in routines.

Happy to run further diagnostics in our environment if useful.