[BUG] Cloud environment setup script gets HTTP 503 through the security proxy; the identical curl succeeds when the agent runs it in-session

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?

In a cloud environment configured with Full network access, a curl in the environment's
setup script returns HTTP 503 from the security proxy. The identical command, for the
identical URL, succeeds when I ask the agent to run it later in the same session, in the same
environment.

Concretely, https://pixi.sh/install.sh:

• From the setup script: HTTP 503 on every attempt (5 retries with backoff, all 503).
• From the agent, mid-session: succeeds, and pixi installs normally.

This is not a DNS failure and not an allowlist denial:

• DNS resolves correctly inside the setup script — pixi.sh → 172.67.171.184 (Cloudflare).
• A blocked domain returns 403 in this sandbox (cf. #11897), not 503. This is 503.
• Network access is set to Full, which the docs state allows any domain.

There is a second, possibly related data point. From the same setup script, the redirect target
of that URL succeeds:

• https://pixi.sh/install.sh → 503 — resolves to 172.67.171.184 (Cloudflare)
• https://pixi.prefix.dev/install.sh → 200 — resolves to 185.199.109.153 (GitHub Pages)

pixi.sh exists only to issue a 301 to pixi.prefix.dev, so the two URLs serve identical content.
That makes the failure look host-specific rather than content-specific, and the Cloudflare-fronted
apex is the one that fails.

I can't tell from inside the sandbox whether the root cause is:

1. the setup-script phase using a different egress path than the agent phase (which would be

consistent with #63541, where environment variables configured for the environment are empty
inside the setup script); or

1. the proxy's upstream connection to Cloudflare-fronted hosts being rejected or rate-limited,

with the agent-phase success being timing luck rather than a real difference.

Either way, a 503 at Full network access for a plain HTTPS GET is unexpected, and the error gives
the user nothing to act on.

What Should Happen?

With Full network access, curl https://pixi.sh/install.sh should succeed from the setup
script, exactly as it does from the agent. If the request is being refused deliberately, the proxy
should return a status and message that identify the reason, rather than a bare 503.

Error Messages/Logs

===== DNS =====
pixi.sh                                       172.67.171.184  pixi.sh
pixi.prefix.dev                               185.199.109.153 pixi.prefix.dev

===== traceroute =====
traceroute to pixi.sh (172.67.171.184), 30 hops max, 60 byte packets
 1  192.0.2.1 (192.0.2.1)  0.221 ms  0.135 ms  0.101 ms
 2  21.4.1.157 (21.4.1.157)  0.178 ms  0.086 ms  0.232 ms
 3  * * *
 [... hops 4-30 all * * *]

traceroute to pixi.prefix.dev (185.199.109.153), 30 hops max, 60 byte packets
 1  192.0.2.1 (192.0.2.1)  0.716 ms  0.671 ms  0.665 ms
 2  21.4.1.157 (21.4.1.157)  0.660 ms  0.654 ms  0.649 ms
 3  * * *
 [... hops 4-30 all * * *]

===== setup script output =====
attempt 1: HTTP 503
attempt 2: HTTP 503
attempt 3: HTTP 503
pixi download failed: HTTP 503


(traceroute stops at the sandbox gateway for both hosts, including the one that works, so it
doesn't discriminate — included only to show it was ruled out.)

Steps to Reproduce

1. At claude.ai/code, create a cloud environment with Network access: Full.

1. Set the environment's setup script to:

```bash
#!/bin/bash
set -o pipefail
exec > >(tee -a /home/user/log.log) 2>&1

for i in 1 2 3; do
code=$(curl -sSL -w '%{http_code}' -o /tmp/pixi-install.sh https://pixi.sh/install.sh)
echo "pixi.sh attempt $i: HTTP $code"
[ "$code" = 200 ] && break
sleep $((i * 5))
done

code2=$(curl -sSL -w '%{http_code}' -o /tmp/pixi-install2.sh https://pixi.prefix.dev/install.sh)
echo "pixi.prefix.dev attempt 1: HTTP $code2"

exit 0
```

Note: editing the setup script text invalidates the environment cache, which is required for
the script to actually re-run.

1. Start a new cloud session in that environment and read /home/user/log.log.

Observed: pixi.sh returns 503 on every attempt; pixi.prefix.dev returns 200.

1. In the same session, ask the agent: *"run `curl -fsSL https://pixi.sh/install.sh -o /tmp/p.sh &&

sh /tmp/p.sh`"*.
Observed: succeeds, pixi installs.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

• Environment network access level: Full
• Surface: Claude Code cloud session (desktop)
• Docs state Full allows "any domain":

https://code.claude.com/docs/en/cloud-environments#access-levels

Possibly related:

• #63541 — environment variables aren't available to the setup script (same phase asymmetry)
• #11897 — binaries blocked by proxy with "All domains" network access (returns 403, not 503)
• #10223 — inconsistent network behavior in the default cloud environment

Workaround in use: request https://pixi.prefix.dev/install.sh directly, skipping the
Cloudflare-fronted apex, and exit 0 from the setup script so a failure doesn't block session
startup.