Claude Codeで"the auto mode classifier gave no verdict"が出る原因と対処法
Claude CodeのAuto Modeで「classifier gave no verdict (error)」が出てBash/Editが全部止まる報告が2026年9月に急増中。15件以上のGitHub Issueを時系列で整理し、拒否(denied)との違いと今すぐできる対処法をまとめた。
エンジニアのゆとです。
GitHub Issueを定点観測してたら、9月末に入ってから同じ文言の報告が異常なペースで積み上がってるのに気づいた。
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.
Auto Modeを使っているとBash・Edit・Writeが軒並みこのエラーで止まる、という報告が2026年9月22日以降、少なくとも15件以上のIssueとして上がっている。以前この記事で扱った「classifierに拒否される(denied)」問題とは文言も原因も別物で、混同すると対処を間違える。この記事では一次情報のIssueを時系列で整理し、“no verdict”が何を意味するか、今すぐ何をすればいいかをまとめた。

まず区別する — “denied”と”no verdict”は別のエラー
Auto Modeのclassifier絡みで表示されるメッセージは、実は性質が違う2種類がある。
| 種類 | 表示文言 | 意味 | 原因 |
|---|---|---|---|
| 拒否(denied) | Permission for this action was denied by the Claude Code auto mode classifier | classifierが判定した上で「危険」と結論を出した | 誤検知を含む安全性判定のロジック |
| 判定不能(no verdict) | The server-side auto mode classifier gave no verdict (error) | classifierが判定そのものを返せなかった | サーバー側の一時的な障害・可用性の問題 |
前者はこの記事で既に扱った。allowlistに入れていても拒否される、bypassPermissionsでも拒否される、という「AIが危ないと誤判定するケース」の話だ。

今回扱う”no verdict”はそれとは根本的に別物で、classifierが「安全か危険か」の判断すらできずにタイムアウトしている状態を指す。エラー文にも明記されている通り、not a judgment about the action——つまりアクション自体への評価ではなく、判定システムそのものが一時的に機能不全になっているという意味だ。
発生タイムライン — 9月22日から15件以上が同じ症状を報告
GitHub Issueをclassifier no verdictで検索すると、直近1週間だけでも次のような報告が並ぶ。
| Issue | 報告日 | 影響を受けたツール |
|---|---|---|
| #95982 | 9/22 | プロジェクト配下のファイル書き込み |
| #96067 | 9/22 | Plan modeの計画ファイル |
| #97812 | 9/28 | Edit / Bash |
| #97854 | 9/28 | Bash / ScheduleWakeup |
| #97855 | 9/28 | classifierサービス全般 |
| #97766 | 9/28 | Bash / Edit |
| #97868 | 9/28 | 全般 |
| #97869 | 9/28 | Write |
| #97870 | 9/28 | allowlist済みコマンド |
| #97874 | 9/28 | Chrome MCPのtabs_context |
| #97877 | 9/28 | WebSearch |
| #97884 | 9/28 | Edit / Bash / PowerShell |
| #98047 | 9/29 | 全般 |
| #98073 | 9/29 | 読み取り専用のBashコマンド |
| #98109 | 9/29 | ファイル編集(こちらは後述の別問題) |
9月22日にも散発的な報告はあったが、9月28日13:10 UTC前後(日本時間22:10頃)から報告が集中していて、複数の独立した環境(macOS/Windows/Linux、CLI/VS Code拡張/デスクトップアプリ)から同時多発的に上がっている。これは個々の設定ミスではなく、classifierを提供するサーバー側で障害が起きていたことを強く示唆している。
実際に報告されている症状パターン
Issueのコメント欄を横断すると、共通するパターンが見えてくる。
Bash・Edit・Writeが軒並み拒否される
一番多いのがこれで、echo ok や ls のような無害なコマンドすらno verdictで止まる。allowlist(permissions.allow)に明示的に書いてあるコマンドでも素通りしない、という報告もある。
Also hitting this on macOS (Darwin 25.4.0), Claude Code 2.1.283, CLI. Every Bash call failed with “classifier gave no verdict (error)”, including
echo okandls, which is allowlisted viaBash(ls:*).
Read系のツールは影響を受けない
複数の報告で共通しているのが、Read・Grep・MCPの読み取り専用クエリは正常に動き続けたという点だ。影響を受けるのは「書き込み・実行を伴う操作」に限られている。
Read and Grep kept working. Like others here, the only fix was switching out of auto mode into default (manual approval).
10回連続で失敗するとセッションが停止する
エラー文にもある通り、リトライのたびに待機時間が伸びていき、10回連続で判定不能が続くとターン自体が停止する仕様になっている。
After 10 consecutive responses without a verdict, Claude Code stops completely with: “Auto mode is unavailable — the server returned no safety verdict for the last 10 responses, so Claude stopped.”
ScheduleWakeupやChrome MCPなど、Bash以外のツールにも波及する
ScheduleWakeup(スケジュール実行の自己リマインド機能)や、Claude in ChromeのMCPツールも同じclassifierでゲートされているため、障害の影響範囲はBashだけにとどまらない。

