MCP tool call requires approvalエラーの原因と対処(Routines)

claude.aiのscheduled routine(/scheduleやRemoteTriggerツールから作成するもの)がMCPツールを呼ぶと、Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approvalというエラーで止まることがあります。この回帰は2026年5月に報告されました。コネクタの操作は読み取りも含めて失敗し、書き込みも反映されません。routineには承認プロンプトをクリックする人間がいないため、処理はそこで止まります。原因はGitHub Issue #61015にまとまっています。対応済みとのコメントは発生翌日に付きました。ただし同種の症状は、その後も形を変えて報告が続いています。

Scheduled routinesのMCP呼び出しが「承認待ち」で止まる症状

最初の報告者は、Auth0でOAuth保護されたカスタムMCPサーバー(Obsidianノートを操作する自作コネクタ)をscheduled routineに接続しました。すると、routine内のlist_notesやcreate_noteの呼び出しがすべて次のエラーで失敗したと説明しています。

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

同じコネクタはClaude Code(ローカルMac・リモートLinux)やclaude.ai chatといった対話的な画面からは問題なく呼べていました。失敗するのは「routineの実行環境+MCPコネクタ」の組み合わせです。スケジュール起動ではlast_fired_atが更新されるためroutine自体は起動しますが、コネクタへの書き込みは反映されません。

報告者の環境情報によると、失敗が始まったのはUTC 2026-05-19 14:00頃からUTC 2026-05-20 14:00頃の間です。同一アカウント上で、プロンプトの異なる複数のroutineが同じコネクタへの書き込みを同時期に止めていました。個別のroutine設定ではなく、プラットフォーム側の変更に連動した動きです。

報告者は当初、公式コネクタ(LinearやGranola)は影響を受けていないように見えると書いていました。この見立ては、数時間のうちに覆ります。コメント欄には、Notion・Gmail・Google Calendar・Microsoft 365・Slack・Atlassian(Jira)・Datadog・Sentry・Linear・Google Drive・Snowflakeなどでの再現報告が並びました。

ある報告者は、実行環境で使える13種類のコネクタに読み取り専用のツール呼び出しを1つずつ試しました。全13件が同一のエラーで失敗し、サブエージェントに同じ呼び出しをさせても結果は同じでした。個別のコネクタ設定ではなく、実行環境全体にかかるゲートだったことがうかがえます。

公式の説明と、報告された挙動のずれ

routineの公式ドキュメントは、承認なしで動くことを前提に書かれています。

くらべる

公式ドキュメントの記述と、Issueの報告

設計上の説明

公式ドキュメント

routineは完全なClaude Codeクラウドセッションとして自律的に動き、権限モードの選択画面はありません。含めたコネクタは書き込みを含む全ツールを、実行中に許可を求められず使えます。

2026年5月21日

Issueの報告

routine設定画面には、コネクタのツールを許可なしで使えるという黄色いバナーが出ていました。それでも実行時は全MCP呼び出しが承認待ちで拒否され、ユーザーが承認を与える画面もありませんでした。

報告者が見た実行コンテナのsettings.jsonには、"allow": ["Skill"]しかありませんでした。画面上の説明と実行時の挙動が食い違っていたことになります。

なぜ止まったのかについて、Issueには技術的な分析が1件あります。対話的な承認と無人実行の承認を同じ許可として扱うと、承認する人間がいない実行では、許可を求める処理がそのまま拒否に転じるという指摘です。ツール一覧(permitted_tools)を作成時に渡していても、承認が要求されたと報告されています。あくまで一報告者の分析です。Anthropic側が原因をこの形で確定させたコメントは、Issueにはありません。

2026年5月21日の経過

Issueが公開されてから収束するまでの流れは、時間単位で動きました。

あゆみ

Issue #61015の5月21日(UTC)

1. 00:54Issue公開

   カスタムOAuthコネクタでの承認待ちエラーが報告されます。

2. 01:52〜14:28再現報告が連続

   Notion・Gmail・Slack・Atlassian・Datadogなど、コネクタを問わず報告が集まります。

3. 15:04〜15:14対応コメント

   15:04に「把握して調査中」、15:14に「対応済みのはず」と続きます。15:28には報告者から「直った」との返信が付きました。

4. 16:00〜18:43別の症状が出る

   元のエラーは消えた一方、routineのセッションにMCPツールが一つも登録されない、再認証のURLを開くと失敗する、といった報告が続きます。

5. 19:57追加の対応とクローズ

   別症状の報告に答える形で「それも修正された」とのコメントが付き、同時刻にIssueがクローズ(state reason: completed)されました。翌22日にも「正常に動いた」という返信が付いています。

18時台の報告には、routineを削除して作り直しても同じだったというものがあります。報告者の見立てでは、原因は承認ゲートの手前、ツールをセッションへ渡す段階に移っていたようです。

2026年7月以降に報告された別の形

Issue #61015自体はクローズされましたが、クローズ後も同じスレッドにコメントが投稿され続けました。5月のクローズが、すべての環境で恒久的な解決になったとは言い切れません。

