Routine MCP Connectors permission grant not honored at scheduled cron-fire

Resolved 💬 1 comment Opened May 21, 2026 by ErezSZenity Closed May 21, 2026

Trigger ID: trig_01QyWogo3oePdg62cUb4f7D3

Working run (last success): session_01Ct8udz3hsiT1hpLXoatDqw, scheduled, 2026-05-20 06:32 UTC

Failed run: session_01BXEWA4ZLdDg6ebcPbz3iPj, scheduled, 2026-05-21 06:32 UTC

Routine config (unchanged between runs)

  • Cron: 32 6 * * 0-4
  • Connectors: Atlassian + Slack, both granted "without asking for permission during runs" via the Connectors tab
  • Model: Sonnet 4.6

Symptom on the failed run

The routine agent reports that MCP tool calls (searchJiraIssuesUsingJql, slack_search_public_and_private, slack_send_message) "need per-call approval" and cannot proceed. The agent then attempts to write ~/.claude/settings.json with allow rules, which is a local Claude Code mechanism that has no effect inside the CCR sandbox and doesn't persist between firings anyway. The run "completes" (green checkmark in the runs list) but no message is posted to the destination channel.

Manual Run-now invocations exhibit the same behavior intermittently. A 12:01 PM manual run on 2026-05-21 succeeded; a 12:06 PM manual run moments later failed with the same per-call-approval block, despite identical config.

Expectation vs. reality

Expectation: the Connectors tab's "without asking for permission during runs" grant should auto-approve those tool calls in every routine invocation, scheduled or manual.

Reality: the grant is honored inconsistently, and reliably not honored at the scheduled cron time today. No config changes between the working and failed runs.

Secondary issue

When the agent inside the routine encounters this state, it hallucinates a local-Claude-Code fix (writing ~/.claude/settings.json) which has no effect in the CCR sandbox. The agent should either know it's in a routine context and surface a clearer error, or the platform should propagate the Connectors-tab grant to the MCP permission gate consistently so the agent never sees the approval prompt in the first place.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