claude-code - 💡(How to fix) Fix [BUG] Scheduled routines fail every MCP tool call with "MCP tool call requires approval" on custom connectors (regression ~2026-05-20)

Preflight Checklist

• 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.
• This is a single bug report.
• 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:

   {
     "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" }
       }
     }
   }

4. Fire the routine manually via POST /v1/code/triggers/<id>/run.
5. 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.