• 2026-07-06: Slackコネクタで、無人実行時のみ承認プロンプトでハングすると報告されました。手動の「Run now」なら成功し、同じroutine内のBigQuery・Google Driveは影響を受けていません。回帰以前に作成したトリガーはSlackツールを無人実行できますが、後に作成したトリガーでは同じコネクタ・同じアカウントでも再現します。許可がトリガー作成時点に紐づいている可能性が指摘されています
• 2026-07-19: Gmail・Google Driveで、エラーメッセージもなく出力ゼロのままセッションが止まり続ける症状が報告されました。「Always」に設定済みのツールでも結果は同じです。Driveだけのトリガーがその日の早い時間に2分足らずで完走したのに、同じ内容を数時間後に再実行するとハングしました。サーバー側の断続的な条件である可能性が指摘されています
• 2026-07-23: 5月にも報告があったSentryコネクタで、承認エラーではなく無出力のハングとして再発しました。permitted_toolsを明示し、作り直したトリガーでも同じ結果です
• 2026-08-04: Gmail・Dropboxで報告されました。リポジトリの.claude/settings.jsonにpermissions.allowを書いていても、全ツール呼び出しで手元の端末に「Allow once / Deny」が出ます。1回の実行で20〜30回以上の承認が要ると述べています
• 2026-08-12: Superhuman Mail・Gmail・Notion・Microsoft 365・Google Calendarで、承認が毎回要求され、手動実行で与えた承認は次の定期実行に引き継がれませんでした。同じ処理がCoworkの定期タスクでは11日まで承認なしで動いていたため、Claude Codeのroutine特有の問題だと述べています

8月の2件は、#61027・#61044・#61097・#61143という重複Issueの番号を挙げています。これらのIssueの状態は、#61015のスレッドには出てきません。さらに2026年9月28日には、7日間更新のないクローズ済みIssueとして自動でロックされました。同種の症状に当たった場合は、新しいIssueを立てて#61015を参照する扱いになります。

症状から切り分ける

同じ領域でも、報告された症状は4種類に分かれます。どれに当たるかで、見るべき場所が変わります。

routineのコネクタ設定では、接続済みのコネクタが既定ですべて含まれ、不要なものは外すよう案内されています。含めたコネクタのツールは、書き込みを含めて実行中に承認を求めず使えるためです。

routineの実行結果の見方にも注意が要ります。実行一覧の緑色の表示は「セッションが起動して、インフラのエラーなしに終了した」ことだけを示します。プロンプトの作業が成功したことは意味しません。MCPツールの欠落やタスク単位の失敗は、実行の記録(トランスクリプト)を開いて初めて見えます。

Claude Code v2.1.227以降なら、次のように尋ねられます。/schedule why did my nightly review do nothing this morning?と入力すると、直近の実行の状態とログを読んで原因を説明させられます。承認エラーかツールの欠落かの見分けに使えます。

効かなかった対処と、限定的に効いた回避策

Issueのコメントには、効かなかった対処が具体的に残っています。

まとめ

Issueで「効かなかった」と報告された対処

• settings.jsonのallowを書く

  実行中に~/.claude/settings.jsonへmcp__Slack__*などを追加しても、すぐ後の呼び出しは拒否されました。"defaultMode": "bypassPermissions"も同様です。8月の報告では、リポジトリの.claude/settings.jsonに書いたallowも効いていません。

• コネクタの接続し直し

  切断と再接続、routineからの外し直し、routine自体の作り直しは、5月の複数の報告で効果がありませんでした。

• ツール権限を「Always allow」に

  claude.aiの画面でツールを「Always allow」にしても、5月の報告では失敗が続きました。7月の報告でも、「Always」にしたツールでハングしています。

5月の報告者の1人は、読み取り専用の呼び出しまで含めてすべて失敗することから、ツールごとの設定ではなく実行環境全体の問題だと結論づけています。settings.jsonの書き方はsettings.jsonの適用範囲にまとまっています。

限定的に機能したのは、人間がその場で操作する手動実行(「Run now」)です。7月の報告では、承認プロンプトをその場でクリックできるぶん成功しています。ただし無人実行という目的を失うため、根本対応ではなく動作確認用です。最初の報告者は、同じコネクタを使う処理をclaude.aiのroutineから切り離し、ローカルのcronジョブとして走らせています。動作はしますが、ローカルマシンの電源が落ちていても実行されるというroutineの利点は手放すことになります。

MCPのツール単位でどこまで許可するかという設計は、routine固有の問題ではなくMCPサーバーの権限設計全般に関わる話です。今回は、その権限モデルが「実行中に人間がいる」前提だった点が、無人実行のroutineで裏目に出ました。トリガー種別・料金・シークレット管理などRoutine全般はClaude Code Routines完全ガイドにあります。

まとめ

routineでMCPコネクタを使う設計は、仕様上は承認なしで動くものです。ただし、5月の回帰以降も承認・ハング・引き継ぎ不足の報告が続きました。新しく組み込むときは、手動の「Run now」だけでなく、スケジュール実行を1回通して、実行のトランスクリプトまで読んで成否を判断するのが確実です。