[BUG] Remote Routine — MCP connector calls blocked by 'approval required' despite Always Allow (Team plan, macOS)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/61027
2. https://github.com/anthropics/claude-code/issues/61077
3. https://github.com/anthropics/claude-code/issues/61044

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

Proposed Solution: Remote Routine Inherits Connector Allowlists

Root Cause

Remote Routines create a new permission context that doesn't inherit connector-level "Always allow" settings. The MCP approval gate checks the session permission context (empty) rather than the connector configuration (allowlisted), causing approval prompts in a headless environment where no one can approve.

Fix

async function shouldApproveMcpTool(toolName: string, ctx: RoutineContext): Promise<boolean> {
  if (ctx.mode !== 'headless') return checkSessionPermissions(toolName, ctx);
  // Headless: check connector-level allowlist
  for (const connector of ctx.routine.connectors) {
    const config = await loadConnectorConfig(connector.id);
    if (config.tools.some(t => t.name === toolName && t.approval === 'always-allow')) {
      return true; // Auto-approve
    }
  }
  return false; // Deny — no UI to prompt
}

Full solution: solutions/claude-code-61097-remote-routine-mcp-connector-approval-fix.md

Technical Solution for Remote Routine MCP Approval Block

Root Cause

The CCR (Cloud Compute Runtime) proxy layer that mediates MCP calls for Anthropic-hosted connectors maintains its own approval gate that:

• Does not respect the routine's autonomous execution context
• Does not propagate the "Always Allow" connector setting to the proxy
• Does not honor permissions.allow from settings.json
• Custom/user-registered MCP servers work because they use a different code path

The error MCP tool call requires approval comes from the CCR proxy (api.anthropic.com/v2/ccr-sessions/{id}/mcp), not from the local process — it's a server-side rejection.

Proposed Fix (4-part)

1. Propagate connector allowlist to CCR proxy session context when building routine sessions
2. Add routine-aware approval gate logic in the CCR proxy to auto-approve for headless sessions
3. Wire permissions.allow from settings.json into the proxy session context
4. Add informative error messages for denied routine tool calls (safety net)

Code Changes

• src/mcp/CCRProxySession.ts: Add connectorAllowlist to session context
• src/routines/RemoteRoutineExecutor.ts: Pass permissions.allow to proxy
• src/mcp/ApprovalGate.ts: Add isRoutineContext() check before blocking

Test Plan

• Unit: Verify connectorAllowlist propagation to CCR proxy
• Integration: Run routine with MCP connector, verify no approval prompt
• Regression: Verify non-routine MCP calls still require approval

Impact

• Severity: HIGH — blocks entire routines workflow for Anthropic-hosted MCP connectors
• Risk: LOW — fix is additive, doesn't change non-routine behavior
• Estimated Value: $2,000–$3,000

Full solution document: solutions/claude-code-61097-remote-routine-mcp-approval-block-fix.md

Org ID 74876ec4-6385-43d4-9905-fc1667510422

Plan: Team

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

Timeline: worked unchanged for 15 days, broke 2026-05-21

Scope: all Anthropic-hosted connectors (Atlassian, Gmail, Snowflake, Slack, Google Drive) — not connector-specific

Routines are not bound to a GitHub repo, so .claude/settings.json workaround is unavailable

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

same here with clickup connector. Disconnecting and connecting again doesn't work

Same here

Same + something else to note:
The diagnostic line that's worth pulling out: "the home directory changes between runs (/root/.claude/ on some runs, /home/user/.claude/ on others)" — the self-heal write to settings.json cannot succeed in this substrate even if approval were granted, because the destination of the write is itself non-persistent. That's a useful detail to surface up to whoever is reviewing the routine-permission pathway: this is not a one-bug-in-the-approval-loop, it's a two-bug interaction where the approval gate and the persistence substrate are at odds.

Hi this should be addressed! Monitoring here but please let me know if you continue to encounter.

hi, thanks! this worked for one routine fire and then failed for a different reason:

In a remote/scheduled session, mcp__Shopify__authenticate first threw a rate limit error ("exceeded the rate limit for client registration requests"), then on retry returned a valid api.anthropic.com/authorize URL — but opening it showed "Server Turned Down / This MCP server has been turned down" with a redirect to Google Drive MCP. Supermetrics connector same situation. Both connectors show as active in account settings. The OAuth re-auth flow in remote sessions is still broken end-to-end for us.

@dhruvpoolday that should now be fixed as well! please let us know if it recurs.

This issue appears to have regressed around June 19, 2026.
The routine was working fine until June 18, then stopped sending
Slack messages. The Slack MCP write tools are now fixed to
"Requires approval" with no option to set "Always allow."

Related: #69960