Remote triggers: MCP tools fail to load and network proxy blocks outbound HTTP after initial run
Description
Remote scheduled triggers (created via both the API and the web UI at claude.ai/code/scheduled) fail silently after their initial run. MCP connector tools do not load, and the execution environment's network proxy blocks outbound HTTP to custom domains. Runs show a green checkmark ("success") despite producing no output.
Environment
- Plan: Max
- Platform: claude.ai/code/scheduled (web UI) and Claude Code CLI (RemoteTrigger API)
- Model: claude-sonnet-4-6
- MCP Connectors: Slack (mcp.slack.com), Gmail (gmail.mcp.claude.com), Google Calendar (gcal.mcp.claude.com)
Steps to Reproduce
- Create a remote scheduled trigger with a Slack MCP connector
- Give it a simple instruction: "Send a Slack DM to user U07FWP7TQCW with this message: 'test'"
- Run it manually — it works on the first run (the one immediately after creation)
- Wait for the next scheduled run, or trigger another manual run later
- The run shows a green checkmark but produces no output
Observed Behavior
Error 1 — MCP tools not loading:
The agent reports: "No Slack MCP tools are present in this environment (no slack_post_message, slack_send_dm, or similar tools were found)."
The Slack connector is configured on the trigger but its tools are not available to the agent at runtime. This means the agent cannot post messages, send DMs, or report errors — it fails completely silently.
Error 2 — Network proxy blocks outbound HTTP:
The agent reports: 403 Forbidden (host_not_allowed) when using curl to reach ag-precon-api.netlify.app (a Netlify Functions endpoint). The execution environment's network proxy does not allow the domain.
Error 3 — False success status:
Runs that fail due to the above issues still show a green checkmark in the run history. There is no indication of failure in the UI.
Timeline
- April 3, 2026: Created 4 triggers via the RemoteTrigger API. Initial runs on creation day worked — MCP tools loaded, curl reached external APIs, Slack messages posted successfully.
- April 4–6, 2026: All subsequent scheduled and manual runs failed silently. No Slack messages, no DMs, no errors surfaced to the user. Runs show green checkmarks.
- April 6, 2026: Diagnosed the issue by clicking into run transcripts in the web UI. Created a brand new trigger from the web UI with a fresh Slack connector — same failure. MCP tools did not load.
Triggers Affected
All 4 triggers on the account exhibit this behavior:
- AG Bid Inbox Scanner (hourly, M-F) — Slack + Gmail + Google Calendar connectors
- AG Daily Pipeline Update (weekdays 8:35am) — Slack connector
- AG Bid Status Alerts (weekdays 8:30am) — Slack connector
- AG Pipeline Health Check (weekdays 8:45am) — Slack connector
Plus a newly created test trigger (from web UI, fresh Slack connector) — same failure.
Expected Behavior
- MCP connector tools should be available to the agent on every run, not just the first
- The network proxy should allow outbound HTTP to domains that worked on initial creation
- Failed runs should not show a green checkmark — they should surface errors in the UI
Workaround
Currently running the same tasks manually from a local Claude Code CLI session, where all MCP tools and outbound HTTP work correctly. The issue is isolated to the remote trigger execution environment.
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the linked issues, though they share the same root cause (MCP tools not loading in remote trigger sessions).
This issue covers two additional failure modes that #43374, #42004, and #42228 do not:
403 Forbidden (host_not_allowed)whencurlhits custom domains (in this caseag-precon-api.netlify.app, a Netlify Functions endpoint). This is a separate infrastructure issue from MCP tool injection.The MCP injection bug is shared across all these issues, but the proxy blocking and false success reporting are distinct problems that warrant separate tracking.
---
For anyone hitting the MCP issue specifically, there's a workaround via #43320: spawn Agent subagents to call MCP tools by name. The main session can't see them, but subagents can. Add this to your trigger prompt:
This does not fix the network proxy or false success issues.
Adding a data point — same root issue, different use case.
I have a scheduled routine running a site audit against my own production
domain (
www.mycardvault.io). Every HTTP request from the routine returns:The intercepting TLS cert is issued by "Egress Gateway Subordinate CA",
not by Cloudflare (which actually fronts my site) — so the request is being
terminated at the routine's egress gateway before reaching the destination.
This is a routine-side deny, not a destination-side restriction. The same
URL responds 200 from any normal client and from my local Claude Code
session. (Detail not in the original report — may help whoever picks this
up.)
Six of eleven audit checks rely on live HTTP and have been silently
returning BLOCKED in every routine run since 2026-05-01. Like @<original
reporter>, the email path via Gmail MCP works fine — the block is selective
to non-MCP hostnames.
Adding the synthetic-monitoring / health-check use case to the pile in
addition to the Slack-MCP-tools-not-loading and Qase-API cases:
scheduled health checks against user-owned production domains is an
obvious legitimate use that's currently impossible.
(Filed #56845 separately, will close as duplicate of this.)
Three separate issues here:
1. MCP connector tools not loading. This was a bug on our side. Scheduled runs were starting the agent before MCP connectors finished connecting, so the tools weren't available when the agent looked for them. It was a timing race, which is why it was intermittent and the first run often worked. Fixed April 9; scheduled runs now wait for connectors before starting. If you still see this on runs after April 9, let us know.
2.
403 host_not_allowedon outbound HTTP. You're right that this is our egress proxy, not the destination. Scheduled routines run inside an Environment that restricts outbound network access to an allowlist. The default is "Trusted" (package managers and Anthropic services only), so your own domains are blocked while MCP connectors still work.Fix: open your routine at claude.ai/code/routines. Click the environment name next to the cloud icon (bottom-right of the Instructions box; likely "Default"). In the dropdown, hover over your environment and click the gear icon that appears. In the "Update cloud environment" modal, change Network access from "Trusted" to Custom and add your domain(s), or pick Full for unrestricted outbound. Save; the routine picks it up on the next run. Docs: https://code.claude.com/docs/en/claude-code-on-the-web#network-access.
3. Green checkmark on runs that didn't do anything. Run status currently reflects whether the session executed without a system error, not whether the task was accomplished. "No Slack tools found" and "every request returned 403" aren't system errors, so the run shows green. We're working on surfacing this better; for now the run transcript shows what actually happened.
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.