Codex Cloud internet set to unrestricted, but outbound HTTPS blocked (CONNECT 403 via proxy)

Open 💬 3 comments Opened May 4, 2026 by laphlaw

With Agent internet access set to On: unrestricted, the cloud task environment cannot reach public HTTPS endpoints.

DNS resolution succeeds, but HTTPS requests fail through a configured proxy with CONNECT tunnel failed, response 403 (Envoy). Direct outbound HTTPS without proxy also fails.

This makes internet effectively unavailable despite unrestricted setting.

Steps to reproduce

Set environment internet access to On: unrestricted.
node -e "require('dns').promises.lookup('example.com').then(console.log)"

curl -I https://example.com --max-time 12
env | rg -i '^(http|https|all)_proxy=|^no_proxy='
HTTPS_PROXY= HTTP_PROXY= curl -I https://example.com --max-time 12

Expected behavior
General internet endpoints should be reachable when internet is unrestricted.

Actual behavior
Connectivity check fails all endpoints.
DNS lookup works.
HTTPS via proxy fails with CONNECT ... 403.
Direct outbound HTTPS without proxy also fails.
Additional context
Same workflow succeeds in local Codex sessions and fails in cloud environment.
This blocks cloud tasks that depend on external downloads.

View original on GitHub ↗

3 Comments

laphlaw · 3 months ago

sakashita-mk · 1 month ago

I can reproduce this issue today.

Environment:

ChatGPT Plus
Codex Cloud
GitHub Connector installed
Internet access enabled

Running:

curl -I https://github.com

returns:

HTTP/1.1 403 Forbidden
server: envoy
curl: (56) CONNECT tunnel failed, response 403

As a result, git push also fails with the same CONNECT tunnel failed error.

This happens before GitHub authentication, so it does not appear to be a repository permission issue.

5gmt · 17 days ago

I can reproduce this in Codex Cloud as well, including after explicitly widening the environment's internet settings.

Environment/context:

ChatGPT Plus / Codex Cloud
GitHub-connected repository
Agent internet access enabled
registry.npmjs.org explicitly added to the allowed domains
Allowed HTTP methods changed to All
Environment/container cache cleared and rebuilt after changing the settings

The failure still occurs before npm/TLS traffic itself, at the proxy CONNECT stage:

CONNECT registry.npmjs.org:443 HTTP/1.1
Host: registry.npmjs.org:443

HTTP/1.1 403 Forbidden
server: envoy

Reproduction/diagnostics:

npm ci --ignore-scripts
# -> fails while fetching @playwright/test@1.62.1 with 403 Forbidden

curl -v --max-time 15 https://registry.npmjs.org/
# -> CONNECT registry.npmjs.org:443 rejected by Envoy with 403

curl -v --max-time 15 \
  https://registry.npmjs.org/@playwright/test/-/test-1.62.1.tgz \
  -o /dev/null
# -> same CONNECT-stage 403

env -u HTTPS_PROXY -u HTTP_PROXY -u https_proxy -u http_proxy \
    -u npm_config_http_proxy -u npm_config_https_proxy \
    curl -I --max-time 20 \
    https://registry.npmjs.org/@playwright/test/-/test-1.62.1.tgz
# -> direct connection times out

So in this case the npm cache/package manager does not appear to be the cause: the configured proxy is reachable, but its CONNECT policy rejects the destination even though that hostname is explicitly allowlisted and HTTP methods are set to All. Direct outbound HTTPS is unavailable as well.

This also prevents downstream validation (npx tsc --noEmit, npm test, and Playwright E2E) because npm ci cannot install the newly added dependency.

One potentially useful distinction: Codex environment setup/maintenance phases with their special network behavior have been able to download Playwright/browser dependencies, while the resumed agent task encounters this CONNECT 403. That makes this look like a mismatch between the UI/environment internet policy and the proxy policy applied to the agent phase, rather than a general npm or DNS problem.