なぜ起きるのか
Issueのコメントを追う限り、原因についてAnthropicから公式な事後報告はまだ出ていない(2026年9月29日時点)。ただし報告内容から次のことは読み取れる。
- 複数の独立したユーザー・環境から同時多発的に発生しており、個々の設定ミスではない
- Read系操作は影響を受けないことから、classifierサービス自体(書き込み・実行の安全性を判定する処理)の可用性問題と考えられる
- 数分から数十分で自然に回復するケースが多く、恒久的な障害ではなく一時的なスパイク性の問題である可能性が高い
- 一部の報告では「関連する可能性がある」として、以前からある
<model> is temporarily unavailable系の長期化したIssue(#49535)が引き合いに出されている
つまり現時点では「Auto Modeの判定エンジンを支えるバックエンドが、一時的に過負荷または不安定になっている」という仮説が最も有力で、ユーザー側の設定を直しても解決しない性質のエラーだ。
今すぐできる対処法
設定ミスではないので「これを直せば終わり」という単純な対処法はないが、実際に効果があったと報告されている手順は次の通り。
1. Shift+TabでManualモードに一時退避する
最も確実で、かつ複数の報告で「唯一効いた」とされている方法。Auto Modeを経由しなければclassifierのゲートそのものを通らないため、書き込み・実行系の操作を続けられる。
Shift+Tab で auto → default (Manual) に切り替え
障害が収まったのを確認してから、もう一度Shift+TabでAuto Modeに戻せばいい。
2. Read系の作業を先に進めておく
Read・Grep・検索系のツールは影響を受けないため、調査・設計フェーズの作業を先に片付けて、書き込みが必要な作業だけ後回しにするのも現実的な回避策になる。
3. リトライを連打しない
10回連続失敗するとターンが強制停止する仕様なので、機械的にリトライを繰り返すより、一度待ってから再試行したほうが早く復旧に当たる。エラー文自体も「読み取り専用の作業を先に進めて、後で戻ってこい」と案内している。
4. 数分〜数十分待つ
報告の大半は「特に何もしなかったが、次のターンでは正常に戻っていた」というパターンで、サーバー側の一時的な問題である以上、待つのが最も再現性の高い解決策になる。
5. Issueにコメントで環境情報を追加する
同じ症状に心当たりがあれば、該当Issueに発生時刻・バージョン・環境をコメントで追記しておくと、Anthropic側の原因特定の優先度が上がりやすい。
紛らわしい別の不具合との切り分け — 「理由なき拒否」は”no verdict”ではない
ここで一つ注意が必要なのが、同じ時期に報告されている別種の不具合との混同だ。
Issue #97923・#98109では、“no verdict”(判定不能)ではなく、classifierが理由を示さずに「危険」と判定して拒否する(judged this action dangerous (it gave no explanation))報告が上がっている。しかも同じコマンドを再実行すると通ってしまう、という非決定的な挙動が指摘されている。
これは”no verdict”(判定そのものが返らない)ではなく、“denied with no explanation”(判定はしたが理由が空)という、また別のバグだ。前者はサーバー障害、後者はclassifierの判定ロジック自体の不安定さが疑われていて、原因のレイヤーが違う。エラー文にno verdictと出ているか、denied+理由なしと出ているかで、どちらの系統かを見分けるのが早い。
恒久対策として — Auto Mode自体を見直す
障害が頻発するようなら、そもそもAuto Modeを常用するかどうかを見直すのも一つの手だ。個人アカウントなら~/.claude/settings.jsonのpermissions.defaultModeを"default"に固定すれば、新規セッションはManualモードから起動するようになる。Auto Modeの仕組み自体をまだちゃんと理解していない場合は、先にこちらを読んでおくと設定の勘所が掴みやすい。

Claude全体のサービス障害という意味では、以前529エラーの障害についても書いた。フリーランスとして「Anthropic側の障害にどう備えるか」という視点は共通しているので、あわせて読んでおくと役立つはずだ。

FAQ
”no verdict”はいつ直る?
2026年9月29日時点で、Anthropicから公式な原因究明・修正報告はまだ出ていない。報告を見る限り数分〜数十分で自然に収まるケースが多いが、恒久的な修正がいつ入るかは不明。Issueをウォッチしておくのが確実。
allowlistに登録したコマンドも影響を受ける?
受ける。permissions.allowに明示的に登録済みのコマンドでも、“no verdict”エラーが出ている間は同様にブロックされたという報告が複数ある。これは「classifierの判定ロジックの誤り」ではなく「classifierサービスそのものにアクセスできない」状態なので、allowlist側の設定を直しても解決しない。
bypassPermissionsを使っていれば回避できる?
現時点の報告では未確認。ただし”denied”パターンの記事で扱った通り、bypassPermissionsでもAuto Modeのclassifierに引っかかるケースが以前から報告されているため、過信はできない。障害中に急ぎの作業がある場合は、Shift+Tabで明示的にManualモードへ切り替えるほうが確実だ。
エラーが出ても作業内容自体は保存される?
保存される。“no verdict”はツール呼び出しの実行可否の判定でブロックされているだけで、それまでの会話やセッションの状態が失われるわけではない。Manualモードに切り替えて同じ操作を再実行すれば、そのまま作業を続けられる。
まとめ
2026年9月22日以降、Auto Modeのclassifierが判定を返せなくなる”no verdict”エラーが少なくとも15件以上のGitHub Issueとして報告されている。以前扱った「classifierに拒否される(denied)」とは別の症状で、こちらはサーバー側の一時的な可用性問題である可能性が高い。allowlistや設定を直しても解消しないタイプのエラーなので、遭遇したらShift+TabでManualモードに一時退避し、Read系の作業を先に進めながら復旧を待つのが今のところ最も再現性の高い対処法になる。