auto modeの分類器が応答不能になるとBashが止まる原因と回避策

<model> is temporarily unavailable, so auto mode cannot determine the safety of ...と表示され、そのあとBashコマンドが軒並み止まる——auto modeでこの現象に当たったら、原因はコマンドの中身ではなく、安全性を判定する分類器モデルへのリクエスト自体が失敗したことにあります。GitHub issue #74949には、この失敗がピーク時間帯にバーストし、複合コマンドの多い開発フローをほぼ止めてしまうという実測データが集まりました。分類器の判定ルールそのものはClaude Codeのauto mode分類器は何を止めているか、失敗の一般的な分類はClaude Codeのauto mode安全性判断エラーで扱っています。この記事はissue #74949が集めた「なぜBashだけ止まるのか」「いつ起きるのか」「何ができるのか」に絞ります。

分類器が応答不能になるとBashがまとめて止まる

issue #74949は2026年7月6日に登録されました。報告者はmacOS上のClaude Code CLIで、ピーク時間帯にauto modeの分類器が繰り返し応答不能になる現象を記録しています。エラー文言は次の形です。

claude-opus-4-7[1m] is temporarily unavailable, so auto mode cannot determine the safety of mcp__Claude_in_Chrome__browser_batch right now. Wait briefly and then try this action again.

26秒後には別のモデル名で同じ文言が再発しました。読み取り・検索・作業ディレクトリ内の編集は分類器を経由しないため動き続けますが、シェルコマンドとネットワーク操作はすべて分類器待ちになります。

なぜBashだけほぼ全滅するのか

報告者は自分のセッション履歴から直近のBash呼び出し901件を分析し、96%が&&・パイプ・リダイレクトを含む複合コマンドだったと記録しています。Claude Codeの権限ルールは複合コマンドをサブコマンドごとに評価するため、静的なallowルールと完全一致しない限り分類器行きになります(詳細はClaude CodeのBash権限ルールは複合コマンドをどう評価するかにまとめています)。分類器がバーストで落ちている間は、この経路を通るコマンドがまとめて足止めされます。

さらに別の報告者(Rob-Makappen、2026-07-21)は、単体の読み取り専用コマンドも同じバーストで止まったと追記しています。git status --short・git diff --stat・git -C <path> statusは、組み込みの読み取り専用allowlistが想定していない書き方だったため、分類器行きになって共倒れしました。復旧の足がかりにしたい調査コマンドほど、逆に止まりやすいという皮肉な結果です。

ピーク時間帯に集中する理由は1つではない

issue内の複数の報告者が、バーストが特定の時間帯に固まって発生し、その後平常に戻るパターンを記録しています。ある報告者(apromyslov)は12個の並行セッションを2日間観測し、UTC時間帯ごとの発生件数を次のように記録しました。

エラー文言に含まれるモデル名を数えるとclaude-sonnet-5が171件で最多でした。報告者はこの偏りから、Sonnet 5側の需給が詰まる時間帯にバーストが集中するのではないかと当初考えていました。

ただしこの報告者自身が、翌日に訂正を加えています。ネットワークログを取ったところ、失敗の大部分はapi.anthropic.comへのクライアント側のDNS解決失敗(7.4分間で43回のERR_NAME_NOT_RESOLVED)であり、朝方のバーストの正体はローカルISPの輻輳でした。DNSをGoogle Public DNSに切り替えて解決を安定させたあとも、米国夕方の時間帯に分類器の応答不能が5件連続で発生し、DNSとサーバー側の需給という2つの原因が重なっているというのが最終的な結論です。

allowルールは分類器を経由しない — 回避策と限界

コミュニティが見つけた回避策の核心は「permissions.allowに一致したコマンドは分類器を呼び出さない」という挙動です。障害中でも分類器へのリクエストが発生しないぶん、影響を受けません。ただしこの回避策には元から明確な限界があります。

• allowルールもサブコマンドごとに評価されるため、cd repo && git status | grep fooのような複合コマンドは、どこか1つでもルールに一致しなければ分類器行きに戻る
• git branch(閲覧)とgit branch -D(削除)のようにプレフィックスが同じでも挙動が分かれるコマンドは、allowルールでは区別できません。allowlistには含めず、askまたはdenyで個別に扱う選択肢があります
• allowlistを広げるほど確認なしで通る範囲が広がるため、危険なコマンドを個別にdenyするか、PreToolUseフックで塞ぐ運用とセットにする

読み取り専用の検証コマンドを1コマンドずつallowlistに登録する例です。

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(gh pr view:*)"
    ]
  }
}

