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

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/61015
2. https://github.com/anthropics/claude-code/issues/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

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__<uuid>__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.

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.

@localden - As I commented in #61200 - I see this still happening in scheduled routines. The Notion MCP continues to fail. This worked briefly Sunday and then regressed every day after that.

Any updates here. The notion connector still isn't working correctly in routines

This looks like a headless-approval state mismatch rather than a connector-auth problem.

For Routines, the runtime probably needs an explicit effective permission mode for each MCP call before execution:

• interactive session: ask can surface a UI prompt;
• routine session: ask has no prompt surface, so it must either fail before the run starts or require a pre-granted routine-scoped policy;
• always allow: allowed only if the routine config records the server, tool, connector identity, and approved scope;
• deny/cancel: return a terminal tool result the routine can report.

The key invariant is that "connected" and "authorized" are not the same as "this exact routine may execute this write call unattended."

Acceptance tests I would want:

• a read tool with a routine-scoped allow policy executes without a prompt;
• a write tool in ask mode fails before the MCP call with a clear configuration error;
• no routine can wait forever for an approval UI that cannot appear;
• changing connector/server/tool scope invalidates the prior routine permission;
• the run log records whether the call was allowed by routine policy, blocked, or missing a prompt surface.

That would preserve unattended routines without turning connector OAuth into ambient execution authority.

does this affect .mcp.json in a repo as well? I have a custom mcp server which runs npx commands, and it's asking for approval everytime in CCR, I cannot get it to do anything without asking me

I would treat a repo .mcp.json server as the same approval-surface class only if it is being invoked from a headless routine or remote run where no interactive prompt can actually resolve.

The useful split is:

1. connector auth: account/server connection exists;
2. server trust: the MCP server definition, command digest, package/source, and allowed tool set are approved for this routine;
3. invocation authority: this exact tool call, args digest, principal, routine id, and policy version are allowed at this step.

A custom server that runs through npx should not inherit authority from "connector is configured" or "repo file exists." The routine needs either a pre-run policy record that binds the server command and tool scope, or a fail-closed no-effect result before execution starts.

The negative controls I would want are:

• same server name but changed command/package digest -> approval invalid
• same tool name but changed args digest or target scope -> approval invalid
• routine has no interactive approval surface and no pre-grant -> terminal approval_required / no_effect, not a mid-run hang
• approval granted for one routine/principal cannot be replayed by another routine/principal

So yes, if .mcp.json is involved in CCR, I would test it as a scoped server-definition approval problem, not only as a per-call popup bug.

@rpelevin I am running in a remote run. when I wake up the run has been sitting there for 2-3 hours waiting for approval.
I _do_ see the approval prompt though.

do I make a separate issue? this is the only open issue best fits my current problem

I would split this into a separate issue if the prompt is actually visible, because that is a different failure mode from "no approval UI can surface."

The boundary I would describe is:

1. run type: remote run, not a headless routine with no prompt surface;
2. approval surface: prompt is visible to the user;
3. blocked state: run remains parked for 2-3 hours after the prompt is shown;
4. resume path: waking the run does not reconnect the waiting approval request to the tool call;
5. expected state: the approval request remains user-owned and either resolves the exact pending tool call, expires explicitly, or reports a lost/resume-state error.

The bug title I would use is something like:

Remote run waits for visible MCP approval prompt but does not resume after wake

That separates it from this routine issue while preserving the shared invariant: approval_pending is not the same as approval_denied, and a remote/run resume boundary should not strand the tool call without a typed terminal outcome.

In the new issue, I would include whether clicking approve after the wake does anything, whether the prompt was shown in browser or CLI/TUI, the MCP server type, and any run id or timestamp that maintainers can correlate.

@rpelevin mm, well it does resume after I approve. maybe it's a PEBKAC error :/

I'd just like the CCR to run without asking me to run MCP tools in the .mcp.json - I have approved the tools in settings.json, however, this seems to be ignored in scheduled CCR runs

Thanks, that clarification helps. If approving does resume the run, I would keep this in the same issue and narrow it to the scheduled-run policy import path rather than wake/resume.

The distinction I would test is:

1. interactive CCR can ask at call time because a prompt surface exists;
2. scheduled CCR cannot depend on a live prompt as its normal path;
3. settings.json approval should compile into an effective scheduled-run pre-grant only if it binds the server definition, command/package digest, tool name, allowed scope, principal, routine id, and policy version;
4. repo .mcp.json should be treated as server definition/trust input, not as execution authority by itself;
5. if the scheduled run cannot prove that effective pre-grant, it should fail before the tool call with approval_required/no_effect instead of repeatedly prompting or parking mid-run.

The regression I would write is:

• approve the MCP server/tool in settings.json;
• run the same tool interactively and confirm no unexpected prompt;
• run the same tool from scheduled CCR with unchanged .mcp.json;
• assert the effective policy is reused or explain exactly why it is not eligible;
• change the server command, package digest, tool args, or scope and assert the scheduled pre-grant is invalidated.

That would separate user mistake from product behavior: the run log should say whether settings approval was ignored, ineligible for scheduled CCR, invalidated, or applied.