[BUG] MCP tool calls in CCR Routines fail with "requires approval" — no approval UI shown, reconnect does not resolve

[beer89447-spec]

Preflight Checklist

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

What's Wrong?

MCP tool calls made inside a Claude Code Routine (automated, non-interactive CCR session) consistently fail with:

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

The Anthropic CCR proxy (api.anthropic.com/v2/ccr-sessions/{id}/mcp) returns this error on every call.

Since Routines have no interactive user present, no approval UI can appear — and indeed none appears. Disconnecting and reconnecting the MCP connectors (Heptabase) does not resolve the issue. The MCP config file (/tmp/mcp-config-{session_id}.json) is correctly generated with valid server IDs and proxy URLs.

What Should Happen?

MCP connectors that have been authorized in claude.ai settings should work in Routines without requiring per-call interactive approval. This was the behavior until recently.

Error Messages/Logs

Steps to Reproduce

1. In claude.ai/code, configure a Routine that calls MCP tools (e.g. Heptabase get_journal_range, Notion notion-create-pages)
2. Ensure the MCP connectors are connected (OAuth authorized) in claude.ai settings
3. Trigger the Routine
4. Observe that every MCP tool call fails with MCP tool call requires approval
5. No approval UI appears anywhere in the browser
6. Disconnecting and reconnecting the MCP connector does not fix the issue
7. The same MCP tools work correctly in local Claude Code CLI with the same OAuth-authorized connections

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.146

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Scheduled routines fail every MCP tool call with "MCP tool call requires approval" on custom connectors (regression ~2026-05-20) #61015
2. [BUG] Routines: MCP connector tool calls fail with "requires approval" despite connectors being added to routine #61027

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

[lukewebsterrtm-byte]

Hitting this same regression — adding context in case it helps triage.

Setup:

Claude Code on the web, scheduled routine triggered daily.
Routine has a Google Drive connector attached with the "Claude can use all tools from these connectors — including writes — without asking for permission during runs" banner showing in the config UI.
Routine was recreated fresh today (after the original failed), so the config is not stale.
Symptom (exact match):
Every MCP Drive tool call returns:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval
No approval UI surfaces (it can't — it's a headless scheduled run), so the routine deadlocks on the first connector call and never produces output.

Confirmation it's session-type specific, not config:
I ran the identical workflow in an interactive web session today (same account, same connector, same repo), and every Drive call succeeded without an approval prompt. The interactive session sees the Drive tools under a UUID-prefixed namespace (mcp____search_files); the routine session appears to be hitting the same backend but gated.

Regression confirmed:
This routine was working previously and started failing around the May 19 build. Symptom and build window match other reports filed the same day.

Business impact:
Production daily routine is broken. No direct-API workaround available in our environment due to deployment constraints. Currently running the routine manually each morning as a holding pattern.

Happy to share routine ID / failed session IDs privately if it helps — let me know where to send them.

[fokkedekker]

Seeing the same thing here. If it helps to narrow it down routines worked fine on may 19th around 5PM. 24 hours later the same routines failed with this exact error message as shared above.