### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Bug Description MCP connectors (Datadog, Atlassian/Jira) are not available to scheduled tasks when they fire automatically. The agent cannot see or ca

[BUG] Scheduled tasks cannot access MCP connectors until a user message warms the session

Resolved 💬 55 comments Opened Mar 18, 2026 by ivansmb Closed Apr 14, 2026

💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Bug Description

MCP connectors (Datadog, Atlassian/Jira) are not available to scheduled tasks when they fire automatically. The agent cannot see or call any MCP tools — they do not appear in the session's tool set. However, sending any user message into the same session immediately makes the connectors available and functional.

This is not a configuration issue. The connectors are properly connected and work perfectly in interactive chat. The problem is that scheduled task sessions do not initialize MCP connectors until a human interaction triggers the session.

Environment Info

Platform: Web (claude.ai)
Product: Claude in Chrome — scheduled tasks
Connectors affected: Datadog (search_datadog_monitors, analyze_datadog_logs, etc.), Atlassian/Jira (getJiraIssue, searchJiraIssuesUsingJql, createJiraIssue, etc.)
Connectors confirmed working: Yes, both work immediately after any user message in the same session

Key Observation

This is not a timing issue. Retries with delays don't help. The connectors are genuinely not wired into the session context until a user message arrives. The scheduled task runs in a context where MCP connector initialization simply doesn't happen.

Related Issues

#29022 — create_scheduled_task tool not injected into Cowork session context
#18194 — Cowork mode MCP connectors return 403 despite working in Claude Chat
#34832 — MCP connectors lose auth after context compaction in Cowork
#27159 — MCP tools not available to model despite successful registration

What Should Happen?

Scheduled tasks should have access to the same MCP connectors that are available in interactive chat sessions. The connectors should initialize when the scheduled task session starts, not when a human interacts with it.

Error Messages/Logs

Scheduled tasks fire with no MCP connectors available. All MCP tool calls fail. Sending any user message immediately initializes the connectors and everything works.

Steps to Reproduce

Connect Datadog and Atlassian MCP connectors at claude.ai/settings/connectors
Verify both work in a normal interactive chat (e.g., "search Jira for PVZAZ-1444" → works)
Create a scheduled task that calls MCP tools as its first action (e.g., search_datadog_monitors and getJiraIssue)
Let the scheduled task fire on its cron schedule
Observe: The agent reports MCP tools are not available / not in the session
Send any message into the session (e.g., "use jira to retrieve a single task")
Observe: The exact same MCP tools now work immediately

What I've Tried (prompt engineering — none of these work)

Attempt 1: Explicit tool instructions

Added "You already have Datadog and Jira MCP connectors" with tool prefixes — agent still introspected its tool list, found nothing, and bailed.

Attempt 2: "Never inspect tools, just call them"

Added aggressive instructions: never call search_mcp_registry, never claim tools are missing, never suggest reconnecting, just call the tools directly. Agent still could not see or invoke any MCP tools after 5 retry attempts with 20-second delays.

Attempt 3: Retry with backoff

Added warm-up probes (search_datadog_monitors + getJiraIssue) with 5 retries, 20-second delays. All 5 attempts failed. Then a single user message made everything work instantly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.78

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is all in the Claude MacOS app (Claude 1.1.7053 (cc1949) 2026-03-16T22:55:50.000Z)

View original on GitHub ↗

55 Comments

ivansmb · 4 months ago

Digitpixels · 3 months ago

