まず、この症状に当てはまりそうかを切り分けるなら、Claude Code の応答が途中で切れたあとに、次のような文字列が出ているかを見るのが早いです。
API Error: Server error mid-response. The response above may be incomplete.
今回の対象になっているのは、上のエラー文字列で終わるケースです。参照した issue は #79854 と #87692 です。どちらも closed ですが、報告内容を見る限り、この手の失敗は「途中でサーバー側のエラーに切り替わったストリーム」が起点になっています。
#79854 では、ストリーミング応答がサーバーエラーで中断されたとき、Agent SDK 側の最終結果は次の形だったと報告されています。
ResultMessage(
is_error=True,
subtype="success",
result="API Error: Server error mid-response. The response above may be incomplete."
)
ここで重要なのは、エラー表示そのものよりも、付随する OpenTelemetry の扱いです。報告では claude_code.llm_request と、それを囲む claude_code.interaction の両方が UNSET のままだったとされています。つまり、見た目は失敗していても、計測上はエラーとして上がっていなかった、という話です。これはトレースや監視を見ている人には厄介です。失敗はしているのに、エラーとして集計されないからです。
一方、#87692 は少し違う角度ですが、同じく API ストリームの失敗を扱っています。こちらでは、長時間の無人セッションでストリームが途中で黙り込むこと、そして claude --print --output-format stream-json のような headless の worker subprocess が retryable な 429/5xx で致命的に落ちることが報告されています。報告者は、運用上見える「stream halt」の原因として、この API stream failure を挙げています。少なくとも issue 本文の範囲では、クライアント側の耐障害性に穴がある、という整理です。
ただし、ここで注意したいのは、今回の二つの issue からは「どう直すか」までは確定できないことです。手元の一次情報として与えられているのは、症状の報告と環境情報だけで、再現手順や恒久対処はありません。したがって、現時点で言えるのは次の範囲までです。
API Error: Server error mid-response. The response above may be incomplete. で終わるケースがあるUNSET のままだったこの症状に遭遇したとき、最初に確認したいのは「単なる出力切れ」ではなく、応答が途中で server error に変わっているかどうかです。エラー文が上の文字列そのものなら、少なくとも同種の事例に入っている可能性は高いです。逆に、別の文言や別の終了の仕方なら、同じクラスとは限りません。
現状、与えられた情報だけでは、利用者側でできる確実な回避策は確認できません。closed にはなっていますが、issue の本文から読み取れる事実は「このエラーは出る」「計測は UNSET のことがある」「stream halt の一因になりうる」という点までです。そこから先は分かりません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-05T08:52:34+09:00