Remote triggers with MCP connections prompt for tool approval despite always-allow setting

Status Fixed / completed
Maintainer reply ✓ Yes — localden
Activity 4 comments · opened May 21, 2026 · closed May 23, 2026
💡 Likely answer: A maintainer (localden, collaborator) responded on this thread — see the highlighted reply below.

Description

Remote triggers (scheduled agents) using MCP connections (Microsoft 365) have stopped auto-approving tool calls. Each run now prompts "Allow Claude to use outlook email search," which blocks unattended execution and defeats the purpose of scheduled triggers.

Was working daily until ~May 20-21, 2026. No user-side configuration changes were made.

Current configuration

  • Microsoft 365 connector set to "always allow" in claude.ai Customize settings
  • Tools listed in both allowed_tools and permitted_tools on the trigger
  • MCP connection properly configured with correct connector_uuid and URL

Observations

  1. Tool naming convention changed from mcp__Microsoft-365__* to mcp__claude_ai_Microsoft_365__* — existing trigger configs referencing old names silently fail
  2. After updating tool names, tools are found but still prompt for manual approval
  3. Affects all triggers using the M365 MCP connection — three separate triggers (daily email summary, daily events scan, weekly recap) broke simultaneously
  4. Connector "always allow" setting is not being respected in the remote trigger execution path

Expected behavior

MCP tools should auto-approve in remote triggers when the connector is set to "always allow" in claude.ai settings.

Actual behavior

Manual approval prompt appears on every MCP tool call, blocking unattended scheduled runs. The trigger outputs: "The tool calls require your approval — it looks like the Microsoft 365 MCP tools need to be authorized before they can run."

Impact

Scheduled triggers that depend on MCP connections are completely non-functional as unattended routines. There is no workaround — manual approval cannot be granted for scheduled runs.

View original on GitHub ↗

4 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/61116
  2. https://github.com/anthropics/claude-code/issues/61015
  3. https://github.com/anthropics/claude-code/issues/61059

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

jshaofa-ui · 4 months ago

Proposed Solution: Remote Trigger MCP Always-Allow Fix

Root Cause

Two issues: (1) Tool names migrated from mcp__Microsoft-365__* to mcp__claude_ai_Microsoft_365__*, breaking existing trigger configs. (2) The "always allow" connector setting is not loaded in the remote trigger execution path — permission resolution falls back to manual approval.

Key Fix

// Load connector "always allow" in remote trigger path
async function resolveToolPermission(trigger: RemoteTrigger, toolName: string): Promise<Permission> {
  const connector = await getMcpConnector(trigger.connectorUuid);
  if (connector?.settings?.alwaysAllow) return 'allow';  // MISSING
  const userPerm = await getUserMcpPermission(toolName);
  if (userPerm === 'always-allow') return 'allow';
  return 'prompt';
}

// Tool name migration fallback
function resolveMcpToolName(name: string, connector: McpConnector): string {
  const newName = name.replace('mcp__', 'mcp__claude_ai_').replace(/-/g, '_');
  return connector.listTools().includes(newName) ? newName : name;
}

Full solution: solutions/claude-code-61203-remote-triggers-mcp-always-allow-fix.md
Estimated effort: 4-5 hours | Quote: $2,000–$3,000

localden collaborator · 4 months ago

Thanks for the report. This was a server-side issue affecting MCP connector calls in scheduled and remote routine sessions. It was resolved on May 21. Please retry your routine. Tracking in #61044.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.