Claude Code Routines APIのfireが403 project is pausedで止まる

Claude Codeの/fireエンドポイントが、Project所属のRoutineに対して403とthis project is pausedを返す報告が出ています。Projectは一時停止もアーカイブもされておらず、同じRoutineのRun nowは動きます。GitHubのissue(anthropics/claude-code#102874)は2026年10月28日時点でopenのままです。

公式ドキュメントのエラー表には、この組み合わせの記載がありません。原因が分からないまま止まっている人向けに、報告された症状、いま分かっている回避策、自分の環境での切り分け手順を順に書きます。

報告されている症状

issueの報告者が送ったのは、次の形のリクエストです。

curl -X POST \
  https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "..."}'

返ってくるのは次のレスポンスです。

{
  "type": "error",
  "error": {
    "type": "permission_error",
    "message": "this project is paused"
  },
  "request_id": "req_..."
}

ステータスは403、error typeはpermission_errorです。報告者のissueには、resourceとsub_reasonが空文字で入ったレスポンスが載っています。

最初の拒否は2026年10月16日の21時台(UTC)で、以降の試行はすべて拒否されたと報告されています。同じ報告者は、2つの別のProjectでそれぞれ再現しています。

同じ症状の追加報告

issueには4件のコメントが付いています。最初の報告者を含めて、少なくとも4人が同じ症状を報告しています。

• 10月16日: 同じRoutineにGitHubイベントのトリガー(Pull requestのlabeledで、ラベルがwake)を足しても、起動しなかった。実行履歴にもスレッドにも何も出ない。Run nowだけが動く
• 10月19日: API専用のRoutineをアクティブなProjectで作り、トークンを作り直し、Projectの一時停止と再開も試したが直らない(Maxプラン)
• 10月27日: 下で触れる「textの有無で結果が分かれる」報告
• 10月28日: TelegramボットからProjectを起こしたい用途で、同じ403を確認。Projectの中でスケジュール実行は正常に動いている

つまりトークンの再発行も、Projectの一時停止と再開も、効いていません。Project所属のRoutineでは、APIとGitHubイベントという外部から起動する経路が、どちらも通らないというのが報告の全体像です。

textを付けるかどうかで結果が変わる

10月27日のコメントは、切り分けの糸口になります。Project内で作ったRoutineに対して、報告者は次の結果を得ています。

APIで「Run now」相当の起動をした場合も、同じ分かれ方をしたという報告です。ここから、Project所属のRoutineをtextなしで起動するだけなら通る、と読めます。

ただしこれは、1人の報告者が自分の環境で観察した結果です。Anthropic側の説明はissueにまだありません。他の人の環境で必ず再現するとは言えないため、自分で試して確かめる前提で読んでください。

回避策: textを空にして、Routine側で文脈を取りに行く

コメントの報告者は、次の形で回避しています。

1. /fireは空のbodyで呼ぶ
2. Routineのプロンプトに、課題管理ツールへ問い合わせて自分宛ての作業を取りに行く手順を書く

アラート本文のようなイベントごとの文脈を、textでは渡せなくなります。その代わりに、起動後にClaude自身が情報を引く設計へ寄せる形です。

別の報告者は、Projectの外に転送用のRoutineを1つ置き、そこからメッセージを受け渡す形で回避しています。Telegramのメッセージを受けて、Projectを起こしたいという用途です。

空bodyで試す手順

自分のRoutineで確かめるなら、まずbodyなしで叩きます。

curl -i -X POST \
  https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2026-10-21"

200でtype: routine_fireが返れば、起動自体は通っています。続けて同じコマンドに-H "Content-Type: application/json" -d '{"text": "test"}'を足し、403に変わるかを見ます。変わったなら、issueの10月27日のコメントと同じ症状です。

レスポンスのrequest_idは控えておきます。issueに追記するときに、報告者全員が貼っているのがこの値です。

自分の環境で切り分ける順番

this project is pausedというメッセージは、文面どおりに受け取ると遠回りになります。issueの報告では、Projectの状態は原因ではありませんでした。次の順に確かめると、無駄な操作を減らせます。

最初の質問は、Routineが動くかどうかを確かめるものです。this project is pausedが出ていても、Run nowが成功するなら、スイッチや環境の設定を疑う理由はありません。

公式ドキュメントとの食い違い

APIリファレンスのエラー表で、403は「アカウントまたは組織がこのエンドポイントにアクセスできない」場合だけです。Routineが一時停止中の場合は400 invalid_request_errorの欄に載っています。

今回のレスポンスは403で、メッセージは「project」の停止を名乗っています。表のどちらの行にも当たりません。

もう1つ、ヘッダの扱いが変わっています。issueの報告者はanthropic-version: 2023-06-01とanthropic-beta: experimental-cc-routine-2026-04-01を付けていました。APIリファレンスの現行の例はanthropic-version: 2026-10-21で、2023-06-01以降のすべてのバージョンを受け付けて同じ挙動になると書かれています。betaヘッダも、付けてあっても付けなくても受け付けられます。

古い例のヘッダのまま叩いて403になった場合、ヘッダの違いは原因になりません。ヘッダを直しても結果は変わらないので、切り分けの対象から外して構いません。

運用への影響

Project所属のRoutineを、外部の仕組みから起こす設計にしている場合に影響が出ます。

• アラートの自動調査: 監視ツールがtextにアラート本文を入れて起動する構成は、Project所属のRoutineでは通らない可能性があります。Projectの外にRoutineを作るほうが確実です
• CIの失敗を渡す構成: 失敗したワークフローのIDをtextに入れて渡す構成も同じです。IDをプロンプト側から取りに行く形に変えると、空bodyで動きます
• スケジュール実行とRun now: こちらは報告者の環境で正常に動いています。影響を受けるのは、外部からの起動だけです

Routineが渡されたtextを使う仕組みは、Routinesのfire APIの手順にまとめています。textが<routine-fire-payload>ブロックで包まれて届くため、空bodyに寄せる場合は、プロンプトからその参照を外しておく必要があります。

APIのエラー全般(400・401・429など)は、Claude Code Routines完全ガイドのエラー表に載っています。MCPコネクタの承認待ちで止まるケースは別の原因なので、Routinesで承認待ちになるエラーを見てください。

修正の進み具合を追う方法

issueは10月28日時点でopenで、bug・platform:web・area:routinesのラベルが付いています。Anthropicからの返信はまだコメントに出ていません。

修正の有無は、同じtext付きのリクエストをもう一度叩いて確かめられます。200が返れば直っています。issueが閉じられたら、再現手順のスクリプトを残しておいたRoutineで確かめ、空bodyの回避策を元の設計に戻します。

APIは実験的な位置づけで、リクエストとレスポンスの形が変わる場合があると公式のリファレンスが明記しています。外部起動を本番の通知経路に使う場合は、起動に失敗したときの代替手段も用意しておくと安全です。