claude-code - 💡(How to fix) Fix Managed Agents: gmail.googleapis.com blocked by egress proxy even with explicit allowed_hosts [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46629Fetched 2026-04-12 13:37:14
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
labeled ×1

gmail.googleapis.com is unreachable from Managed Agent containers regardless of networking configuration. The egress proxy (SWP with TLS inspection) returns an HTML 403 that does not originate from Google — it lacks all standard Google API response headers (server: ESF, vary, x-xss-protection, etc.).

Root Cause

gmail.googleapis.com is unreachable from Managed Agent containers regardless of networking configuration. The egress proxy (SWP with TLS inspection) returns an HTML 403 that does not originate from Google — it lacks all standard Google API response headers (server: ESF, vary, x-xss-protection, etc.).

Code Example

$ python -c "
import json, requests
with open('token.json') as f: t = json.load(f)
resp = requests.post('https://oauth2.googleapis.com/token', data={...})
token = resp.json()['access_token']
r = requests.get('https://gmail.googleapis.com/gmail/v1/users/me/profile',
                  headers={'Authorization': f'Bearer {token}'})
print(r.status_code, r.json())
"
200 {"emailAddress": "***@gmail.com", "messagesTotal": 3931, ...}

---

Issuer: O=Anthropic; CN=sandbox-egress-production TLS Inspection CA

---

import anthropic

client = anthropic.Anthropic()

# Environment with explicit allowed_hosts
env = client.beta.environments.create(
    name="gmail-test",
    config={
        "type": "cloud",
        "networking": {
            "type": "limited",
            "allowed_hosts": ["gmail.googleapis.com", "oauth2.googleapis.com"],
            "allow_package_managers": True,
        },
    },
)

# Create session and ask agent to curl gmail.googleapis.com
session = client.beta.sessions.create(
    agent=AGENT_ID,
    environment_id=env.id,
)
# Send: "Run: curl -v https://gmail.googleapis.com/gmail/v1/users/me/profile"
# Result: HTML 403 with no Google-specific headers
RAW_BUFFERClick to expand / collapse

Description

gmail.googleapis.com is unreachable from Managed Agent containers regardless of networking configuration. The egress proxy (SWP with TLS inspection) returns an HTML 403 that does not originate from Google — it lacks all standard Google API response headers (server: ESF, vary, x-xss-protection, etc.).

Environment configurations tested

All three configurations produce the same 403 result:

  1. unrestricted networking (default)
  2. unrestricted networking (fresh environment)
  3. limited networking with explicit allowed_hosts: ["gmail.googleapis.com", "oauth2.googleapis.com", "www.googleapis.com"]

What works vs. what doesn't

EndpointResultResponse headers
oauth2.googleapis.com (token refresh)✅ 200server: ESF, full Google headers
storage.googleapis.com✅ 403 JSON (expected — no access)server: UploadServer, Google headers
compute.googleapis.com✅ 403 JSON (expected — no access)Google headers present
gmail.googleapis.com❌ 403 HTMLOnly content-type, referrer-policy, dateno Google headers
www.googleapis.com/discovery❌ 403 HTMLSame non-Google response

Proof that credentials and API are valid

The exact same token.json and credentials.json (mounted via Files API) work perfectly from outside the sandbox:

$ python -c "
import json, requests
with open('token.json') as f: t = json.load(f)
resp = requests.post('https://oauth2.googleapis.com/token', data={...})
token = resp.json()['access_token']
r = requests.get('https://gmail.googleapis.com/gmail/v1/users/me/profile',
                  headers={'Authorization': f'Bearer {token}'})
print(r.status_code, r.json())
"
200 {"emailAddress": "***@gmail.com", "messagesTotal": 3931, ...}
  • Gmail API is enabled in the GCP project
  • OAuth token scope: https://mail.google.com/ (confirmed via tokeninfo)
  • Token refresh works inside the container

TLS inspection detail

The proxy performs MITM TLS inspection:

Issuer: O=Anthropic; CN=sandbox-egress-production TLS Inspection CA

The CONNECT tunnel to gmail.googleapis.com:443 is established, but the response at the HTTP layer is a synthetic 403 from the proxy infrastructure, not from Google's servers.

Reproduction

import anthropic

client = anthropic.Anthropic()

# Environment with explicit allowed_hosts
env = client.beta.environments.create(
    name="gmail-test",
    config={
        "type": "cloud",
        "networking": {
            "type": "limited",
            "allowed_hosts": ["gmail.googleapis.com", "oauth2.googleapis.com"],
            "allow_package_managers": True,
        },
    },
)

# Create session and ask agent to curl gmail.googleapis.com
session = client.beta.sessions.create(
    agent=AGENT_ID,
    environment_id=env.id,
)
# Send: "Run: curl -v https://gmail.googleapis.com/gmail/v1/users/me/profile"
# Result: HTML 403 with no Google-specific headers

Expected behavior

gmail.googleapis.com should be reachable from Managed Agent containers when:

  • Networking is set to unrestricted, OR
  • The domain is explicitly listed in allowed_hosts with limited networking

Impact

This blocks any Managed Agent use case involving Gmail API (reading, sending, or managing email), which is a common automation scenario.

Related issues

  • #34690 — JWT not reflecting "All domains" setting
  • #30861 — MITM egress proxy blocks non-API domains regardless of allowlist
  • #30112 — Additional allowed domains not applied to container network egress

extent analysis

TL;DR

The issue can be resolved by configuring the egress proxy to exempt gmail.googleapis.com from TLS inspection or by adding the necessary headers to the proxy's response to make it appear as a legitimate Google response.

Guidance

  • Investigate the egress proxy configuration to determine why it's returning a synthetic 403 response for gmail.googleapis.com requests, despite the domain being allowed.
  • Verify that the allowed_hosts configuration is correctly applied to the container's network egress.
  • Consider temporarily disabling TLS inspection for gmail.googleapis.com to test if it resolves the issue.
  • Review related issues (#34690, #30861, #30112) to see if they provide any insight into the problem or potential solutions.

Example

No code snippet is provided as the issue seems to be related to the egress proxy configuration rather than the code itself.

Notes

The issue may be specific to the egress proxy configuration or the Managed Agent environment, and resolving it may require collaboration with the network or infrastructure team.

Recommendation

Apply a workaround by configuring the egress proxy to exempt gmail.googleapis.com from TLS inspection, as this is likely to be the most straightforward solution to resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

gmail.googleapis.com should be reachable from Managed Agent containers when:

  • Networking is set to unrestricted, OR
  • The domain is explicitly listed in allowed_hosts with limited networking

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING