auto modeの分類器が応答不能・判定なし(no verdict)でBashが止まる原因と回避策

<model> is temporarily unavailable, so auto mode cannot determine the safety of ...と表示され、そのあとBashコマンドが軒並み止まる。auto modeでこの現象に当たったら、原因はコマンドの中身ではありません。安全性を判定する分類器モデルへのリクエスト自体が失敗しています。

The server-side auto mode classifier gave no verdictも同じ系統で、危険と判定されたのではなく判定そのものが出なかったという意味です。数秒待って再試行すれば通ることが多く、繰り返すなら下の切り分けに進みます。

Bash denied by auto modeは別です。この通知は、分類器が危険と判定した通常の拒否でも入力欄の近くに出ます。末尾の理由が[Data Exfiltration]などの分類名なら判定結果なので、待っても通りません。temporarily unavailableやgave no verdictの文言なら、判定が出なかっただけです。フックのログでreasonがClassifier unavailableになっている場合も、判定不能の側です。

GitHub issue #74949には、この失敗がピーク時間帯にバーストし、複合コマンドの多い開発フローをほぼ止めてしまうという実測データが集まりました。分類器の判定ルールそのものはClaude Codeのauto mode分類器は何を止めているか、失敗の一般的な分類はClaude Codeのauto mode安全性判断エラーで扱っています。この記事は「なぜBashだけ止まるのか」「いつ起きるのか」「何ができるのか」に絞ります。

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

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

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秒後には別のモデル名で同じ文言が再発しました。公式のエラー一覧によると、読み取り・検索・作業ディレクトリ内の編集は分類器を経由しないため、これらは動き続けます。止まるのは、allowルールに一致しないシェルコマンド、MCPツール呼び出し、ネットワーク操作です。

症状から原因を切り分ける

文言は固定ではありません。v2.1.229以降は、Claude Codeが失敗の種類を判別できるとtemporarily unavailableの直後にカッコで種類を添えます。種類は(rate-limited)・(overloaded)・(server error)・(timed out)・(connection failed)の5つです。v2.1.229より前は種類を書かず、末尾もWait brieflyでした。issueの文言が古い形なのはそのためです。

種類が分かれば、見るべき場所が変わります。

Amazon Bedrockだけは例外があります。AWSアカウントが文言のモデルを呼び出せない場合も同じ文言になり、再試行のたびに繰り返されます。この場合は一時障害ではなく権限の問題です。

「gave no verdict」と出たときの意味と対処

temporarily unavailableとは別に、The server-side auto mode classifier gave no verdict (timed out), so auto mode cannot determine the safety of <tool>.という文言もあります。サーバーが判定を返さなかったときの拒否で、カッコ内にtimed outのような種類が入ります。

このとき、次のように動けます。

• Claude Codeが待ち時間を挟むことがあり、対話セッションではAuto mode check unavailableとカウントダウンが出る。Escで中断できる
• 判定なしが10回連続すると、Auto mode is unavailableと出てターンが止まる(v2.1.280以降)。次のメッセージを送ればカウントはやり直しになる
• LLMゲートウェイやプロキシ経由なら、ストリーミング応答を途中で切っていないか確かめる
• 起動前にCLAUDE_CODE_AUTO_MODE_SERVER=0を設定すると、サーバー側レビューをやめて従来の分類器リクエストを使う(直接接続で効くのはv2.1.281以降)
• 自分で承認したいなら、auto modeから別の権限モードに切り替える

表示は使い方で変わります。v2.1.296以降の対話セッションでは、エラー文の代わりにNot run · auto mode's check had no usable answerという薄い行が出ます。本文はCtrl+Oのトランスクリプトで読めます。-pの非対話実行で10回連続になると、実行がエラーで終わり、メッセージは標準エラー出力に出ます。

ScheduleWakeupも同じ分類器で止まる

gave no verdictの文言は、カッコの中が(timed out)とは限りません。GitHub issue #97854(2026年9月28日登録)では、デスクトップアプリのauto modeで次の形が全呼び出しに出たと報告されています。

The server-side auto mode classifier gave no verdict (error), so auto mode cannot determine the safety of Bash. This is a transient failure of the check, not a judgment about the action: a later response may get a verdict. You may try the action again once, as-is. Repeated attempts are slowed by a growing delay, and after 10 responses in a row without a verdict the turn stops. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

文面は、これが「行為への判断ではなく、チェック側の一時的な失敗」だと断っています。再試行は1回だけ、そのままの形で試せるとも書かれています。連続して判定が出ないと待ち時間が伸びていき、10回続くとターンが止まります。この10回は、前の節のAuto mode is unavailableと同じ仕組みです。

