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

Status Open

Maintainer reply None cached

Activity 5 comments · opened Jul 2, 2026

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)

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

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.

View original on GitHub ↗

3 Comments

Rob-Makappen · 1 month ago

The connection resets here are consistent with the proxy limitation in #11791 (no HTTPS CONNECT tunneling), so this likely can't be fixed by network settings alone.

I've filed a feature request at #75632 proposing first-class browser support in cloud sessions: opt-in pre-installed Chromium, localhost-scoped first (no proxy involvement), screenshots surfaced in the session transcript. Would cover the verification use case even while external browsing remains blocked.

AlexGuyNichols · 1 month ago

Still reproduces on Claude Code 2.1.220 (2026-07-25), routine sessions against a custom-allowlist cloud environment. Adding a few variables this report had not tested, plus a non-sandbox control, in case they help narrow it.

Additional variables ruled out (all still net::ERR_CONNECTION_RESET, target is an Azure Static Web Apps host that is explicitly on the environment allowlist):

--disable-http2 and --disable-quic launch args
ignoreHTTPSErrors: true plus --ignore-certificate-errors
Playwright use.proxy set explicitly from the session's own HTTPS_PROXY value
A clean non-headless user agent (the devices['Desktop Chrome'] profile), so the reset is not user-agent driven

Same-moment control in the same session: curl through that identical proxy returned HTTP 200 on 5/5 attempts, and the proxy reported zero relay failures.

Non-sandbox control: the byte-identical Playwright spec, same Playwright version and same target host, passes 9/9 in 6.3 seconds from a local machine with no sandbox proxy involved. So the spec, the config, and the target are all verifiably fine; only the sandbox path fails.

This is consistent with the no-CONNECT-tunneling explanation in #11791. Posting mainly to confirm it is unchanged eight months after that issue and three weeks after this one, since it fully blocks browser-driven scheduled routines (a11y auditing and UAT flows in our case) against any external HTTPS host.

One unrelated red herring worth flagging for anyone else debugging this: our target's edge tarpits the default HeadlessChrome user-agent marker from any network, sandbox or not. An ad hoc probe using a bare Playwright context therefore hangs to timeout even locally, which looks like the same bug but is not. Real specs are immune because a device profile supplies a normal UA. Worth using a device profile in any repro to keep the two effects separate.

shanekba2 · 1 month ago

Hitting this too, in a scheduled routine session (claude-sonnet-5). Same symptom: every Playwright chromium.launch() → page.goto() fails with net::ERR_CONNECTION_RESET, on arbitrary sites (example.com, www.google.com), while curl and Node's built-in https module succeed instantly against the same URLs in the same shell — including through the same local forward proxy.

A few extra data points from my testing that might help narrow it down:

Not specific to the full Chromium binary — headless_shell fails identically.
Not IPv6 resolution order — launching with --disable-ipv6 didn't change the outcome.
The proxy itself is reachable from Chromium — pointing Chromium at a plain HTTP URL (http://example.com) through the same proxy config gets back a 405 (the proxy's documented rejection of non-CONNECT requests), so Chromium is completing a request to the proxy over that path. The reset specifically happens on the HTTPS/CONNECT-tunnel path.
Not a stale-proxy-port artifact — this session's proxy port rotated mid-session (e.g. 37745 → 39163); re-tested with the current port each time and the reset reproduces consistently, not just against a dead port.

Consistent with the theory above that the proxy is resetting browser-class TLS clients specifically rather than the connection being blocked outright. Happy to share full repro scripts if useful.

Showing cached comments. Read the full discussion on GitHub ↗