英語版で読む
技術 約9分で読めます

Claude Code（Opus 4.8）でcourtが出てツール呼び出しが止まる

Claude Code Anthropic Bug トラブルシューティング AIエージェント
いけさん目次

Claude Codeがツールを呼ぼうとした直前に court とだけ出して止まる、または court の後ろに <invoke name="..."> がそのまま表示されて何も実行されない。
これ、手元のシェルやMCPサーバが詰まっているだけではなく、Claude Code側のIssueとして同じ形の報告が複数ある。

Bash や Read や Edit が実行された後にハングする話とは少し違う。
問題の形は、ツール呼び出しを作る段階で構造化された tool_use にならず、プレーンテキストとして会話に漏れる、というものだ。
Claude Code側のハーネスから見ると実行できるツール呼び出しが存在しないので、ユーザーには「何も走らず止まった」ように見える。

長時間セッションをtmuxに置きっぱなしにする運用なら、以前書いたClaude Codeセッション管理、どうしてる？の延長でこの症状を見ておく。
セッションを残す運用は便利だが、今回のIssue群では高コンテキスト、複数日リジューム、大量のEdit/Read/Bashが発火条件として何度も出てくる。

court付きのraw invokeがそのまま出る

代表的なのはGitHub Issue #64108だ。
報告者は、長いClaude Code CLIセッションで、Edit や Read の呼び出しが実行されず、次のようなテキストがそのまま表示されたと書いている。

court
<invoke name="Edit">
<parameter name="file_path">/path/to/file</parameter>
...
</invoke>

同じIssueのコメントでは、Opus 4.8 1Mセッションで court が182回出たという追加報告、Opus 4.7 + Claude Code 2.1.148でも同じ形が490件出たという追加報告がある。
つまり「Opus 4.8だけ」「Claude Code 2.1.158以降だけ」と言い切れる材料にはなっていない。
ただしIssue一覧では、5月末から6月上旬にかけてOpus 4.8や長時間セッションを含む報告が目立つ。

#64150は、手元で「実行されないまま同じ壊れ方を繰り返す」症状に近い。
Opus 4.8の1Mコンテキストで、ツール呼び出しの先頭に court が付き、ネームスペースが落ち、ブロックがテキスト表示されてツールが実行されない。
ユーザーが「それはテキストとして出ただけで何も走っていない」と伝えても、同じ壊れ方を約10回繰り返したと書いている。

#65705では、さらに症状が分かりやすい。
アシスタントメッセージの stop_reason が end_turn になり、本文中に court 付きの <invoke name="Bash"> が入る。
この場合、ハーネスには実行対象の tool_use ブロックがない。
だからコマンドは失敗するのではなく、最初から実行されない。

ツールが重いのではなく、呼び出しの形が壊れている

症状を雑に「Claude Codeがハングした」と呼ぶと、原因候補が広がりすぎる。
この court 系は、少なくともIssue上の報告ではツール呼び出しのシリアライズ崩れとして扱われている。

違いはローカルで切り分けやすい。

画面上の見え方近い原因
Bash 実行ログが出た後に戻らないコマンド、サブプロセス、ストリーム、タイムアウト
承認プロンプトが出ないまま固まるパーミッションプロンプト、UIレンダラー
court と <invoke name="..."> が文章として出るtool_use生成の崩れ
tool call could not be parsed が出るツール呼び出しパーサーまたはモデル出力

court が出ている場合、MCPサーバを再起動しても直らないことがある。
実行前の出力が壊れているので、サーバ側にはリクエストが届いていない。

6月上旬は公式ステータス側も荒れていた

Anthropicのステータスページでも、2026年6月1日から7日にかけてOpus 4.7、Opus 4.8、Sonnet 4.6、複数モデル、Claude Code servicesのインシデントが並んでいる。
6月3日のClaude Code services障害では、Claude Code security reviews、code reviews、routines、一部のClaude Code web sessionsがdegradedになったと記録されている。
6月5日には多くのClaude modelsでelevated errors、6月6日にはOpus 4.8のelevated errorsとdegraded service、6月7日にも複数モデルのdegraded performanceが出ていた。

Anthropic以外でも影響が出ていた。Notionのステータスは、Opus 4.7と4.8の性能低下を6月5日から7日のインシデントとして記録している。
Notion AIでこれらのモデルを選んだユーザーの失敗率が上がったため、モデル選択画面からAnthropicの全モデルを一時的に無効化し、リクエストを別プロバイダに振り分けたと書いている。
ユーザー側の設定ではなく、Opus 4.7/4.8側の問題として外部サービスが対応に動いた。

これは court Issueの原因を公式障害に直結させる材料ではない。
ただ、同じ週にモデル側・Claude Code側のエラーが連続していたのは事実だ。
「自分の端末だけがおかしい」と切り捨てるより、ステータスページとGitHub Issueの時刻を並べるほうが早い。

4月のClaude Code品質ポストモーテムも近い文脈にある。
Anthropicは、3月4日のreasoning effort変更、3月26日のthinking履歴削除バグ、4月16日のシステムプロンプト変更がClaude Code品質に影響したと説明している。
その記事では、high effort時の長いレイテンシーでUIがフリーズして見える報告にも触れていた。

今回の court は4月ポストモーテムの3件と同じバグだとは書かれていない。
ただ、長時間セッション、thinking履歴、tool call、UI上の停止感が絡むという点では、同じ運用面に出てくる。

手元で見るならjsonlを確認する

Claude Codeのローカルセッションは ~/.claude/projects/ 配下のJSONLに残る。
Issue #64108のコメントでは、assistant messageが stop_reason: "tool_use" なのにcontentが court だけで、tool_use ブロックがない形をgrepする例が出ていた。