報告でこれまでと違うのは、ScheduleWakeupが同じ文言で止まった点です。pwdやecho okのような自明なコマンドまで止まり、数分間は全滅したあと、手元の操作なしに復旧しています。同じ時間帯にBashの次の呼び出しとしてScheduleWakeupを試しても、文言のBashがScheduleWakeupに変わっただけで失敗したため、特定のツールではなく共有の分類サービス側の障害だと報告者は見ています。

実務上の痛みは、エラー文が勧める「他の作業を進めて後で戻る」が、戻る先自体がBashや予約だと成立しない点です。自分で再試行を予約するScheduleWakeupも止まるので、セッションが自力で待ち直せません。報告者のセッションは再試行を繰り返さずに止まり、利用者の次のメッセージで再開したときは直ちに通っています。

提案は次の3点です。

• 再試行の予算を消費せずに分類器の状態だけ調べる手段
• ScheduleWakeupを分類器のゲートから外す扱い
• エラー文に再試行までの目安時間を添えること

issue #97854は単独の登録ではなく、同じ現象を書いた別のissue(#97766・#97812・#97855・#97868・#97870)が並んでいます。issueは未解決(open)で、修正や回答は載っていません。待つ側でできるのは、エラー文が言うとおりの1回の再試行と、読み取り中心の作業に回ることです。

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

報告者は自分のセッション履歴から直近のBash呼び出し901件を分析し、96%が&&・パイプ・リダイレクトを含む複合コマンドだったと記録しています。

権限ルールは複合コマンドをサブコマンドごとに評価します。認識される区切りは&&・||・;・|・|&・&・改行で、ルールは各サブコマンドに個別に一致しなければなりません。一致しない部分が1つでもあれば分類器行きです(詳細はClaude CodeのBash権限ルールは複合コマンドをどう評価するかにまとめています)。分類器がバーストで落ちている間は、この経路を通るコマンドがまとめて足止めされます。

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

公式の判定順序を見ると、この報告の筋が通ります。

2段目の例外のとおり、読み取り専用でも分類器側の失敗に巻き込まれる経路が公式に書かれています。Robの報告がこの経路かどうかは、issueからは分かりません。

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

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

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

ただしこの報告者自身が、約1時間後に訂正を加えています。ネットワークログを取ったところ、失敗のかなりの部分はapi.anthropic.comへのクライアント側のDNS解決失敗(7.4分間で43回のERR_NAME_NOT_RESOLVED)でした。朝方のバーストの正体は、ローカルISPの輻輳です。

ルーターのDNSを使わず8.8.8.8と1.1.1.1を直接参照するように変えたあとも、米国夕方の時間帯に分類器の応答不能が5回以上連続で発生しました。最終的な結論は、DNSとサーバー側の需給という2つの原因が重なっているというものです。

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

コミュニティが見つけた回避策の核心は、permissions.allowに一致したコマンドは原則として分類器を呼び出さないという挙動です。判定順序の1段目で結論が出るので、分類器が落ちていても影響を受けません。ただしこの回避策には、元から明確な限界があります。

• allowルールもサブコマンドごとに評価されるため、cd repo && git status | grep fooのような複合コマンドは、どこか1つでもルールに一致しなければ分類器行きに戻る
• git branch(閲覧)とgit branch -D(削除)のようにプレフィックスが同じでも挙動が分かれるコマンドは、allowルールでは区別できません。allowlistには含めず、askまたはdenyで個別に扱う選択肢があります
• allowlistを広げるほど確認なしで通る範囲が広がるため、危険なコマンドを個別にdenyするか、PreToolUseフックで塞ぐ運用とセットにする
• auto modeに入るとき、広すぎるallowルールは自動的に外される。Bash(*)、Bash(python*)のようなインタープリタのワイルドカード、パッケージマネージャーの実行コマンド、AgentとMonitorのallowルールが対象で、Bash(npm test)のような狭いルールは残る

最後の点は見落としやすい落とし穴です。「Bash(npm run *)を足したから大丈夫」と思っても、auto modeの間はそのルールが効かず、障害時には分類器行きのままになります。allowに載せるなら、コマンドを具体的な形で書いておく必要があります。

読み取り専用の検証コマンドを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という設定もあります。trueにすると、auto mode中はBashとPowerShellのallowルールがすべて止まります。クリティカルパスの削除を除き、allowリストに関係なく全シェルコマンドが分類器に回ります。

つまり、この節のallowルールによる回避策はclassifyAllShellが有効な環境では効きません。分類器がバーストしている間は、止まる範囲をむしろ広げる方向に働きます。設定の詳細はautoMode.classifyAllShellで全shellをClaude Codeの審査対象にする設定を参照してください。

バースト中に権限モードをbypassPermissionsへ手動で切り替えるという逃げ道にも、issue内で1件だけ落とし穴が報告されています(apromyslov、2026-07-18)。

~/.claude/settings.jsonでpermissions.defaultMode: bypassPermissionsに変えました。それでも、約1.5時間後にDesktopアプリで作った新しいセッションは分類器を使い続けました。UIで権限モードを切り替えても、起動中のセッション3つすべてで分類器が動き続けたとも記録されています。