<html>
<body>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Same issue here — with a custom MCP server (not just native connectors)</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I'm running an autonomous crypto trading bot via Cowork scheduled tasks (3 tasks/day: 07h, 12h, 20h). My setup uses two MCP connectors:</p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>Supabase MCP</strong> (native connector) — PostgreSQL database</li>
<li class="whitespace-normal break-words pl-2"><strong>Custom MCP Trading Server</strong> — self-hosted on a VPS (Python FastMCP, Docker, HTTPS, Bearer token auth) connected to the Binance API</li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Failure pattern (identical to what's described in this issue)</h3>
<div class="overflow-x-auto w-full px-2 mb-6">
Date | Task | What happened
-- | -- | --
2026-03-30 07:00 | Task 1 (morning) | ToolSearch returns empty — no MCP tools found. Task aborted.
2026-03-31 20:00 | Task 3 (evening) | ToolSearch returns HTTP 500 (API Error: Internal server error). Task aborted.
2026-04-01 07:00 | Task 1 (morning) | ToolSearch returns empty — no MCP tools found. Task aborted.

</div>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">The "warm session" behavior — confirmed</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">On 2026-04-01, after the scheduled task failed at 07:00:</p>
<ol class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>09:50</strong> — I opened the same conversation and typed "reprend" (resume). Claude ran 6 ToolSearch queries with various keywords (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">get_portfolio</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">execute_sql</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">binance</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">supabase</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">mcp</code>, etc.) → <strong>all returned empty</strong>. Both MCP connectors invisible.</li>
<li class="whitespace-normal break-words pl-2"><strong>~09:55</strong> — I replied "pourtant le MCP est bien disponible" (the MCP is available though). Claude searched again → <strong>tools found instantly</strong>. Full task executed successfully.</li>
</ol>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Nothing changed between step 1 and step 2 — no server restart, no config change. The MCP servers were up the entire time (confirmed by successful calls once tools were found).</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Key detail: this is intermittent</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Many of my scheduled tasks have executed successfully over the past weeks. The bug doesn't trigger every time — maybe 1 in 5 or 1 in 10 runs. This makes it look like a race condition or timing-dependent initialization issue rather than a fundamental missing feature.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Evidence that MCP servers are NOT the problem</h3>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">When ToolSearch finds the tools, every MCP call succeeds immediately (portfolio, SQL queries, technical analysis, order placement)</li>
<li class="whitespace-normal break-words pl-2">My VPS server has 100% uptime during these failures (verified via direct HTTP health checks)</li>
<li class="whitespace-normal break-words pl-2">Both native (Supabase) AND custom (VPS) connectors fail simultaneously → the issue is in the session's tool initialization, not in any specific connector</li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Environment</h3>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>Platform</strong>: Cowork (Claude desktop app, macOS)</li>
<li class="whitespace-normal break-words pl-2"><strong>Model</strong>: Claude Opus</li>
<li class="whitespace-normal break-words pl-2"><strong>Plan</strong>: Claude Max</li>
<li class="whitespace-normal break-words pl-2"><strong>MCP connectors</strong>: Supabase (native) + custom FastMCP server on VPS (streamable HTTP transport)</li>
<li class="whitespace-normal break-words pl-2"><strong>Scheduled tasks</strong>: 3x daily via Cowork <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/schedule</code></li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Impact</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This is a trading bot managing real money. When a scheduled task silently fails because MCP connectors aren't initialized, no market analysis or risk management is performed. For automated workflows that depend on scheduled execution, this bug makes the feature unreliable.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Workaround</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">None that actually prevents the failure. I've added cross-task verification: each task checks if the previous task produced its expected output, and logs a critical alert if not. This at least surfaces the failure — but doesn't fix it.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">A fix or even an acknowledgment from the team would be greatly appreciated. This seems to be affecting a growing number of users relying on scheduled tasks + MCP.</p>
</body>
</html>

patant · 3 months ago

[BUG] MCP tools not available in scheduled tasks — only connect after manual interactive prompt

Description

MCP tools (specifically Slack) are never discovered during scheduled task execution, even with explicit retries and delays. The same MCP tools connect successfully in interactive sessions after a second manual prompt.

Steps to Reproduce

Configure Slack MCP server connection in Claude Code
Create a scheduled task that uses Slack MCP tools
Run the scheduled task

Attempt 1 — Default behavior

The task runs ToolSearch for Slack tools. No Slack MCP tools are found. Manually prompting "list again" in the same session causes Slack tools to appear (13 tools).

Attempt 2 — Retry with prompt instruction

Added to task prompt: "Before doing anything, run ToolSearch for Slack tools. If no Slack tools are found, wait a few seconds and try again."
Result: First attempt finds nothing, second attempt finds nothing. Tools never connect.

Attempt 3 — Aggressive retry with explicit sleep

Added to task prompt: "First, run sleep 10 via Bash, then search for Slack tools. If still not found, sleep 10 again and retry up to 3 more times."
Result: 4 attempts with 10-second Bash sleeps between each (40+ seconds total). Slack tools were never discovered.

Expected Behavior

MCP tools configured in the user's settings should be available to scheduled tasks, either by waiting for MCP server connections to be established before task execution begins, or by re-scanning when tools are requested.

Actual Behavior

Scheduled tasks: MCP tools are never available, regardless of retries or delays.
Interactive sessions: MCP tools are not available on the first prompt but appear after a second manual prompt (suggesting the interactive message loop triggers an MCP reconnection/re-scan that scheduled tasks cannot replicate).

Environment

Product: Claude Code (mac app)
MCP server: Slack (via claude.ai connection)
Task type: Scheduled task

Analysis

The issue appears to be that scheduled tasks do not trigger the same MCP server initialization/connection flow that interactive sessions do. In interactive mode, a second user message seems to cause a re-scan that picks up the now-connected MCP server. Scheduled tasks have no equivalent mechanism — they execute their prompts but cannot trigger this re-initialization, so MCP tools remain permanently unavailable for the duration of the task.

A potential fix could be:

A "wait for MCP ready" gate before scheduled task execution begins
Automatic MCP re-scanning when ToolSearch returns no results for a configured server
An explicit MCP initialization step that scheduled tasks can invoke

stringbeans · 3 months ago

i have the same issue with sentry/slack connectors and scheduled jobs. interestingly enough this seemed to only start happening a few days ago...

cherron · 3 months ago

This is a legitimate issue. Experiencing for Gmail with Claude Code (Web) Scheduled Tasks.

riya-amemiya · 3 months ago

This problem is still occurring 😢

mohamedlaayouni · 3 months ago

Having the same issue for Slack and Linear on remote scheduled tasks

SelcukTekin · 3 months ago

Same issue here (for slack), defeats the whole purpose of having a scheduled task for me

tdfirth · 3 months ago

Same issue for me

dark-star-bot · 3 months ago

Adding another data point. I'm experiencing the same issue as of April 2, 2026.

Setup: Scheduled task on Claude Code web (claude.ai/code) with 5 MCP connectors attached: Slack, ms365, Google Calendar, Gmail, Circleback.

Behavior:

Scheduled runs and "Run now" runs: all 5 connectors fail to load. ToolSearch returns "No matching deferred tools found" for all of them, even after retries with 10-second waits (tried up to 3 retries).
Interactive sessions in the same environment with the same connectors: all connectors load fine and work normally.
Disconnecting and reconnecting all connectors (fresh OAuth credentials) did not fix the issue for scheduled/Run Now sessions, though connectors continued to work in interactive sessions.

Additional context:

This started after the March 31, 2026 connectors incident (where connectors were removed from organization allowlists).
The same scheduled task with the same connectors worked correctly prior to ~March 31.
The "Run now" button appears to create the same session type as a scheduled run (not interactive), and connectors fail in both cases.

This is blocking automated workflows that depend on MCP connectors (e.g., daily briefings that pull from Outlook calendar, email, Slack, and Circleback).

hirotaka-iwasaki · 3 months ago

+1 — experiencing the same issue.

Setup:

Slack connector connected at account level and attached to the trigger
Trigger visible in UI with Slack connector badge

Symptoms:

ToolSearch returns "No matching deferred tools found" for all Slack-related queries (slack, mcp, +mcp, select:mcp__slack__*)
Direct curl to slack.com blocked by egress proxy (403 Forbidden - host_not_allowed), confirming Slack access is only possible via MCP connector
Manual execution from the dashboard also fails (same ToolSearch result)
This was previously working — the trigger successfully created fix PRs via Slack MCP

Tried:

Disconnected and reconnected Slack connector
Created a brand new trigger with Slack connector attached
Attempted curl fallback to Slack Web API (blocked by egress proxy as expected)

None of these resolved the issue. The connector appears attached in the UI but is not initialized/injected into the remote session.

mase-kun · 3 months ago

Same issue here. Notion MCP connector configured on trigger with mcp_connections, tools set to "Always allow" in connector settings. Remote session starts but cannot find any MCP tools. Works fine in local/interactive sessions. Started failing around April 1, 2026. Trigger updated_at shows execution occurs, but agent logs show "MCP tools not found."

BryanEddy5 · 3 months ago

Experiencing the same issue as of April 2, 2026.

Setup

Platform: claude.ai/code — scheduled triggers (CCR remote sessions)
Model: claude-sonnet-4-6
Connectors attached to trigger: Incident.io, Atlassian/Jira, Slack
Trigger ID: trig_01KyPnrjPXWTwWHRVdApgUKS
Environment: Anthropic Cloud (env_0172ZSTeVoTtNCnfjXr8UppX)

All three connectors work correctly in interactive sessions on claude.ai.

Steps to Reproduce

Go to https://claude.ai/settings/connectors and verify Incident.io, Atlassian, and Slack connectors are connected and working
Create a scheduled trigger via RemoteTrigger API with mcp_connections referencing all three connectors (connector UUIDs, names, and URLs)
Use "Run now" or wait for the cron schedule to fire
Observe: the remote agent session starts but no MCP tools are available

What I tried (prompt engineering — none of these work)

Attempt 1: ToolSearch with keyword queries

Added Step 0 to the prompt: run three ToolSearch calls before doing anything else:

ToolSearch: "incident list follow up"
ToolSearch: "Jira search issues JQL Atlassian"
ToolSearch: "Slack search users send message"

Result: All three ToolSearch calls completed but returned only general-purpose tools (TodoWrite, WebSearch, AskUserQuestion, WebFetch, RemoteTrigger). No MCP connector tools found.

Attempt 2: Explicit MCP connector instructions

Told the agent it has MCP connectors available with tool names like incident_list, searchJiraIssuesUsingJql, slack_send_message. Told it not to use curl.

Result: Agent searched for these tool names via ToolSearch, found nothing, concluded the MCP servers weren't configured, and stopped with setup instructions for the user.

Attempt 3: Direct tool name invocation (bypass ToolSearch)

Told the agent to call tools directly by their full mcp__claude_ai_* names without using ToolSearch:

mcp__claude_ai_Incident_io__incident_list
mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql
mcp__claude_ai_Slack__slack_send_message

Result: Not yet tested, but based on other comments in this thread, likely to fail since the tools are not injected into the session context at all.

Expected Behavior

The mcp_connections attached to the trigger should initialize the MCP connector tools in the remote session so ToolSearch can discover them (or they are callable directly).

Actual Behavior

MCP connector tools are completely absent from the session. Only base tools are available. The connectors appear attached in the trigger config but are not initialized in the CCR session.

Impact

This blocks a daily incident awareness briefing that pulls Sev1/Sev2 incidents from incident.io, cross-references with Jira tickets, and sends a formatted Slack DM. The prompt, schema, and trigger are fully built — blocked entirely by this initialization bug.

riya-amemiya · 3 months ago

I made an interesting discovery that might help unblock some of you. It turns out sub-agents can still access MCP connectors.

Workaround Prompt Example:

"Do not call MCP tools directly. Instead, create a sub-agent and instruct it to use the [Slack/Jira/Datadog] MCP tools to gather the information, then report back to you."

While this isn't a root cause fix, it’s a functional workaround to keep scheduled tasks running until the Anthropic team patches the main agent's initialization issue!

max-csr · 3 months ago

@riya-amemiya thanks the sub-agent workaround worked for me too!
It now triggers connectors (GCal, Slack, Notion), testing it now with MCPs

Hoping the CC team figures out a long-term fix soon!

404sand808s · 3 months ago

+1 — Hitting this with a daily scheduled task (claude.ai/code, /schedule trigger) that uses remote MCP connectors (Notion, Google Calendar, Gmail, Hindsight, GitHub).

Tools return "No such tool available" at session start, briefly appear ~1 min later, then disconnect before any calls succeed. If I manually open the session and send a message, the tools reconnect and work fine. Same connectors work perfectly from the desktop app.

rakeshvmehta · 3 months ago

+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

ashwin-ant collaborator · 3 months ago

We have a fix on the way for this.

aidanouckama · 3 months ago

We have a fix on the way for this.

Thank you! 🙏

harshamverve · 3 months ago

We have a fix on the way for this.

Is this patched?

Adamruns · 3 months ago

We have a fix on the way for this.

Any update or ETA?

ashwin-ant collaborator · 3 months ago

The fix was deployed around 11am Pacific time today (April 7). Are people still seeing the issue even after that? If so, please include a session id (this is in the URL of the page with the conversation, looks like session_011Z3...).

mattfelten · 3 months ago

@ashwin-ant I just ran a job that hits an MCP server first thing and it's still not being found. Subagent worked though, and after the subagent came back, the main agent said it now could access all MCP servers.

session_01LmQ68X7Spe1ErkiYJdGzet

It could just be an async loading delay, which is what I thought it was originally before I found this thread. I'll test that.

ashwin-ant collaborator · 3 months ago

That's helpful context, we're digging in a bit more.

mattfelten · 3 months ago

@ashwin-ant i just ran the scheduled job again with a modified prompt to do 3 tries on the main agent with delays and then fallback to a subagent, to rule out a timing issue.

Main agent never got access to the MCP server. Subagent got there first try.

session_01QTWEro8zLs2Q4mZZavPjNp

Hope that helps.

harshamverve · 3 months ago

the sub agent trick worked 0 thanks @mattfelten. @ashwin-ant - hope to get a fix though.

ashwin-ant collaborator · 3 months ago

@mattfelten we've identified another issue, thanks for the additional detail!

mattfelten · 3 months ago

@ashwin-ant No problem. I accept payment in the form of free months of Max subscriptions 😁

ashwin-ant collaborator · 3 months ago

Hey all, this fix is now deployed. It was an underlying race condition in Claude Code's MCP logic, and the latest version of CC has the fix (and thus scheduled tasks has the fix as well). Would love to get confirmation that it's working for people so we can close this out 😄

ivansmb · 3 months ago

This is working for me now, thank you very much.

dankins · 3 months ago

This is still not working for me. Session ID session_012XFx5XJayxZwMq7e2q9UTW

On the first message it cannot find the Linear tools, but after immediately asking to try again it is able to find them

stringbeans · 3 months ago

not working for me yet either... session_018wFyV8nMdw6Awk8MCgftxz

in my system prompt i even instruct to "sleep(60)" before asking what tools are available in case theres a warmup period but it doesnt seem to help

cvanes · 3 months ago

Not working here either - kicked off a scheduled task via web and desktop (macOS upgraded to latest version a few minutes ago) in a new session and neither could find MCP tools.

Session ID: session_01Gdg3K2EMdMPLv52Mk4gtN7

ashwin-ant collaborator · 3 months ago

Apologies, the fix is actually going out tomorrow (my mistake). We will resolve this!

hatef-palizgar · 3 months ago

Sub-agent workaround confirmed working (April 9, 2026)

Adding to the workaround discussion — I got this fully working for a scheduled trigger that uses Granola, Slack, Google Calendar, Gmail, and Atlassian MCP connectors. Using Claude Code v2.1.98.

The key missing piece nobody mentioned: you must add "Agent" and "ToolSearch" to allowed_tools in your trigger's session_context. Without these, the remote agent can't even spawn sub-agents to work around the bug.

"allowed_tools": [
  "Bash", "Read", "Write", "Edit", "Glob", "Grep",
  "WebFetch", "WebSearch",
  "Agent", "ToolSearch",
  "mcp__*"
]

Then prepend your prompt with instructions to delegate all MCP work to sub-agents:

IMPORTANT — MCP TOOL LOADING WORKAROUND:
Due to a known bug, MCP tools may not be visible to you directly.
You MUST delegate ALL MCP-dependent work to sub-agents using the Agent tool.
Do NOT attempt to call MCP tools yourself in the main agent. Instead:
1. Spawn a sub-agent for each MCP-dependent task.
2. Inside each sub-agent, have it search for and load MCP tools
   (e.g. use ToolSearch for mcp__*) before doing any work.
3. If a sub-agent doesn't see MCP tools on the first attempt,
   have it retry ToolSearch once more.
4. Only proceed with MCP calls once the sub-agent confirms the tools are loaded.

I also structured my prompt with an explicit execution plan telling the agent which sub-agent to spawn for each step (calendar fetch, Granola lookup, Slack search, Slack send) — this helped it follow the pattern consistently rather than trying MCP calls in the main agent first.

Hope this helps others until the fix fully lands.

ashwin-ant collaborator · 3 months ago

A few additional questions, since our telemetry suggests there may be more than one thing going on:

Did you see zero MCP tools, or were some servers present and others missing?
Was it missing only on the first message/run, or still missing after a follow-up message in the same session?
Was this a scheduled/force-run trigger, or an interactive session in the web UI?
If you open a fresh interactive session with the same MCP config and run /mcp, does it show your servers as connected?

samgutentag · 3 months ago

Still reproducing on Claude Code 2.1.98, Max plan, 2026-04-09.

Scenario: Two existing triggers (trig_01KC1UsdbDughgD2meHU2cZu deploy-watcher, trig_01FyRboyvtnHKv36QaJv7wRx daily-devrel-scanner) with Slack, Linear, Slite, and trunk docs connectors attached. Triggers originally created 2026-04-06.

What fails:

ToolSearch query: "Slack" returns "No matching deferred tools found" during scheduled task execution
Same for Linear, Slite, and trunk docs
Connectors are correctly listed in both the web UI and the API response (\GET /v1/code/triggers/{id}\ shows them with \permitted_tools: []\)

Web UI workaround attempt:

Removed all four connectors via the web UI — worked
Tried to re-add connectors via the web UI — button click does nothing, no OAuth flow starts, no connectors added
Had to reattach connectors via \POST /v1/code/triggers/{id}\ with \mcp_connections\ array
Even after API-based reattachment, the next run still couldn't find the tools

Fresh trigger test:

Created a brand new trigger (\trig_013YmVqLYegBMAQxpxRrjdw9\ deploy-watcher-v2) via API with the same connector UUIDs
Same empty \ToolSearch\ results

This means the issue is not limited to old/stale triggers. A freshly created trigger with connectors attached via API also fails to load MCP tools at runtime.

Related: #45306, #43661, #44796 appear to be the same root cause.

samgutentag · 3 months ago

Update: the sub-agent workaround from @hatef-palizgar works (https://github.com/anthropics/claude-code/issues/35899#issuecomment-4217969223)

Set up two new triggers using that pattern. Daily scanner ran successfully end-to-end after repeatedly failing with direct MCP calls earlier today. Sub-agents can see the MCP tools. The main agent still cannot.

What I changed:

Added Agent and ToolSearch to session_context.allowed_tools
Rewrote the prompt so the main agent handles git, bash, and curl directly, and delegates every MCP-dependent step to a sub-agent via the Agent tool
Each sub-agent uses ToolSearch to find the MCP tool name, then calls it

Working trigger: trig_01D3xu4LiBfefTQ2tpX31p3r (daily-devrel-scanner-v2). Viewable under my account at claude.ai/code/scheduled.

Questions from @ashwin-ant (https://github.com/anthropics/claude-code/issues/35899#issuecomment-4218319600) weren't aimed at me, but in case the data points help:

Zero or partial? Zero. ToolSearch returned "No matching deferred tools found" for all four connected services (Slack, Linear, Slite, trunk docs) in the main agent. Same four loaded fine inside spawned sub-agents.

First message only, or still missing after a follow-up? Can't test this one. The triggers are autonomous with persist_session: false, so there's no way to send a follow-up into the scheduled session. The sub-agent workaround sidesteps the question.

Scheduled trigger or interactive session? Both force-run (via POST /v1/code/triggers/{id}/run) and scheduled runs hit it. I also created a brand new trigger from scratch via the API, and it failed the same way on its first run. Not a staleness issue.

Fresh interactive session with /mcp? Haven't tested that specifically, but the same connectors work fine in my interactive claude.ai and Claude Code CLI sessions. I use Slack, Linear, Slite, and trunk docs via MCP all day. The breakdown is specific to scheduled/remote trigger sessions.

Side observation, possibly a separate bug: after removing all four connectors from a trigger via the web UI, the "add connector" button stopped responding. No OAuth flow, no error. Had to reattach via the POST /v1/code/triggers/{id} API with mcp_connections to restore them.

ashwin-ant collaborator · 3 months ago

2.1.101 is out with the fix as of a few minutes ago. Are people still able to repro?

OLI9292 · 3 months ago

Working for me now @ashwin-ant

samgutentag · 3 months ago

Gah so close for me, using the web interface at https://claude.ai/code/scheduled im still not able to add a connector to existing scheduled tasks or new ones. By default new tasks include all my connectors, which is fine for now, but if I remove one I can not re-add it, and I can not add new connectors to existing tasks at all with the same "doesnt do anything when i click it" behavior. hopefully the attached gif helps fill in the gaps of my summary there 😆

!Image

ashwin-ant collaborator · 3 months ago

@samgutentag that looks like a separate issue (also worth fixing). Feel free to file that, but this issue is specifically for MCP servers failing to connect once the session actually starts.

SelcukTekin · 3 months ago

@ashwin-ant I set up a very basic workflow asking it to list all slack channels using the slack MCP, and it still can't find it. Here's a session number for you, hope it helps: session_01QJ7ekoBMw1wPm3pzB5kwgq. If it helps: this was a manual run

ashwin-ant collaborator · 3 months ago

@SelcukTekin it's possible the tools hadn't loaded on the first turn but loaded afterward. Does the session still not show any tools found?

SelcukTekin · 3 months ago

@ashwin-ant It's still happening at the start of every manual run if that's what you mean.

Here's some session id's that were all called back to back (waiting for the previous one to finish each time)
session_01TEED8bYCiNEPW7LSWtAsCn
session_016qktA3wp55cg8bMfx9f2Fs
session_01GsZd4e4GRwZQ9zb5FC224q

There was some time in between me warming the session in some of these sessions (with a late "And now" message). As you can see it still wasn't available after those messages (because i assume the session was not warm), afterwards it was immediately available. Maybe that's a clue?

SelcukTekin · 3 months ago

Here's one scheduled run (of the same workflow), has the same issue: session_01GTgW4zCRpdTgCrYbkBvbR1

sean-lynch · 3 months ago

Actually appears to be working for me just fine now (wasn't working 4 hours ago when I was testing this).

dotscottdotscot · 3 months ago

Workaround

I was able to get my scheduled jobs running with tools again by changing settings on claude.ai

Settings -> Capabilities -> Tool Access

Set to 'Tools already loaded'.

It's not ideal as it blows out the context on my other Claude interactions, but if your scheduled jobs are critical then this is a workaround to get them running again.

cvanes · 3 months ago

Looks to be resolved for me - my scheduled task ran this morning with access to tools.

SelcukTekin · 3 months ago

The update that just hit seems to have solved the issue for me as well now (2.1.105)

ashwin-ant collaborator · 3 months ago

Closing now since we haven't gotten any more reports. Feel free to open a new issue if this comes up again, and thanks again for the valuable debugging info!

eran-medan · 3 months ago

@ashwin-ant this still happens to me (intermittently)

ashwin-ant collaborator · 3 months ago

@eran-medan could you provide session ids?

eran-medan · 3 months ago

@eran-medan could you provide session ids?

@ashwin-ant thanks for the reply, this is the most recent session id session_01CtPS4XG3d1h7s7tGrg7Z1U (it might be before your recent release so maybe you did fix it... I'll let you know if it happens again on the next scheduled run... )

github-actions[bot] · 2 months ago

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.