手元では、まず次を見る。

  • 画面に court だけが出たか
  • <invoke name="Bash"> や <invoke name="Edit"> が文章として表示されたか
  • その直後に実際のファイル変更、コマンド実行、MCPサーバ側ログがあるか
  • stop_reason が tool_use なのに tool_use ブロックがないか
  • stop_reason=end_turn で本文に <invoke name= が入っていないか

ここで実行ログがなければ、BashやMCPのデバッグに入る前にセッションを捨てる判断が早い。
同じ会話で「もう一回やって」と言うと、壊れた <invoke> を次の出力テンプレートとして踏むことがある。
#64150の報告も、ユーザー指摘後に同じ壊れ方を繰り返したと書いている。

courtの後に何が起きるか

GitHub Issueでは <invoke name="..."><parameter name="..."> のフルテキストがそのまま表示される例が多い。
だが手元で実際に遭遇すると、そこまで丁寧に壊れるほうが少ない。

一番多いのは、court が出た後に Bash のツール呼び出しヘッダだけ表示されて、何も実行されないパターンだ。
画面にはBashを呼ぼうとしている表示が出る。
コマンドは走らず、結果も返らず、そのまま止まる。
承認プロンプトが出ていない状態とも違う。
ローカルのプロセスリストを見てもBash子プロセスは起きていない。

Issue上の報告では <parameter name="command"> タグまでテキスト表示されるケースがあるが、手元では <parameter> タグまで漏れてきたことがない。
court → Bashヘッダ → 沈黙、がほぼ全部だった。
壊れ方にも段階があって、Issue報告のようにXML構造がまるごとテキストに落ちるのはかなり進んだ状態で、実際に遭遇する頻度としてはBashヘッダだけ出て黙る形のほうがずっと多い。

手元のセッションだと、こういう出方をする。

⏺ 生成物の確認に進む。4枚出して、それぞれの仕上がりを見る。

court

✻ Brewed for 45s · 2 shells still running

❯ ちゃんと実行して

⏺ court

✻ Cooked for 10s · 2 shells still running

❯ また止まってる。続けて

⏺ Bash(cd ~/project && python gen.py ...)
  saved out_01.png

⏺ 4枚出た。それぞれ確認する。

court

  Read 3 files

⏺ 1枚目の結果が想定とずれてる。読み違えないよう読み直す。

court

  Read 1 file

⏺ ツール呼び出しがズレて読み込み位置が動いた。読み直して確定させる。

court

見ての通り、court が出るのは毎回ツール呼び出しの直前、テキストから Bash や Read に移る境目だ。
✻ Brewed for 45s · 2 shells still running の通りバックグラウンドのシェルは動いたままで、固まっているのはセッションのツール呼び出し生成だけだ。

この状態で「再開しろ」「動け」のように雑に促すと、次のターンでは正常な tool_use が生成されてコマンドも実行される。
ただし直ったわけではなく、ツール呼び出しが数回続くとまた同じ崩れ方をする。
「動け」で動くが、根本は変わっていない。

前のターンで壊れた出力がコンテキストに入っている状態で、「再開しろ」というメッセージが挟まるとモデルはツール呼び出しの構造を最初から組み直す。
だから次の1回は通る。
壊れたコンテキスト自体が消えるわけではないので、しばらくするとまた崩れる。
Issue #64150で報告者が「同じ壊れ方を10回繰り返した」と書いているのは、このサイクルが延々続いた結果だ。

courtが見えた時点で、そのセッションでのツール呼び出しは不安定になっている。
「動け」で通った1回を信用してファイル編集やgit操作を続けるより、セッションを切ったほうが安全だ。

回避はセッションを短く切る

GitHub Issue上で確定修正はまだ見つからない。
手元でできる対処は、壊れたセッションを延命しないことになる。

モデルを下げる手もあるが、court対策でOpus 4.7に逃げるのは微妙だ。
Opus 4.7はツール呼び出しを飛ばす別の癖が報告されていて、Opus 4.8のリリースノートもその修正に触れている。Notionが4.7に切り替えず全Anthropicモデルを切ったのも、4.7と4.8の両方が不調だったからだ。
Claudeに残るならSonnet 4.6のほうが安定だが、これもcourt自体の確定修正ではない。

長いセッションで court が出たら、まず新規セッションへ移す。
未完了作業はClaude Codeに持たせず、git diff、TODOファイル、作業ログに逃がす。
この方針はtmuxでClaude CodeとCodexを連携させて一晩放置でゲームを作らせる実践編みたいな常駐運用とは相性が悪いが、今のIssue形状だと長寿命セッションを信じすぎるほうが危ない。

プロンプト側では、ツール前の説明を短くする、1メッセージで複数のツール呼び出しを詰めない、実行したい操作を小さく分ける。
これは根本修正ではないが、Issue上では「長いセッション」「大量編集」「ツール呼び出し連打」で発火した報告が多い。 #63800でも、2時間ほど使った後にツール呼び出し前で固まり、let me ... で終わるメッセージの後に再現するという報告が出ている。
同じ court 署名ではないが、長い会話でツール呼び出しへ移る直前に止まる点は共通している。

Claude Codeの内部実装やBunランタイムの話は、Claude Codeのソースコード全公開とOpenAI Codexのトークン窃取脆弱性が同時期に発覚で以前見た。
今回の court はソース流出やローカルツールの脆弱性ではなく、モデル出力とハーネスの境界で壊れている。
画面にraw <invoke> が出た時点で、ツール側のログを追うよりセッションJSONLとIssue番号を添えて /bug するほうが情報として使いやすい。

参考