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

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

+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.

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

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".

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) 

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

+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.

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


+1, with slack and sentry

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.

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

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.

• 1 on report, had a few ruined routines tonight. Looking forward to be fixed

+1 on gmail..

+1 Slack,Jira

• 1 Linear

+1 Google Calendar

+1 Google Drive

+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

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.

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

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.

+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.

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

Experiencing the same with G Cal, Notion, Todoist MCPs

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

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

It's fixed.
Thanks @omid-ant

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

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" />

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.

+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.

+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.

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

Working! Thank you!

Yes, thanks!

My scheduled routines worked today without issue.

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.

Adding a data point that may be a variant of this same bug, filed independently today (2026-07-18) as a full write-up: we're seeing the same underlying failure class — MCP connector calls blocked in a fired Claude Code Remote scheduled task ("Routine") despite connectors being fully authorized — but with a worse symptom than the "requires approval" error shown above: in our case the fired session hangs indefinitely with zero output and no error text at all, on both Gmail and Google Drive connectors.

Two findings that might help narrow this down:

1. Not gated by permission state. We re-ran the identical trigger with the failing tool explicitly set to "Always" in Settings → Connectors, confirmed via the UI beforehand. Hung identically. Rules out "missing a one-time approval grant" as the cause.
2. Not confined to one connector, and time-varying within the same day. A Drive-only trigger (no Gmail/Calendar/Tasks at all) completed cleanly, unattended, in under 2 minutes early in the day. The exact same unmodified prompt, re-fired a few hours later with zero changes, hung with no output at all — including a direct control test re-firing the original working trigger verbatim. So this doesn't look purely connector-specific; it may be an intermittent server-side condition that can affect any connector call in a fired Routine.

Full repro writeup with timestamps/trigger IDs available if useful — happy to share more detail if it helps triage.

+1, reproducing on the Sentry connector (https://mcp.sentry.dev/mcp), which confirms this isn't limited to the connectors already listed in this thread.

Setup: Pro-tier account, remote routine on a daily cron schedule, single connector (Sentry) attached with explicit permitted_tools set on the connector entry (search_issues, get_issue_activity, get_issue_breadcrumbs, add_issue_note).

Symptom: No MCP tool call requires approval error text at all — the fired session simply never produces any Sentry-side output (no comment posted, no visible error). Manual RemoteTrigger action=run via the API produces the identical silent no-op.

Things tried (none worked):

• Set permitted_tools explicitly per tool name on the mcp_connections entry (was previously [])
• Added mcp__Sentry__* to the session-level allowed_tools
• Created a brand-new trigger from scratch with the corrected config (can't delete via API, so this is a second trigger alongside the original) — same silent failure

Timing note: both triggers were created 2026-07-22 and 2026-07-23 — well after the original May regression — which lines up with @mlevantin's 2026-07-05 comment that "the grant is bound at trigger creation and post-regression triggers can't obtain it." It also matches @gFarr85's 2026-07-18 report of indefinite hangs with zero output on Gmail/Drive: this variant looks to still be live today (2026-07-23), and it affects Sentry too.

Happy to share trigger IDs / full config privately if useful for repro.

Still reproducing this on 2026-08-04, well after the "should be addressed" update above — same signature as #61027/#61044/#61097/#61143.

Setup: a scheduled Routine on Claude Code on the web, personal Gmail + Dropbox MCP connectors, no org-managed policy. .claude/settings.json in the repo has an explicit permissions.allow with both server-level entries ("mcp__Gmail", "mcp__Dropbox") and exact tool names (e.g. "mcp__Gmail__search_threads").

Every connector tool call during the run still requires manual approval on the phone ("Allow once / Deny"), including tools that are literally present in permissions.allow. Confirmed with a screenshot of search_threads triggering the prompt. Since the whole point of a Routine is to run unattended, this makes any workflow that touches a connector unusable without a human standing by to tap through 20-30+ prompts per run.

Also filed via the in-app feedback button, reference ID 64ad7f41-5760-4bbc-84f4-f3e266b14bea, in case that helps correlate on your end.

Given the "addressed" note is from a while back and the duplicates keep coming, could someone confirm whether this is being actively worked on?

Still reproducing this on 2026-08-12, well after the "should be addressed" update above — same signature as https://github.com/anthropics/claude-code/issues/61027/https://github.com/anthropics/claude-code/issues/61044/https://github.com/anthropics/claude-code/issues/61097/https://github.com/anthropics/claude-code/issues/61143.

Claude Code cloud routines are prompting for approval on every MCP connector call, and approvals granted in one run don't persist to the next. Routine created 11 Aug 2026; a manual run that day required approving every tool call, and the first scheduled run on 12 Aug prompted for everything again. Connectors: Superhuman Mail, Gmail, Notion, Microsoft 365, Google Calendar — all directory connectors, all authorised with read/search permissions via the Claude Connectors UI.

Same connectors and equivalent workload ran headless with no prompts as a Cowork scheduled task through 11 Aug, so this looks specific to the Code routines surface rather than connector auth.