Managed Agents: gmail.googleapis.com blocked by egress proxy even with explicit allowed_hosts

[dvazquezd]

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

Endpoint	Result	Response headers
oauth2.googleapis.com (token refresh)	✅ 200	server: 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 HTML	Only content-type, referrer-policy, date — no Google headers
www.googleapis.com/discovery	❌ 403 HTML	Same 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

• [BUG] Allow network egress - All domains' setting not reflected in session proxy JWT #34690 — JWT not reflecting "All domains" setting
• [BUG] Cowork macOS: MITM egress proxy blocks all non-API domains regardless of allowlist settings #30861 — MITM egress proxy blocks non-API domains regardless of allowlist
• [BUG]Cowork network egress allowlist not working - custom domains blocked with 403 blocked-by-allowlist #30112 — Additional allowed domains not applied to container network egress

[KittichoteKamalapirat]

Encountered the same issue but for Google Drive API. The exact same request works when calling from my local machine.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.