複数ステップの読み取り専用処理は、1本のスクリプトにまとめてパスで個別許可すると、複合コマンドの分解を気にせず1ルールで済みます。auto modeのallow/deny/askルールの管理方法は/permissionsコマンドで権限ルールとauto mode拒否を管理するにまとめています。反対に、複合コマンドすべてを分類器に通したい組織向けにはautoMode.classifyAllShellを有効にする設定もありますが、これは分類器がバースト中の場面ではむしろ影響範囲を広げる方向に働く点に注意が必要です(設定の詳細はautoMode.classifyAllShellで全shellをClaude Codeの審査対象にする設定を参照してください)。

バースト中に権限モードをbypassPermissionsへ手動で切り替えるという逃げ道にも、issue内で1件だけ落とし穴が報告されています。~/.claude/settings.jsonでpermissions.defaultMode: bypassPermissionsに変更しても、変更前から起動していたセッションには反映されず、分類器を使う判定のままauto modeが動き続けたと報告されています(apromyslov、2026-07-18)。権限モードの変更は新しく起動したセッションから反映されるとみられ、既存セッションを抜けるにはセッションの再作成が要る可能性があります。ただし単一ユーザーの観測にとどまり、公式の裏付けは取れていません。

部分的な修正はあるが、フォールバックそのものは実装されていない

issueの「Suggestion」は「分類器が使えないときは拒否せず、手動の確認プロンプト1回にフォールバックしてほしい」というものでした。この提案は2026年9月8日、動きがないままgithub-actions[bot]によって自動クローズされています。修正されたと明言してクローズされたわけではありません。

公式ドキュメントが定めているのは、これとは別の自動フォールバックです。分類器が同じアクションを3回連続、または合計20回ブロックすると、auto modeは自動的に手動の確認プロンプトへ切り替わります。ただしこのしきい値は分類器が拒否を返した回数だけを数えるもので、no-verdict denial——分類器自身へのリクエストが、分類器とは別の安全性チェックによって拒否された場合、または分類器の応答が構文解析できなかった場合——はカウントされないと明記されています。issueが報告している「分類器モデルへのリクエスト自体が一時的に失敗する(temporarily unavailable)」ケースがこのno-verdict denialの定義に当てはまるかどうかは、一次ソースに明記がありません。当てはまれば確認プロンプトへの切り替えは起こらず、当てはまらなければ通常の拒否として数えられ、いずれ確認プロンプトに切り替わるはずですが、どちらかを判定できる記述は見つかりませんでした(このフォールバックが確実に効くケースはClaude Codeのauto mode安全性判断エラーにまとめています)。

公式changelogには、この期間に関係する修正が複数入っています。v2.1.243(2026年8月25日)は「APIが一時的に過負荷でリトライを指示したあと、約1分待ってもtemporarily unavailableのまま拒否され続ける」不具合を修正し、v2.1.246(同日)は非常に大きなセッションで安全性チェックの締め切りをプロンプトサイズに応じて延ばす修正を加えました。どちらもissueで報告された症状の一部に対応する内容です。ただし、issueが求めていた「分類器停止時は手動承認へ自動フォールバックする」という設計変更そのものは、この2件のどちらにも含まれていません。

一方でフックの仕組みは、この障害を観測する手段を用意しています。PermissionDeniedフックは分類器が判定を出せなかった拒否でも発火し、reasonフィールドには分類器が応答不能だったことを示す固定文字列Classifier unavailableが入ります。フック側でhookSpecificOutput.retry: trueを返すとモデルに再試行を促せますが、分類器が判定を出せなかった拒否についてはClaude Code側がこのretryを無視すると明記されています。ログを取って傾向を把握する用途には使えますが、この失敗を自動で突破する手段としては機能しません。

自分のセッションでこの現象がどれだけ起きているかは、過去のセッションログから該当文言を数えると分かります。

grep -rl "is temporarily unavailable" ~/.claude/projects/ | wc -l

まとめ

auto modeの「temporarily unavailable」バーストは、分類器モデル自体の需給とクライアント側のDNSという2つの原因が絡み、判定を返せなかったアクションを拒否する仕組みのため、複合コマンドの多いBash作業をまとめて止めます。回避策の中心は「allowルールに一致したコマンドは分類器を経由しない」という挙動を使い、読み取り専用コマンドと繰り返し使うスクリプトを個別に許可しておくことです。issue自体は手動承認へのフォールバックを求めたまま自動クローズされており、フック経由の自動再試行も分類器の無応答時には機能しません。バースト中に手を止めないための備えは、事後の設定より事前のallowlist整備に依存します。