›_ Claude Code Issues
Claude Code Issues / #61015

[BUG] Scheduled routines fail every MCP tool call with "MCP tool call requires approval" on custom connectors (regression ~2026-05-20)

Resolved 💬 38 comments Opened May 21, 2026 by lucidlearning314 Closed May 21, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet. Related but distinct: #58757 (Bypass Permissions in CLI blocks requiresUserInteraction MCP tools). This report is for the claude.ai scheduled routine surface, reachable from Claude Code via /schedule and the RemoteTrigger tool.
  • [x] This is a single bug report.
  • [x] I am using the latest version of Claude Code.

What's Wrong?

Around 2026-05-20, scheduled claude.ai routines that use a custom MCP connector silently stopped completing their work. Every MCP tool call inside the routine fails with:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval

There is no human in the loop on a scheduled routine, so the call never gets approved and the routine effectively no-ops. The routine itself fires (visible in last_fired_at), but nothing the routine was supposed to write to the connector ever lands.

The same connector works perfectly from every interactive surface:

  • Claude Code on a local Mac
  • Claude Code on a remote Linux box (this is where I'm filing from — used mcp__claude_ai_Notes_Remote_MCP__list_notes and read_note half a dozen times in the session)
  • claude.ai chat

So the bug is scoped to the routine surface + custom MCP connector combo. First-party connectors (Linear, Granola) in the same routine slot don't appear to be affected.

Steps to Reproduce

  1. In claude.ai, register a custom MCP connector (mine is a Railway-hosted Obsidian server fronted by Auth0 OAuth — anything with the standard OAuth-protected-resource handshake will reproduce).
  2. Confirm it works from chat: ask Claude to call any tool on it, approve once.
  3. Create a scheduled routine that uses the connector. Easiest repro via POST /v1/code/triggers with body shape:

``json
{
"name": "mcp-smoke",
"cron_expression": "0 0 1 1 *",
"enabled": true,
"mcp_connections": [{
"connector_uuid": "<uuid>",
"name": "<connector name>",
"permitted_tools": ["list_notes", "read_note", "create_note", "update_note"],
"url": "<server url>"
}],
"job_config": {
"ccr": {
"environment_id": "<env id>",
"events": [{ "data": { "message": { "content": "Call list_notes(folder=\"foo/\") then create_note(...) and reply 'ok'.", "role": "user" }, "type": "user", "uuid": "...", "session_id": "" } }],
"session_context": { "allowed_tools": ["Bash"], "model": "claude-opus-4-7" }
}
}
}
``

  1. Fire the routine manually via POST /v1/code/triggers/<id>/run.
  2. Observe: routine "ran" (200 response), but list_notes / read_note / etc. fail with the approval error and nothing gets written.

What Should Happen

A scheduled routine, by definition, runs unattended. If the user has attached an MCP connector to a routine — and especially if permitted_tools is explicitly populated on the routine's mcp_connections entry — that should be a standing grant for those tools when the routine fires. Anything else makes scheduled routines + custom MCP connectors structurally unusable.

What I Tried (none of which fixed it)

  1. Disconnected and reconnected the connector in claude.ai → Settings → Connectors. Interactive surfaces stayed working; routines stayed broken.
  2. PATCHed mcp_connections.permitted_tools on an existing routine via POST /v1/code/triggers/<id> to explicitly list the tool names. Server accepted the update, but the routine still fails the same way on next fire.
  3. Created a brand-new routine via API with permitted_tools populated at creation time, same connector UUID. Same failure. This rules out "old routines hold a stale grant" — newly created routines reproduce immediately.
  4. Looked for a per-tool "Always allow" / "Trusted for routines" toggle in the Connectors UI, the Routines/Skills editor, and via a fresh approval flow in chat. Nothing changes the routine behavior.

Environment

  • Surface: claude.ai scheduled routines (/v1/code/triggers), invoked through Claude Code's /schedule skill and RemoteTrigger tool.
  • Connector: custom MCP server, OAuth-protected (Auth0). Endpoint returns 401 to anonymous probes (correctly) and 200 to interactive calls (correctly).
  • Claude Code version: latest.
  • Failure window: started between ~14:00 UTC 2026-05-19 and ~14:00 UTC 2026-05-20.
  • Cross-routine confirmation: at least two unrelated routines on the same account, with different prompts but the same custom connector, simultaneously stopped writing on those dates. So it's not a routine-specific config drift; it correlates with a platform change.

Error Messages / Logs

The only surfaced error is the one quoted above:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval

It is visible when the routine is run; there is no further detail in the API response, and last_fired_at does not update on manual run calls (separate minor issue).

Suggested Fix

  1. Treat a routine's attached connector as a standing grant for the tools listed in mcp_connections[].permitted_tools. Routines are by construction non-interactive; gating them behind a separate approval flow makes them dead-on-arrival.
  2. If a stricter policy is intended, surface the gate as a user-visible setting (per-connector or per-routine, "Trusted for unattended execution") and document the migration. Right now the only error returned is "requires approval", with no path the user can take to grant that approval for an unattended context.
  3. Cross-reference #58757 — the underlying gating logic is plausibly the same and a unified fix may address both.

Impact

Routines that use custom MCP connectors are the only practical way to drive multi-step, vault-style automations on claude.ai today. For me this powers a daily journaling/dispatch system that's been broken for two days. The workaround is to move the workload off claude.ai routines entirely and run it as local cron against the same connector — which works fine, but defeats the point of having claude.ai routines.

View original on GitHub ↗

38 Comments

github-actions[bot] · 1 month ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/47180

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

shunsukekono · 1 month ago

+1 — reproducing on the Notion connector (first-party in Customize, not a self-hosted MCP).

The routine settings UI states that tools from attached connectors can be used during execution without requesting approval (paraphrasing — I'm on the Japanese locale). Despite that, the routine fails at runtime with MCP tool call requires approval on mcp__Notion__notion-fetch. The container's settings.json only contains "allow": ["Skill"], and there is no UI surface for the user to grant MCP-tool approval.

So this isn't limited to custom OAuth connectors — it also affects the Notion first-party connector attached via Customize, and the UI's own stated guarantee appears to be violated.

Leonnikishaev · 1 month ago

"Same issue. Gmail, Google Calendar, and Microsoft 365 connectors. Started today. All connectors are added to the routine with the no-approval banner confirmed."

wjeroen · 1 month ago

For me this doesn't just happen with custom MCPs, but also with the standard Gmail and Google Calendar MCPs. What is the point of this feature if we can't use MCPs? Even when I am present, no UI prompt to approve requests appear. All my relevant connector settings are set to "always allow".

Damecek · 1 month ago 
Used Atlassian: searchJiraIssuesUsingJql
cloudId: afbd1aaa-56d7-4xxxxd751ca2d7
fields: ["summary","status"]
jql: project IN (Salxxxxrce, Caxxxgo, "ExxxM") AND status changed BY (5e1f2xxxxd10b0, 612f73cxxx560, 63fexxx9ad4, "7120xxx4544", 6183ba7xxxe39, 63b2ce75xxxb6d, 6035xxx10) AFTER "2026-05-19" ORDER BY updated DESC
maxResults: 100
Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval
Used Atlassian: searchJiraIssuesUsingJql
cloudId: afbd1aaa-56xxx1d751ca2d7
fields: ["summary","status","creator","created"]
jql: project IN (Salxxxorce, Caxxx, "ExxxM") AND creator IN (5e1f2bxxx0b0, 612f7xxx60, 63fe6xxxc9ad4, "7120xxxxef4544", 618xxx9, 63b2cxxx430b6d, 60352bxxx0) AND created >= "2026-05-20" ORDER BY created DESC
maxResults: 100
Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval
I'm unable to query Jira — every call to the Atlassian MCP tool is being rejected with "MCP tool call requires approval". Please approve the Atlassian MCP tool (or grant it always-allow permission)
kai-cupist · 1 month ago

I am also experiencing the same issue when calling the Slack connector (MCP).

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval
alefebv · 1 month ago

+1, same regression on first-party Datadog and Slack connectors (claude.ai EU). A routine that had been running fine for 6 days started failing on 2026-05-20 with MCP tool call requires approval on every MCP call.

Local CLI from the same account can call mcp__claude_ai_Datadog__* and mcp__claude_ai_Slack__* without issue, so the OAuth grant is intact — the failure is scoped to the routine surface.

aamaterasu91 · 1 month ago

+1, experience the same issue when using Slack Connector.
Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval

aviseth · 1 month ago

+1, with slack and sentry

mkocztorz · 1 month ago

I wanted to report, but since its done already I will just attach here. Same routine was working yesterday. When I asked claude to find solution it kept insisting on working on permissions - which makes no sense in routines as I understand. Same behaviour on desktop and web client.

Title: MCP tool calls fail with "MCP tool call requires approval" inside Routine sessions on claude.ai/code

Description:

When a Routine runs on claude.ai/code (remote execution environment), MCP tool calls fail with the following error despite Routines being documented to run without confirmation prompts:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval
Environment:

Claude Code on the web (claude.ai/code)
Remote execution environment (ephemeral container, no local filesystem access)
Session type: Routine (automated, scheduled)
MCP servers affected: Slack (mcp.slack.com/mcp), Atlassian
Model: claude-sonnet-4-6
Steps to reproduce:

Configure a Routine on claude.ai/code that uses MCP tools (Slack, Atlassian)
Run the Routine
Observe MCP tool calls fail with MCP tool call requires approval
Expected behavior:
Routines run autonomously without any confirmation prompts. MCP tool calls should execute without requiring approval, by definition of how Routines work.

Actual behavior:
Every MCP tool call is blocked by Claude Code's internal permission check and throws MCP tool call requires approval. The Routine cannot proceed.

Workaround attempted:
Writing ~/.claude/settings.json with "defaultMode": "bypassPermissions" and MCP tool allow rules — this has no effect because the remote container is ephemeral and the settings file is not read mid-session. There is no persistent filesystem access in remote sessions to apply a fix.

Impact:
Routines that rely on MCP tools are completely non-functional in remote sessions.

seanhandley · 1 month ago

Seeing this behaviour today too. Nothing changed my end but none of my connectors are authorising as expected.

cw-trustpilot · 1 month ago

I'm also seeing this with my routines when they are trying to use Slack, Google Calendar and Atlassian connectors. It was working yesterday afternoon and it was this morning my daily routines all started failing.

PathKnower · 1 month ago
  • 1 on report, had a few ruined routines tonight. Looking forward to be fixed
kunchen-cookiy · 1 month ago

+1 on gmail..

tdesai-eightfold · 1 month ago

+1 Slack,Jira

samirmhsnv · 1 month ago
  • 1 Linear
JackOfSpade · 1 month ago

+1 Google Calendar

robertyoung2 · 1 month ago

+1 Google Drive

AviyaGmara · 1 month ago

+1 Jira, Snowflake (any MCP connector...)
It worked for sure on 2026-05-20, and today (2026-05-21) it doesn't.
definitely regression.
Very frustrating

m13v · 1 month ago

the part that bites here isn't the approval gate itself, it's that interactive approval and unattended approval are getting treated as one grant. a routine has no human to click 'allow', so a permission model that only knows 'ask the user now' degrades to a hard no the moment nobody's sitting there. permitted_tools on the connector should act as a standing grant scoped to that surface, precisely because the surface is non-interactive by construction. the failure mode i keep running into is permission logic built for the interactive case first, then bolted onto scheduled runs where the same prompt silently becomes an infinite wait. cleaner to split approval-at-bind-time for unattended from approval-at-call-time for interactive, with the tool allowlist being the bind-time artifact.

dhk1 · 1 month ago

Same bug happened recently and it's affecting all remote routines and connectors for me.
Every MCP tool call in my remote/scheduled routines fails instantly with:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval

seandorsett-atx · 1 month ago

Confirming on scheduled (cron-triggered) routines, not just API-fired ones, and any type triggered manually.

A few additional data points from debugging this session:

13-connector diagnostic: Attempted one read-only tool call from each of 13 connectors available in the execution environment (Slack, Google Drive, JIRA, Atlassian, Gmail, Google Calendar, Figma, Amplitude, Guru, Ramp, Zapier, monday.com). All 13 returned the identical error. This suggests the gate is environment-wide, not scoped to the routine's connector config.

Subagent test: Spawned a subagent and had it attempt the same calls. Same error. The block is consistent across the main agent and subagents.

~/.claude/settings.json workaround: Added mcp__Slack__, mcp__Google-Drive__, mcp__JIRA__, mcp__Atlassian__ to permissions.allow mid-session. File write confirmed, allow rules verified with jq. MCP calls still blocked immediately after.

No workaround found. Routine is non-functional until this is resolved on the platform side.

kolmykovde-cpu · 1 month ago

+1 — same issue on Gmail and Google Drive connectors in a remote routine. Worked fine 2026-05-20, broken since 2026-05-21.

Every MCP call returns "Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval" — including read-only ones (Gmail:search_threads, Google-Drive:read_file_content).

Setup:

  • Personal Pro plan
  • Remote routine triggered by cron
  • Gmail + Google Drive connectors added to routine
  • Yellow banner confirmed: "Claude can use all tools from these connectors without asking for permission during runs"
  • All connector tools set to "Always allow" in web UI

Things tried (none worked):

  • Disconnect + reconnect both connectors
  • Remove + re-add connectors to routine
  • ~/.claude/settings.json with explicit mcp__Gmail__ and mcp__Google-Drive__ in permissions.allow
  • "defaultMode": "bypassPermissions" in settings.json
  • Recreated routine from scratch
  • Verified same connectors work instantly in normal Claude.ai chat on the same account

Confirms what others said: this is a routine-execution-layer regression, not a connector or OAuth issue. Unattended routines are completely broken for any MCP-dependent workflow.

marimoreli · 1 month ago

Running into the same thing with Slack, Datadog and Sentry MCPs

bellmount · 1 month ago

Experiencing the same with G Cal, Notion, Todoist MCPs

omid-ant · 1 month ago

Hi folks, we're aware of this issue and looking into it.

omid-ant · 1 month ago

Update: This issue should be addressed. We are continuing to monitor, please let me know if you encounter any issues.

tdesai-eightfold · 1 month ago

It's fixed.
Thanks @omid-ant

devonpohl · 1 month ago

Claude Code routine now having issues seeing MCP, still digging but the original error is no longer present.

devonpohl · 1 month ago

Routine is telling me: Please open this URL in your browser to authorize the [...] connector:
[URL]

after hitting the URL I see the attached image. This seems like it has to be the wrong flow? @omid-ant

<img width="816" height="182" alt="Image" src="https://github.com/user-attachments/assets/6d71a831-3186-4ff3-b827-7608c7183d8d" />

bellmount · 1 month ago

Reproducing post-fix. Created routine after your fix comment. Notion, Google Calendar, Todoist connectors all attached and visible in the routine config UI. Routine fires, but the agent's tool registry contains zero MCP tools - ToolSearch returns nothing for any of the three connectors. Not the "requires approval" error from the original report; this is a step earlier - tools never injected into the session at all. Deleted and recreated the routine, same symptom. Account on Pro plan, region DE.

hoysay · 1 month ago

+1, now seeing different error message from the original ("MCP tool call requires approval") - now routines are treating external MCPs as unauthorized, and trying to re-authenticate returns the same "Server Turned Down" message that devon mentioned above.

shreyashah115 · 1 month ago

+1 facing the same issue. Gmail first-party connector on a scheduled daily triage routine. Tools are never injected into the session at all, no "requires approval" error, just zero Gmail tools visible. Secondary symptom: re-auth fallback hits rate limit for client registration requests with no UI path to resolve it.

omid-ant · 1 month ago

Thanks @devonpohl and others, that issue should now be fixed as well.

devonpohl · 1 month ago

Working! Thank you!

bellmount · 1 month ago

Yes, thanks!

mkocztorz · 1 month ago

My scheduled routines worked today without issue.

mlevantin · 10 days ago

Still reproducing as of July 5, 2026. A scheduled routine calling the Slack connector (slack_read_channel / slack_send_message) fires but hangs on the approval prompt when run headless — no output. Manual "Run now" works since a human can approve; BigQuery and Google Drive connectors in the same routine are unaffected.

One extra data point that might help localize the fix: a trigger created before the ~May 19 regression still runs Slack tools headless with no prompt, while a trigger created after it never can — even for the same connector and account. Approving the connector on a manual run doesn't persist to later scheduled runs. Suggests the grant is bound at trigger creation and post-regression triggers can't obtain it.