[BUG] Cloud scheduled tasks cannot access MCP connectors — tools not loaded into session

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/43173
2. https://github.com/anthropics/claude-code/issues/43374
3. https://github.com/anthropics/claude-code/issues/42522

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Additional data: MCP handshake completes at transport level, tools never register

I've been debugging the same issue from the CLI side (RemoteTrigger API) with a custom MCP server and can add some specifics about where the breakdown occurs.

Setup

• Self-hosted MCP server (Streamable HTTP, OAuth 2.1 + PKCE, Python CGI on Apache)
• Two connectors: "Atreides Email" (production, send_email) and "Test MCP" (minimal, ping → pong)
• Triggers created via both API and UI, connectors attached via both API and UI

What I can prove from server-side logs

Every time a scheduled task fires, the MCP server logs show a complete, successful handshake:

2026-04-04T04:38:52 MCP method=initialize
2026-04-04T04:38:52 MCP method=notifications/initialized
2026-04-04T04:38:53 MCP method=tools/list

The server returns valid tool schemas in the tools/list response. Bearer token is valid. No errors. But tools/call never follows — because the agent's ToolSearch returns "No matching deferred tools found."

What I tried (all failed)

| Approach | Result |
|----------|--------|
| sleep 10 then ToolSearch | No tools found |
| sleep 10, ToolSearch, sleep 10, ToolSearch (20s total) | No tools found |
| WebSearch + WebFetch + Bash first, then ToolSearch | No tools found |
| ToolSearch keyword mcp (broad search) | Only returned WebFetch (built-in) — zero MCP tools in registry |
| ToolSearch keyword ping | No results |
| select:mcp__Test-MCP__ping exact match | No results |
| Underscore variant mcp__Test_MCP__ping | No results |
| Different connector (known-working Atreides Email) in a new trigger | Same failure |
| Remove connector via UI → save → re-add → save | Same failure |
| Matching allowed_tools to a known-working trigger | Same failure |

The transport-registration gap

The platform establishes the MCP connection (transport layer works — server receives and responds to all protocol messages). But the tool schemas from tools/list are never injected into the agent's deferred tools registry. The agent literally cannot discover that MCP tools exist, regardless of query strategy or wait time.

A single user message into the session makes them appear instantly, confirming the tools can be registered — they just aren't during autonomous initialization.

Environment

• Plan: Claude Pro
• Platform: CLI (RemoteTrigger API) and claude.ai scheduled tasks UI
• Claude Code version: 1.0.33
• Custom MCP server (not a third-party connector)

+1 on this issue.

I'm experiencing the same behavior on Claude Code Web. I have Sentry and Trello MCP servers connected. In interactive sessions, all MCP tools load correctly and are fully functional. However, during scheduled/automatic runs, the MCP tools are not injected into the context at all.

When Claude runs on a schedule, it doesn't detect the MCP servers and incorrectly reports that no Sentry or Trello integrations are available. If I then interact with the same session manually, the MCP tools appear immediately via the deferred tools system.

This effectively makes scheduled tasks useless for any workflow that depends on MCP integrations. There's also no viable workaround on Claude Code Web since there's no persistent filesystem or secret storage to fall back on (e.g., calling APIs directly via curl isn't practical without a way to securely store tokens between sessions).

Environment:

• Claude Code Web (not local CLI)
• MCP servers: Sentry, Trello
• Both work perfectly in interactive sessions, fail silently in scheduled runs

A small update from mobile just because it may help folks - I found a workaround on web, thanks to a reddit users comment (ill link the post and credit the user later) - it'll cost a few extra tokens but if you start the scheduled task prompt by telling it to not do any work but instead to use an agent to do the entire task - everything works fine because the subagent gets mcp tools initialized properly. Then for now im telling it to have the subagent report a summary back up to the primary so I can look at its results in the task log.

Cost difference is probably negligible and it solves the problem until its formally fixed.

EDIT: Credit to /u/e_lizzle on reddit

I'm experiencing this as well. I tried creating scheduled tasks that search my app's error logs, create Github issues and submit pull requests with fixes. Doesn't work because Github MCP tools aren't available on the first prompt, but become available later if a second message such as "Try again" is sent by the user.

I find this surprising as Claude Code's docs specifically list use cases like this, which are not actually possible due to this limitation:

A few examples of recurring work you can automate: 1. Reviewing open pull requests each morning 2. Analyzing CI failures overnight and surfacing summaries 3. Syncing documentation after PRs merge 4. Running dependency audits every week

https://code.claude.com/docs/en/web-scheduled-tasks

Happening to me as well.

+1 on this issue. Last successful scheduled cloud task using mcp connectors was March 31st.

A small update from mobile just because it may help folks - I found a workaround on web, thanks to a reddit users comment (ill link the post and credit the user later) - it'll cost a few extra tokens but if you start the scheduled task prompt by telling it to not do any work but instead to use an agent to do the entire task - everything works fine because the subagent gets mcp tools initialized properly. Then for now im telling it to have the subagent report a summary back up to the primary so I can look at its results in the task log. Cost difference is probably negligible and it solves the problem until its formally fixed. EDIT: Credit to /u/e_lizzle on reddit

fascinating. confirmed this does in fact lead to a successful run. simply pasting "DO NOT DO ANY WORK. ASSIGN THIS TASK TO AN AGENT." as the first line in the instructions, and my scheduled job delivers the intended output again.

This issue is affecting me as well, but the sub-agent fix works

fascinating. confirmed this does in fact lead to a successful run. simply pasting "DO NOT DO ANY WORK. ASSIGN THIS TASK TO AN AGENT." as the first line in the instructions, and my scheduled job delivers the intended output again.

This worked for me too 🫶

I had to change the text to, "DO NOT DO ANY WORK. ASSIGN THE FOLLOWING WORK TO AN AGENT." and that worked for me. It's not stupid if it works 🤷.

Same. Not working

Ditto. Same issue on a custom MCP connector.

Experiencing the same issue for all my scheduled tasks as well as new remote sessions.

• Adding DO NOT DO ANY WORK. ASSIGN THIS TASK TO AN AGENT. to the top of the scheduled task instructions does seem to be the workaround.
• After performing a "Try again" reply, the remote session seems to regain access to the MCP servers.

<img width="771" height="968" alt="Image" src="https://github.com/user-attachments/assets/6a8735ab-a9ea-475f-bf6c-73bf2589e953" />

Duplicate of #35899

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.