Claude Codeで"the auto mode classifier gave no verdict"が出る原因と対処法

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”が何を意味するか、今すぐ何をすればいいかをまとめた。

Claude Codeの"permission denied"を症状別に切り分ける——EACCESとAuto Modeクラシファイアは別物だった
Claude Codeの"permission denied"を症状別に切り分ける——EACCESとAuto Modeクラシファイアは別物だったClaude Codeでpermission deniedが出る原因は一つじゃない。npm installのEACCES権限エラーと、2026年8月にAuto Modeが標準になったことで急増した「classifierによる拒否」を、公式ドキュメントとGitHub Issueの一次情報で切り分けて整理した。読む →

まず区別する — “denied”と”no verdict”は別のエラー

Auto Modeのclassifier絡みで表示されるメッセージは、実は性質が違う2種類がある。

種類表示文言意味原因
拒否(denied)Permission for this action was denied by the Claude Code auto mode classifierclassifierが判定した上で「危険」と結論を出した誤検知を含む安全性判定のロジック
判定不能(no verdict)The server-side auto mode classifier gave no verdict (error)classifierが判定そのものを返せなかったサーバー側の一時的な障害・可用性の問題

前者はこの記事で既に扱った。allowlistに入れていても拒否される、bypassPermissionsでも拒否される、という「AIが危ないと誤判定するケース」の話だ。

Claude Codeの"permission denied"を症状別に切り分ける——EACCESとAuto Modeクラシファイアは別物だった
Claude Codeの"permission denied"を症状別に切り分ける——EACCESとAuto Modeクラシファイアは別物だったClaude Codeでpermission deniedが出る原因は一つじゃない。npm installのEACCES権限エラーと、2026年8月にAuto Modeが標準になったことで急増した「classifierによる拒否」を、公式ドキュメントとGitHub Issueの一次情報で切り分けて整理した。読む →

今回扱う”no verdict”はそれとは根本的に別物で、classifierが「安全か危険か」の判断すらできずにタイムアウトしている状態を指す。エラー文にも明記されている通り、not a judgment about the action——つまりアクション自体への評価ではなく、判定システムそのものが一時的に機能不全になっているという意味だ。


発生タイムライン — 9月22日から15件以上が同じ症状を報告

GitHub Issueをclassifier no verdictで検索すると、直近1週間だけでも次のような報告が並ぶ。

Issue報告日影響を受けたツール
#959829/22プロジェクト配下のファイル書き込み
#960679/22Plan modeの計画ファイル
#978129/28Edit / Bash
#978549/28Bash / ScheduleWakeup
#978559/28classifierサービス全般
#977669/28Bash / Edit
#978689/28全般
#978699/28Write
#978709/28allowlist済みコマンド
#978749/28Chrome MCPのtabs_context
#978779/28WebSearch
#978849/28Edit / Bash / PowerShell
#980479/29全般
#980739/29読み取り専用のBashコマンド
#981099/29ファイル編集(こちらは後述の別問題)

9月22日にも散発的な報告はあったが、9月28日13:10 UTC前後(日本時間22:10頃)から報告が集中していて、複数の独立した環境(macOS/Windows/Linux、CLI/VS Code拡張/デスクトップアプリ)から同時多発的に上がっている。これは個々の設定ミスではなく、classifierを提供するサーバー側で障害が起きていたことを強く示唆している。

github.com
Auto mode: server-side safety classifier intermittently returns no verdict, blocking Bash and ScheduleWakeup entirely · Issue #97854 エラー文言の全文と再現手順が最も詳しく整理されている報告。BashだけでなくScheduleWakeupも同じ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 ok and ls, which is allowlisted via Bash(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だけにとどまらない。

Claude Codeのスケジュール実行でハマった3つの罠——cronとLaunchAgent連携のデバッグ記録
Claude Codeのスケジュール実行でハマった3つの罠——cronとLaunchAgent連携のデバッグ記録Claude Codeの/scheduleコマンドとcron/LaunchAgentを組み合わせた自動実行で遭遇した3つの問題と解決策。環境変数、認証、タイムアウトの罠を実体験ベースで解説。読む →

なぜ起きるのか

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側の原因特定の優先度が上がりやすい。

github.com
Auto mode classifier returns no verdict, blocking Edit/Bash operations · Issue #97812 Edit操作が繰り返しno verdictで止まった報告に、macOS・Windows・VS Code拡張など複数環境からの追加コメントが集まっている。共通してRead系は無事だったこと、Manualモードへの切り替えが唯一の回避策だったことが複数人から確認されている。

紛らわしい別の不具合との切り分け — 「理由なき拒否」は”no verdict”ではない

ここで一つ注意が必要なのが、同じ時期に報告されている別種の不具合との混同だ。

Issue #97923・#98109では、“no verdict”(判定不能)ではなく、classifierが理由を示さずに「危険」と判定して拒否する(judged this action dangerous (it gave no explanation))報告が上がっている。しかも同じコマンドを再実行すると通ってしまう、という非決定的な挙動が指摘されている。

github.com
Auto mode classifier denied a routine in-repo file edit without a reason, then allowed the identical command on retry · Issue #98109 ユーザー自身のリポジトリ内でのバイト単位で同一のコマンドが、1回目は理由なしで拒否され、2回目はそのまま通った、という非決定性を指摘する報告。「no verdict(判定不能)」ではなく「判定はしたが説明がない拒否」である点が今回のテーマと異なる。

これは”no verdict”(判定そのものが返らない)ではなく、“denied with no explanation”(判定はしたが理由が空)という、また別のバグだ。前者はサーバー障害、後者はclassifierの判定ロジック自体の不安定さが疑われていて、原因のレイヤーが違う。エラー文にno verdictと出ているか、denied+理由なしと出ているかで、どちらの系統かを見分けるのが早い。


恒久対策として — Auto Mode自体を見直す

障害が頻発するようなら、そもそもAuto Modeを常用するかどうかを見直すのも一つの手だ。個人アカウントなら~/.claude/settings.jsonのpermissions.defaultModeを"default"に固定すれば、新規セッションはManualモードから起動するようになる。Auto Modeの仕組み自体をまだちゃんと理解していない場合は、先にこちらを読んでおくと設定の勘所が掴みやすい。

Claude Code Auto Mode 完全攻略 2026——2段階分類器の仕組み・カスタマイズ設定・安全な使い方
Claude Code Auto Mode 完全攻略 2026——2段階分類器の仕組み・カスタマイズ設定・安全な使い方Claude Code Auto ModeはShift+Tabで起動する自律承認モード。2段階分類器の仕組み(17%見落とし率含む)、--dangerously-skip-permissionsとの違い、カスタマイズJSON設定、Enterprise封鎖設計まで網羅。読む →

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

Claude Codeが2時間47分止まった日。フリーランスが障害に備えてやるべきこと
Claude Codeが2時間47分止まった日。フリーランスが障害に備えてやるべきこと2026年7月29日19:49〜22:36 UTC(日本時間30日朝)、Claude全体で529エラーが多発する障害が発生。年初から155件の障害が報告される中、Claude Code依存で仕事してるフリーランスがステータス監視・こまめなコミット・セッション設計で備える具体策を整理する。読む →

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系の作業を先に進めながら復旧を待つのが今のところ最も再現性の高い対処法になる。

github.com
anthropics/claude-code Issues 「no verdict」「classifier」で検索すると、今回扱った以外の関連報告や、その後の修正状況が見つかることがある。同じ症状に心当たりがあれば、既存Issueへのコメントで環境情報を追加すると優先度が上がりやすい。
← 記事一覧に戻る