Claude Codeの「Connection closed mid-response」、実は応答が完了した後に出ていた——v2.1.222で直った誤表示バグと、紛らわしいバグ5兄弟の正体
Claude Codeで「Connection closed mid-response」と表示されるのに応答自体は完了しているケースをv2.1.222の修正内容から解説。同時期に直った紛らわしい表示バグ(ストリームタイムアウト誤発火・部分出力の破棄・ターミナルフリーズ・描画停止)を整理し、本当に落ちているかの見分け方と対処法をまとめた。
エンジニアのゆとです。
長めのタスクをClaude Codeに投げて、コードが最後まで生成し終わった直後にConnection closed mid-responseと赤字で出た経験がある人、たぶん結構いる。
見た瞬間「うわ、途中で切れた」と思う。もう一回同じ指示を投げ直そうとして、念のためファイルを確認したら——普通に最後まで書き終わっている。壊れてない。なのにエラーだけは出ている。
これ、バグだった。しかも1個じゃない。7月から8月にかけてのアップデートで、似たような「見た目はエラーなのに実害がない、あるいは逆に実害があるのに何も表示されない」系の紛らわしい挙動がまとめて5件直っている。今回はその全体像と、実際に自分のセッションが壊れているのかどうかの見分け方を整理する。
結論 — まずこの表で自分の症状を確認する
| 症状 | 直った版 | 実際に起きていたこと | 今すぐできる対処 |
|---|---|---|---|
応答が最後まで出た直後にConnection closed mid-responseが出る | v2.1.222 | 応答は完了していたのに、完了検知のタイミングがズレて誤ってエラー扱いされていた | アップデートすれば消える。出ても再実行は不要、まず結果を確認する |
ANTHROPIC_BASE_URLをカスタムゲートウェイに向けているとき、通信は生きているのに接続が切られる | v2.1.221 | サーバーのkeep-aliveパケットは届いているのに、アイドルタイムアウトの判定が誤発火していた | アップデート後に再現するか確認。社内プロキシ経由の人は特に対象 |
| Anthropic側が混雑しているときに、出力が途中まで表示されてから丸ごと消える | v2.1.199 | overloaded/server errorがストリーム中に発生すると、それまでの出力ごと破棄されていた（今は「未完了」の注記付きで残る） | アップデートすれば途中出力が残るようになる。それ以前のバージョンでは自衛策が必要（後述） |
| 長いコードブロックや表を出力中に、キー入力が効かなくなる・カクつく | v2.1.206 | ターミナルの再描画処理が長大な出力に追いつかず固まっていた | アップデートで解消。凍った場合はCtrl+Cを1回、それでもダメなら後述の見分け方へ |
| 画面が完全に固まって何も表示されなくなるのに、プロセス自体は裏で動き続けている | v2.1.228 | まれな内部レイアウトエラーで再描画が止まっていた（処理自体は継続） | アップデートで解消。固まった場合、プロセスが生きているかはpsで確認できる（後述） |
自分のケースがどれに近いか分かったら、該当の見出しまで読み飛ばしてもらって構わない。全部通しで読みたい人は上から。
ケース1: Connection closed mid-responseは「完了後」に出ていた
一番報告が多いのがこれ。v2.1.222のchangelogにはこう書かれている。
Fixed “Connection closed mid-response” errors being reported on responses that had actually completed
直訳すると「実際には完了していた応答に対してConnection closed mid-responseエラーが報告されていたのを修正した」。つまりバグの本質は通信断そのものではなく、「応答が完了したかどうかの判定」と「エラー表示のタイミング」がズレていたことにある。
ストリーミングでレスポンスを受け取る仕組み上、Claude Code側は「もうこれ以上データが来ない」と確定するまでの間に、何らかの理由で内部的な待機がわずかに長引く瞬間がある。そこでタイムアウト判定が先に走ってしまうと、実際にはデータを受け取り切っているのに「接続が切れた」という扱いでエラーメッセージだけが表示される。ファイル自体はすでに書き込まれている、コミットも走っている、テストも通っている——なのに画面には赤字のエラーだけが残る、という状態になる。
厄介なのは、これが「本物の接続断」と見た目上まったく区別がつかないことだ。本物の接続断（Wi-Fiが切れた、VPNがタイムアウトした等）でも同じメッセージが出るし、実害があるケース（本当に途中で切れて出力が欠けている）も存在する。だからこそ「エラーが出た＝壊れた」と反射的に判断せず、まず結果を確認する癖をつけておくと無駄な手戻りを防げる。
ケース2: カスタムゲートウェイ経由だと、生きてる接続が誤って切られていた
社内プロキシや自前のAPIゲートウェイ経由でANTHROPIC_BASE_URLを設定して使っている人向けの話。v2.1.221のchangelogにはこうある。
Fixed stream idle timeout firing on custom
ANTHROPIC_BASE_URLgateways despite server keep-alive pings arriving on the wire
サーバー側は接続維持のためのkeep-aliveパケットをちゃんと送ってきているのに、Claude Code側のアイドルタイムアウト判定がそれを正しく認識できず、生きている接続を「反応がない」と見なして自分から切っていた、という不具合。企業でカスタムゲートウェイを噛ませている環境ほど遭遇しやすく、個人のPro/Maxプランで直接APIに繋いでいる人にはあまり関係ない。心当たりがあるならアップデート後に再現するか見ておくといい。
ケース3: 混雑時、途中まで出た出力が丸ごと消えていた（今は残る）
これは表示バグというより「保存されるべきものが保存されていなかった」系の実害寄りのバグ。v2.1.199のchangelogから。
Fixed streaming responses being discarded when the API emits a mid-stream overloaded/server error after partial output — the partial is now kept with an incomplete-response notice
Anthropic側が混雑してoverloadedエラーやサーバーエラーがストリームの途中で発生すると、それ以前に受信していた出力ごと全部破棄されていた。長いコードを生成中にAPI側の過負荷が起きると、せっかく途中まで出ていた分もろとも消えて「最初から」になっていたということだ。
v2.1.199以降はこの挙動が変わっていて、部分的な出力が「未完了」の注記付きでちゃんと残るようになっている。過負荷そのものは無くならないが、少なくとも「途中まで書いてくれた分」を見ながら続きを指示できるようになったのは実務上の差が大きい。
ケース4・5: ターミナルが固まる、画面が完全に止まる
残り2つは表示・描画まわりの不具合。似ているようで原因は別物。
**ケース4（v2.1.206）**は、長いリストや表、長大なコードブロックをストリーミング出力しているときにターミナルの再描画処理が追いつかず、キー入力が効かなくなったりカクついたりする不具合。処理自体は進んでいるが、UIの更新が重くて操作感が「固まった」ように見える。
**ケース5（v2.1.228）**は、まれな内部レイアウトエラーが起きた際にセッションの再描画が完全に止まってしまう不具合。ここが一番紛らわしいポイントで、画面が完全にフリーズしていても、プロセス自体は裏で処理を継続していることがある。画面だけ見て「固まった＝止まった」と判断してCtrl+Cで強制終了すると、実は最後まで走り切っていたはずの処理を自分で打ち切ってしまうことになる。
同じv2.1.228では、これとは別の系統のバグとして/modelでモデルを切り替えた直後に/tuiを使うと、セッションが以前のモデルに巻き戻って表示される不具合も修正されている。実害というより表示上の混乱だが、「モデルを変えたはずなのに反映されていない」と焦る人が出そうな類のバグなので併記しておく。
本当に落ちているのか、表示がおかしいだけなのかの見分け方
ここが一番実用的な部分。エラーやフリーズが出たときに、パニックになって再実行やCtrl+Cを連打する前に、次の順番で確認する。
1. まずファイルの状態を見る
エディタやターミナルの別タブで、Claude Codeが編集していたはずのファイルを直接開く。書き込みが完了しているなら、それは「表示バグ」だった可能性が高い。
git status
git diff --stat途中までしか書かれていない、あるいは全く変更されていないなら、実際に処理が止まっている可能性がある。
2. プロセスが生きているか確認する
画面が固まって何も反応しないとき、別のターミナルからプロセスの状態を見る。
ps aux | grep claudeCPU使用率が動いている、あるいは時間経過とともにファイルのタイムスタンプが更新されているなら、裏では処理が継続している。
watch -n 1 ls -la --time-style=full-iso .3. claude doctorでインストール状態を確認する
エラーが再現性を持って出る場合、インストールや設定自体に問題がないかを確認しておく。
claude doctorセッションを新規に開始せずに、インストールの健全性や設定ファイルのバリデーションエラーを読み取り専用で表示してくれる。
4. バージョンを確認する
ここまでのバグはすべて、対応するバージョン以降なら発生しない。まず自分がどのバージョンを使っているかを確認する。
claude --versionv2.1.222より前ならConnection closed mid-responseの誤表示に、v2.1.228より前ならケース5の描画停止に、それぞれ該当バージョンまでは遭遇し得る状態にある。
対処法 — アップデートする
原因が判明している以上、対処はシンプルにアップデートが最優先になる。
claude updatenpm経由でグローバルインストールしている場合はこちらでも上げられる。
npm update -g @anthropic-ai/claude-codeアップデート後はclaude --versionで反映されたか必ず確認する。ここで「成功と出たのにバージョンが変わらない」という別のバグに遭遇した場合は、複数インストールの競合や権限まわりが原因のことが多い。
アップデートしてもなお同じ症状が出る場合は、既知のバグではなく別の原因（ネットワーク環境、OS固有の問題など）を疑う段階になる。GitHubのIssueで同じ症状の報告がないか検索するのが早い。
なぜこの手の「誤表示バグ」がまとまって出やすいのか
Claude Codeはローカルのターミナルと、Anthropicのサーバー間でストリーミング通信をしながら、届いたトークンをその場で画面に描画するという処理を常に並行して行っている。「通信が生きているか」「応答が完了したか」「画面の描画が終わっているか」は本来それぞれ独立した状態のはずだが、実装上はタイミングがシビアに絡み合っている。
だからこそ、この3つのどれか1つでも判定がわずかにズレると、実態とは違う情報がユーザーに見える。今回まとめた5件は根本原因もバージョンもバラバラだが、共通しているのは「実際の状態」と「画面に出ている情報」が一致していなかった、という一点だけだ。フリーズやエラー表示そのものを完全にゼロにするのは技術的に難しくても、せめて「これは本当に落ちているのか」を自分で確認できる手順を持っておくと、無駄な再実行やタスクの中断を避けられる。
FAQ
Connection closed mid-responseが出たら、その場でもう一度同じ指示を出し直すべき？
いきなり再実行しないほうがいい。まずgit statusやファイルの中身を確認して、実際に処理が完了しているかを見る。完了していれば再実行は二度手間になるし、意図せず同じ変更を重ねてコンフリクトの原因にもなる。
アップデートしても同じエラーが再現する場合は？
既知の5件のバグはいずれも該当バージョン以降で解消しているはずなので、再現するなら別原因の可能性が高い。ネットワーク環境（VPN・社内プロキシ）、OS側のスリープ復帰直後、ディスク容量不足などを疑い、それでも分からなければGitHub Issueで同じ症状が報告されていないか検索するのが早い。
画面が完全にフリーズして何も操作できない場合、どうすればいい？
まず別のターミナルからps aux | grep claudeでプロセスが生きているか確認する。生きていてファイルも更新され続けているなら、そのまま待つのが安全。反応がなく、ファイルも一切更新されていないなら、Ctrl+Cで終了してセッションを立て直す。
まとめ
Connection closed mid-responseをはじめとする一連の表示バグは、どれも「実際の処理状態」と「画面表示」がズレていただけで、多くのケースで実害はなかった。とはいえ、エラーメッセージを見た瞬間に反射で再実行やCtrl+Cをしてしまうと、逆に正常に終わりかけていた処理を自分で潰すことになりかねない。
エラーが出たら、まずgit statusでファイルの実態を確認する。フリーズしたら、まずps auxでプロセスの生死を確認する。そのうえでclaude --versionを見て、該当バージョンより古ければアップデートする——この順番さえ守れば、見た目のエラーに振り回される回数はかなり減らせるはずだ。