報告者は、Desktopアプリがフォルダやセッション単位で持つ設定が全体の既定を上書きしているのではないかと推測しています。ただし単一ユーザーのDesktopアプリでの観測にとどまり、公式の裏付けは取れていません。

手元のv2.1.286で確認できること

分類器が見るルールは、手元のCLIから確認できます。v2.1.286でclaude auto-modeのサブコマンドを調べました。

claude --version
claude auto-mode --help
claude auto-mode defaults | python3 -c "import json,sys; d=json.load(sys.stdin); print({k: len(v) for k, v in d.items()})"

出力は次のとおりです。

2.1.286 (Claude Code)
Commands:
  config              Print the effective auto mode config as JSON: your
                      settings where set, defaults otherwise
  critique [options]  Get AI feedback on your custom auto mode rules
  defaults [options]  Print the default auto mode environment, allow, soft_deny,
                      and hard_deny rules as JSON
  reset [options]     Reset auto mode configuration to the shipped defaults by
                      removing the autoMode section from your user settings file
{'allow': 17, 'soft_deny': 72, 'hard_deny': 1, 'environment': 21}

既定の分類器ルールは、allow例外が17件、soft_denyが72件、hard_denyが1件(Data Exfiltration)です。allow側の見出しを並べると、Read-Only Operations・Git Push Destination・Transient Retryなどが入っています。

このうちTransient Retryは、障害の文脈で興味深いルールです。ネットワークエラー・5xx・タイムアウト・レート制限といった一時的な失敗のあとに同じ操作を再試行しても、それ自体は回避行為として扱わない、という趣旨の例外です。再試行したアクションは、ほかのブロックルールに照らして評価されます。つまり再試行そのものは、ルール上は回避行為の根拠になりません。

claude --helpでは、--permission-modeの選択肢がacceptEdits・auto・bypassPermissions・manual・dontAsk・planの6つ並びます。

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

issueの「Suggestion」は、分類器が使えないときは拒否せず、手動の確認プロンプトを1回出してほしいというものでした。後半の報告者(yonikremer、2026-08-07)は、承認判定のモデル呼び出しにリトライを入れる案も出しています。

issue自体は2026年9月8日、動きがないままgithub-actions[bot]によって自動クローズされました。GitHub上の終了理由はnot_plannedで、duplicateとstaleのラベルも付いています。修正されたと明言してクローズされたわけではありません。

公式ドキュメントが定めているのは、これとは別の自動フォールバックです。分類器が同じアクションを3回連続、または合計20回ブロックすると、auto modeは自動的に手動の確認プロンプトへ切り替わります。しきい値は設定で変えられません。

このしきい値に数えないと明記されているのは、分類器自身へのリクエストが、auto modeとは別の安全性チェックに拒否された場合です。分類器の応答が構文解析できなかった場合の扱いは、公式に記述がありません。

issueが報告している「分類器モデルへのリクエスト自体が一時的に失敗する」ケースは、公式のno-verdict denialの定義(構文解析失敗と別の安全性チェックによる拒否)に含まれません。しきい値に数えるかどうかも明記がありません(このフォールバックが確実に効くケースはClaude Codeのauto mode安全性判断エラーにまとめています)。

公式changelogには、この期間に関係する修正が複数入っています。

v2.1.216・v2.1.243・v2.1.246は、issueの症状の一部に対応する内容です。ただし、issueが求めていた「分類器停止時は手動承認へ自動フォールバックする」という設計変更そのものは、どれにも含まれていません。v2.1.246より前のバージョンを使っている場合は、まず更新で消える失敗が混じっていないか確かめる価値があります。

一方でフックの仕組みは、この障害を観測する手段を用意しています。PermissionDeniedフックは分類器が判定を出せなかった拒否でも発火し、reasonフィールドには、分類器モデルが応答不能だったときだけ固定文字列Classifier unavailableが入ります。

フック側でhookSpecificOutput.retry: trueを返すとモデルに再試行を促せます。ただし、Claude Code側がretryを無視すると明記されているのは、応答の構文解析失敗と別の安全性チェックによる拒否の2ケースだけです。モデル応答不能は、その列挙に含まれていません。まずはログを取って傾向を把握する用途に向きます。

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

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

まとめ

バーストに当たったら、まずエラー文言のカッコの中身で自分の環境かサーバー側かを切り分け、前者なら接続の確認、後者なら読み取り中心の作業に回って再試行する、という順に動けます。手を止めない備えとしては、狭い形で書いたallowルールを事前に整えておくのが、障害時にも効く備えです。ただしBash(*)のような広いルールはauto modeでは外されます。

障害ではなく、許可したはずのpushを分類器が理由なしで止める報告もあります。そちらはauto modeで許可したgit pushがブロックされる不具合と回避策で扱っています。