Scheduled Routine (Trigger) fails at network layer: outbound curl to custom domain gets CONNECT tunnel 403, while interactive session on same account works fine

Summary

A scheduled cloud Routine (trigger) consistently fails its very first network call — a plain curl via the native Bash tool to an HTTPS endpoint on our own custom domain — with a proxy-level CONNECT tunnel failed, response 403 (curl exit code 56), before any HTTP response is received from the target host. This happens 4/4 times across both scheduled and manually-triggered runs of the same routine, spanning 2026-07-30. Meanwhile, an ordinary interactive Claude Code session on the same account reaches the identical URL successfully within ~0.24s, and a different scheduled routine on the same environment reached the same host successfully once.

This points to an outbound network/proxy restriction specific to the sandboxed execution environment that scheduled Routines run in — not to our application, DNS, or account-wide egress.

Environment

• Product surface: Claude Code Routines (scheduled triggers), invoked via RemoteTrigger (action: "run" and via cron schedule)
• Routine ID: trig_0147LSuSSU9f6b4LnnncANem
• environment_id: env_01JusZkdSeBCvYBFVqdhPF7u (the only "Default" anthropic_cloud environment available on this account)
• Model: claude-sonnet-5
• allowed_tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch
• MCP connections: Composio only (not reached — failure happens before any MCP call)

What the routine does (Step 0 of its prompt)

The routine's first instruction is a plain curl via the native Bash tool:

curl -sS -w '\nHTTP %{http_code}\n' https://vault.coachesvault.io/api/hq/research-config -H "Authorization: Bearer <redacted>"

This is our own production Next.js app on Vercel, behind our own custom domain (Porkbun DNS → Vercel). The route itself is a simple authenticated GET handler with no unusual middleware.

Observed failures (4 for 4, identical every time)

1. 2026-07-30, ~07:11 local — scheduled cron fire. Failed.
2. 2026-07-30 — manual re-run, session cse_01QDWJM5v1J6d1wURE8LMFzq. Failed identically.
3. 2026-07-30 — manual re-run, session cse_01YaawQ2qMfKuJNLdi9a9KVx. Failed identically.
4. 2026-07-30 — manual re-run via RemoteTrigger action:"run", session cse_012ixZDXV4YYoViDeGZSDy1T. Failed identically within seconds of firing.

Every time, the routine's own instructions require exactly one retry on connection failure; both attempts fail with the same error, and the routine correctly stops rather than inventing fallback behavior. The transcript for run 4 (viewed via the Claude.ai UI) shows:

"Both attempts to reach https://vault.coachesvault.io/api/hq/research-config failed with a connection-level error (curl: (56) CONNECT tunnel failed, response 403, HTTP 000) — this is the outbound proxy rejecting the tunnel to that host, not a response from the HQ app itself."

curl exit code 56 + "CONNECT tunnel failed, response 403" indicates the local outbound HTTP proxy inside the sandbox refused to establish the TLS tunnel to the target host:port — i.e. a rejection that happens before any request reaches Vercel/our app at all.

Evidence this is NOT our app, DNS, or an account-wide block

• Direct curl to the identical URL from an unrelated machine (not inside any Claude sandbox) returns a normal 401 Unauthorized (correct behavior — missing/invalid bearer token) in ~0.24s. The app is healthy and reachable from the public internet.
• An ordinary interactive Claude Code session on the same account, in the course of the same evening, made dozens of successful curl calls to this exact domain (vault.coachesvault.io) and to our Supabase REST API on a different domain, with zero network failures, across roughly 3 hours of work.
• A second, unrelated scheduled Routine on the same account (trig_01JuiroyY39pRj6ETo79RXK5, an hourly Gmail-reply-watcher), with the same environment_id, the same target host, and the same native-curl-via-Bash calling pattern, succeeded at least once in between the failed Research-routine runs. So this is not a standing/permanent block on the domain or the environment as a whole — but for this specific routine it has now failed 4 consecutive times with zero successes, which no longer looks like ordinary transient flakiness.

Why I don't think this is fixable from the product's configuration surface

I inspected the routine's full config via RemoteTrigger action:"get" — environment_id, mcp_connections, allowed_tools, and the prompt text are all correct and unremarkable. There is only one environment (env_01JusZkdSeBCvYBFVqdhPF7u, "Default") available on this account to switch to. Nothing in the Routines UI (Status / Repeats / Connectors / Instructions) exposes any network/egress-allowlist setting.

Impact

This routine is a nightly business-discovery job (Composio Google Maps + web search) that is designed to be extremely cheap on failure by design — it fetches a small config object first and does zero paid work if that fails, specifically so a network hiccup costs nothing. That safety design is working correctly. But the automation itself has now been fully non-functional for 4 consecutive attempts, requiring a human to manually run the equivalent research by hand in an interactive session as a workaround.

What would help

• Any visibility into whether outbound requests from scheduled-Routine sandboxes to arbitrary HTTPS hosts on non-standard (i.e., not pre-known/allowlisted) custom domains are subject to a different, more aggressive proxy policy than interactive sessions or than other routines.
• If there is an allowlist mechanism for Routine sandboxes, exposing it in the Routine UI (or documenting how to request a host be allowlisted) would resolve this.

Happy to provide the raw transcript IDs above, the routine's full JSON config, or reproduce a fresh failing run on request.