目次
Claude Codeに長めの作業をさせていると、応答の途中で突然こう出て止まることがある。
API Error: Connection lost mid-response. The response above may be incomplete.
この文言をそのまま検索すると、なぜか出てくる情報が少ない。理由ははっきりしていて、これは比較的新しい名前だからだ。Claude Code公式のエラーリファレンスには、この一文がそのまま書かれている——「v2.1.227より前は、Connection lost mid-response は Connection closed mid-response と表示されていた」。つまり中身は前からある事象で、表示される単語だけが closed から lost に替わった。ネット上の既存情報が旧名称で書かれているせいで、新しい名前で検索した人が何も見つけられなくなっている。
本記事は、この改名の事実を起点に、①メッセージの正確な意味 ②いま画面の前でやること ③なぜ自動で再試行されないのか ④切れている層の切り分け ⑤環境変数での調整 ⑥よく似た別メッセージとの区別を、公式ドキュメントと公開Issueだけを根拠に整理する。推測が混じる部分には、そのつど確度のラベルを付ける。
画面に出た分は消えていない。continue と返せば、最後に完了したブロックの続きから再開できると公式が案内している。
v2.1.227より前は Connection closed mid-response という表示だった。旧名称の情報もそのまま使える。
手元・経路・サーバ側のどこで切れているかで打つ手が変わる。生のHTTPSは通るのにClaude Codeだけ落ちる報告もある。
1. まず最初にやること——画面の出力は消えていない
対処の前に、いちばん誤解されやすい点をはっきりさせておく。このメッセージが出ても、それまでに画面へ流れてきた内容は保持されている。捨てられていない。
公式エラーリファレンスは、末尾が「The response above may be incomplete.（上の応答は不完全かもしれません）」で終わる一群のメッセージについて、こう説明している——Claudeがテキストのブロックやツール呼び出しをひとつ完了させたあとでストリーミングが失敗した場合、リクエストを送り直すと同じツール呼び出しを二重に実行してしまう恐れがあるため、Claude Codeは完了した分をそのまま残し、ターンを捨てる代わりにこの注記を付ける。
したがって、やることは3手だけだ。
Claude Codeは完了したブロックはすべて残すが、ターンが終わる時点で途中だった最後のブロックは捨てる。欠けているのは末尾の数文か、最後のツール呼び出しであることが多い。
continue と返す公式の復帰手順そのものだ。最後に完了したブロックから続けさせる。最初から指示をやり直さない——すでに実行済みの操作を重ねて走らせることになる。
ファイル書き込みやコマンド実行の途中で切れた場合、どこまで実行されたかは画面の記録が正。git status などで実際の状態を見てから続きに進む。
-p 実行やAgent SDK、クラウドセッションのような非対話セッションでは、切れた応答がテキストのみでツール呼び出しを含まない場合、Claude Codeが自分でClaudeに続きを促す——最大3回連続まで。この注記が出るのは、その継続を使い切ったあとだけだ。サブエージェントも同様に自動継続する。
2. 公式の定義——「途中で切れた」4つのメッセージ
まず押さえておきたいのは、この文言はClaude Codeが自分で付けている注記であって、APIが返したエラーレスポンスの本文ではないという点だ。だから同じ「途中で切れた」でも、Claude Codeは原因ごとに末尾の言い回しを変えている。公式リファレンスが列挙しているのは次の4つだ。
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.
公式の説明はひと言——「接続が切れた」。ストリームは正常に流れていたが、それを運んでいた接続そのものが失われた。
ストリームの途中でoverloadedや5xxが発生。公式によればこの表示自体がv2.1.199以降で、それ以前は途中出力を捨ててターン全体をエラー扱いにしていた。
応答の途中でPCがスリープしたことをClaude Codeが検出した場合。復帰後は接続が壊れたものとして読み取りをやめる。
接続は開いたままなのにデータが来なくなり、ストリーム監視タイマーが打ち切った場合。切断ではなく停止で、原因も対処も別。
4枚のうち自分がどれを見たのかを、まず正確に読み取ってほしい。「途中で切れた」という体験はどれも同じに見えるが、Claude Codeはすでに原因を切り分けたうえで文言を選んでいる。lost と出ているなら、それは接続が失われたという判定であって、サーバが5xxを返したのでもタイムアウトしたのでもない。
3. v2.1.227で「closed」から「lost」に改名された
ここが本記事の中心だ。公式エラーリファレンスは、4つの説明を並べたすぐあとに、注意書きとして次の一文を置いている。
「v2.1.227より前は、Connection lost mid-responseはConnection closed mid-responseと表示され、The response stopped arrivingはResponse stalled mid-streamと表示されていた」
——Claude Code公式エラーリファレンス（拙訳）
つまり2つの文言が同時に付け替えられている。対応関係を表にするとこうなる。
| v2.1.227より前の表示 | 現在の表示 | 意味（公式） |
|---|---|---|
Connection closed mid-response |
Connection lost mid-response |
接続が切れた |
Response stalled mid-stream |
The response stopped arriving |
接続は開いたままデータが来なくなった |
Connection closed while thinking, before producing a response |
Connection lost before a response was produced |
出力が1文字も出る前に切れた（＝途中出力なし） |
Response stalled while thinking, before producing a response |
The response stalled before a response was produced |
出力が1文字も出る前に、接続は開いたまま止まった |
3行目は本記事のメッセージとは別物なので注意してほしい。mid-response は「途中まで出力が出たあとに切れた」、before a response was produced は「1文字も出ないうちに切れた」——同じ改名の対象だが、意味も出たあとの挙動も違う。詳しくは次章で扱う。
この改名がわかると何が変わるか
実務上の効き目は3つある。
「Connection closed mid-response」で検索すれば、GitHub Issueも解説記事も一気に増える。同じ事象なので読み替える必要はない。
lost と出ているなら、そのClaude Codeはv2.1.227以降だと分かる。逆に closed と出るなら、それより古い。
同じ現象が2つの名前で報告されているため、issue検索は両方の文言で当たらないと既存報告を見落とす。
⚠️ v2.1.222 より前は、そもそも誤報の可能性がある。公式エラーリファレンスは「v2.1.222 より前の Claude Code は、応答が完了したあとに接続が切れたり停滞したりした場合にもこの通知を出し、完全な応答なのにターンをエラーとして報告していた」と明記している。つまり古い版では、出力が全部届いているのにエラー表示だけが出る。claude --version が 2.1.222 より小さいなら、切り分けを始める前にまず更新してほしい——見えているエラーが実在しない可能性がある。
4. なぜ自動で再試行してくれないのか
Claude Codeは何もしていないわけではない。公式リファレンスの「Automatic retries」によれば、一時的な失敗は指数バックオフで最大10回まで自動再試行される。それでもこのメッセージが出るということは、Claude Codeが「ここは再試行してはいけない」と判断したということだ。
分岐しているのは「Claudeがすでに何かを完了させていたか」の一点だけだ。
思考を含めClaudeが応答のどの部分も完了させていないうちに接続が落ちた場合、Claude Codeは同じバックオフでリクエストを送り直し、ターンは続く。テキストが流れ始めていても同じだ。
思考は終わったがテキストもツール呼び出しも始まっていない段階なら、短い間隔で最大2回だけ送り直し、それでも落ち続けると Connection lost before a response was produced でターンを終える。
テキストのブロックかツール呼び出しをひとつ完了させた（あるいは思考のあとに開始した）あとで切れた場合、Claude Codeはリクエストを送り直さない。同じツール呼び出しを二重に実行しかねないからだ。
代わりに、完了した分を保持し、完了済みのツール呼び出しは実行してその結果からターンを続ける。そのうえでこの注記を出す。
この設計は不便に見えて、実は安全側に倒してある。もし自動で送り直していたら、「ファイルを書き換えた」「コマンドを実行した」といった副作用のある操作が、切断のたびに二重に走りかねない。だから公式は再送ではなく continue を案内している——それが「もう終わった作業をやり直させない」唯一の道だからだ。
リトライ中に画面に出るもの
再試行が走っている間、スピナーの脇には Retrying in Ns · attempt x/y のカウントダウンが出る。ラベルは最初は API error だが、v2.1.198以降は3回目の試行から具体的な理由に切り替わる（CLAUDE_CODE_MAX_RETRIES が3未満なら最後の試行で切り替わる）。
また、リクエストが生きたままデータが20秒来ないと、まだ失敗する前の段階で Waiting for API response · will retry in … · check your network というバナーが出る。これは「まだ失敗していない」という意味の表示で、カウントダウンはClaude Codeが停滞した接続を打ち切る時点までを指す。公式によればこのしきい値はv2.1.185より前は10秒で、文言も違っていた。
5. どこで切れているのか——3つの層
「接続が切れた」とだけ言われても打つ手が決まらない。切れうる場所は大きく3つで、それぞれ確かめ方が違う。
Wi-Fiの切り替わり、モバイル回線の瞬断、スリープ、VPNクライアントの再接続。
確かめ方：有線や別回線で再現するか。スリープが原因なら専用の文言が出るので、そこで切り分けられる。
企業プロキシ、TLS検査、LLMゲートウェイ、VPN。長時間開きっぱなしのストリームをアイドルとみなして切る装置は珍しくない。
確かめ方：HTTPS_PROXY を外して再現するか。/status でプロキシ行を確認する。
サービス側の障害、あるいは使い回している接続が実は死んでいたケース。手元の回線は健全なのに落ち続けるのが特徴。
確かめ方：status.claude.com を見る。複数の回線で同じように再現するなら手元だけの問題ではない。
claude --debug のログに Stale connection — reloaded rotated mTLS client material が出るかで確認できる。
6. いま試すこと——切り分けチェックリスト
上から順に、効果が大きく手間が小さい順に並べてある。1つ試すごとに再現するか確かめてほしい。
| # | やること | 狙い |
|---|---|---|
| 1 | continue と返す | まず損失を確定させない。やり直しより速く、二重実行の危険もない |
| 2 | Claude Codeを最新へ更新する | 接続まわりの挙動は版で変わる。v2.1.198で「応答途中の短いネットワーク断がターンを中断する」問題が修正されている |
| 3 | 1ターンを短く割る | 「大量のファイルを読んでレポートを書く」を読み込みと執筆に分ける。ストリームが開いている時間そのものを減らす |
| 4 | VPN・プロキシを外して再現する | 層2の切り分け。外して直るなら経路側のアイドル切断を疑う |
| 5 | 別の回線で再現する | 層1と層3の切り分け。複数回線で同じなら手元だけの問題ではない |
| 6 | スリープ設定を見直す | 長い応答の途中で画面が消える環境なら、専用の文言が出る前に接続が壊れている可能性がある |
| 7 | status.claude.com を見る | 層3の確認。529のときはClaude Code自身がこのホスト名を画面に出す |
| 8 | claude --debug で記録を取る | ログは ~/.claude/debug/<session-id>.txt に出る。報告するときはこれを添える |
| 9 | SOCKSプロキシを使っていないか確認する | 公式ドキュメントはSOCKSプロキシを非対応と明記している。使っているなら別の経路にする |
7. タイマーとリトライを環境変数で調整する
Claude Codeは、応答が静かになったストリームを打ち切るために4つの独立したタイマーを持っている。公式のネットワーク設定ドキュメントが挙げている一覧はこうだ。
| タイマー | 打ち切る条件 | 既定のタイムアウト |
|---|---|---|
| First-byte deadline | 送信後、レスポンスヘッダが1つも来ない | 直APIで180秒／それ以外300秒（＋リクエスト本体32KBごとに1秒） |
| Event-level watchdog | レスポンスのイベントが1つもパースできない | 300秒（全プロバイダで動く） |
| Byte-level watchdog | SSEのキープアライブpingを含め、バイトが一切来ない | 直APIで180秒／それ以外300秒 |
| Body idle timeout | 5分間バイトが来ない | 5分（直API以外のプロバイダ向け） |
ただし、これらのタイマーが打ち切った結果は基本的に「無音」側の文言になる——本記事のメッセージとは別だ。ここを載せているのは、両方を見分けるために既定値を知っておく必要があるからで、「lostが出るからタイマーを伸ばそう」という話ではない。プロキシ越しで長い沈黙が起きる環境なら、この値をいじると停止側の症状は変わる。
リトライの側は次の変数で調整できる。
| 環境変数 | 既定 | 効果 |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES |
10 | 再試行の回数。v2.1.186以降は15が上限。スクリプトでは下げて早く失敗させる使い方が推奨されている |
CLAUDE_CODE_RETRY_WATCHDOG |
未設定 | CIなど無人セッション向け。1 にすると429／529を無期限に再試行し、v2.1.199以降は切断を含む一時エラーの既定回数を300へ引き上げる |
API_TIMEOUT_MS |
600000 | 1リクエストあたりのタイムアウト（ミリ秒＝10分）。遅い回線やプロキシでは引き上げる |
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS |
未設定 | バイト監視だけのタイムアウト。10秒〜30分にクランプされる |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS |
未設定 | 最初の1バイトまでの期限を直接指定する。v2.1.242以降で使える |
CLAUDE_CODE_MAX_RETRIES を上げて効くのは「出力が出る前に落ちる」ほうの失敗であって、途中で切れた分には効かない。効くのは1ターンを短くすることのほうだ。
8. 似たメッセージとの見分け方
ここが読者にとっていちばん実利のある部分かもしれない。「途中で止まった」という体験は共通でも、Claude Codeが出している文言は違い、原因も対処も違う。当サイトの既存記事との対応も含めて整理する。
| 画面に出る文言 | 起きていること | どこを読むか |
|---|---|---|
Connection lost mid-response |
途中まで出力が出たあとに接続が失われた | 本記事 |
Connection closed mid-response |
同じ事象の旧名称（v2.1.227より前） | 旧名称時代の報告をまとめたclosed の記事 |
The response stopped arriving旧： Response stalled mid-stream |
接続は生きているが無音になり、タイマーが打ち切った | stalled の記事（反復ループとの連鎖に注意） |
Server error mid-response |
ストリームの途中でサーバ側が5xx／overloaded | 529／500の記事 |
Your computer went to sleep mid-response |
応答中にPCがスリープしたとClaude Codeが検出 | 電源・スリープ設定を見直す（本記事第6章） |
Connection lost before a response was produced |
1文字も出ないうちに切れた（途中出力なし） | 再試行の対象。本記事第4章 |
Unable to connect／SSL証明書エラー |
そもそも接続できていない | ネットワーク・プロキシの記事 |
court／invokeタグが本文に出る |
通信ではなくツール呼び出しが実行されていない | courtタグの記事 |
いちばん大きな分岐は「画面に応答が出たかどうか」だ。1文字も出ていないなら、そもそも接続や設定（プロキシ・証明書・ファイアウォール）を疑う番になる。途中まで出ているなら、それは接続できていた証拠なので、設定をいじるより本記事の切り分けに進むほうが正しい。
2つ目の分岐は「切断か、無音か」
接続が失われたのか、開いたまま黙り込んだのかで、次の一手は真逆になる。
経路と接続の再利用を疑う。タイムアウト値を伸ばしても意味がない——時間切れではなく、接続そのものが無くなっているからだ。
タイマーの出番。CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS などの調整が効く余地があり、モデル側が長時間黙る状況も疑う。
9. 実際の報告——ECONNRESETが止まらないケース
もっとも厄介なのが、手元の回線は完全に健全なのにClaude Codeだけが落ち続けるパターンだ。公開Issueに、検証の手数がかなり多い報告が2件ある。どちらも本記事の新名称で報告されているか、その直前の版の文言を含む。
報告者は Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 のあとに API Error: Connection lost mid-response. が出ると書いている。そのうえで、curl による60KBのPOSTも、素のNode.jsの https.request による同サイズのPOSTも正常に完走し、他ホストからの長時間SSEも途切れなかったと報告している。
MTUの確認、Winsock LSPの確認、最小構成での再現、2つの無関係なネットワークでの再現まで済ませたうえで未解決。Issue #86473は重複としてマークされつつオープンのまま。
こちらは Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10。報告者はセキュリティソフトの完全アンインストール、VPNフィルタ、プロキシ／IPv6、Winsockのリセットまで潰したうえで、3つのネットワーク（社内Wi-Fi・自宅Wi-Fi・スマホのテザリング）で同じように再現したと書いている。
同じ端末・同じアカウントでclaude.aiのチャットは問題なく動くという対比が示されている。Issue #85979もオープン（stale）のまま。
それでも、この2件から言える実用的なことはある。「pingが通る」「curlが通る」は、このエラーが起きない証拠にならないということだ。ストリーミングで数分間1本の接続を開き続ける通信は、短いリクエストとは条件が違う。手元のネットワーク検査に時間を注ぐより、ターンを短く割るほうが再現率を下げやすい。
10. 確定していること／していないこと
誤解を避けるため、公式に確認できることと、そうでないことを分けて示す。
- この文言は公式エラーリファレンスに正式に記載があり、意味は「接続が切れた」
- v2.1.227より前は
Connection closed mid-responseと表示されていた（同じものの改名） - 途中まで流れた出力は意図的に保持される（再送すると二重実行の恐れがあるため）
- 復帰手順は
continueと返すこと - 出力が出る前の切断は自動で再試行される（最大10回・指数バックオフ）
- 非対話セッションとサブエージェントは自分で継続する（それぞれv2.1.246／v2.1.257以降）
- 生のHTTPSは健全なのにCLIだけECONNRESETで落ちる（#86473・#85979の報告）
- 同じ端末・同じアカウントでブラウザ版は無事、という対比（#85979の報告）
- 接続の使い回しに関する不具合が関与している可能性（報告者が引用したサポートの説明）
- 特定の日時にサーバ側の障害があったという言及（同じく報告者経由）
- Anthropicによる原因の公式説明（上の2件のIssueに公開回答はない）
- 改名の理由。CHANGELOGに文言変更の記載が見当たらない
- #86473・#85979はいずれもオープンのまま
要するに、症状・意味・復帰手順は公式に文書化されているが、なぜ切れるのかの公式説明はまだ出ていない。この状況で確実に効くのは、原因の特定より「切れても損失を最小にする」運用だ——ターンを短く割る、副作用のある操作は状態を確認しながら進める、バージョンを新しく保つ。この3つは原因が何であれ効く。
FAQ
Q1. 「Connection lost mid-response」と「Connection closed mid-response」は違うエラーですか？
同じものです。公式エラーリファレンスが明記しているとおり、v2.1.227より前は同じ事象が Connection closed mid-response と表示されていました。表示が変わったからといって、新しい種類の障害が起きたわけではありません。旧名称で書かれた情報もそのまま参照できます。
Q2. それまでの出力は消えますか？
消えません。Claudeが完了させたブロックはすべて残ります。捨てられるのは、ターンが終わる時点で途中だった最後のブロックだけです。Claude Codeがあえて再送せずにこの注記を付けているのは、送り直すと同じツール呼び出しを二重に実行してしまう恐れがあるためです。
Q3. 何と返せば続きから再開できますか？
continue と返してください。公式エラーリファレンスが案内している復帰手順で、最後に完了したブロックから続けさせます。最初から指示をやり直すと、すでに実行済みの操作が重複するおそれがあります。
Q4. リトライ回数を増やせば直りますか？
直りません。第4章のとおり、これはClaude Codeが意図的に再試行を避けている局面の注記だからです。CLAUDE_CODE_MAX_RETRIES（既定10、v2.1.186以降は上限15）が効くのは「出力が出る前に落ちる」ほうの失敗です。効くのは1ターンを短くすることのほうです。
Q5. -p やCI（非対話実行）でも同じですか？
挙動が違います。公式リファレンスによれば、非対話セッションでは、切れた応答がテキストのみでツール呼び出しを含まない場合、Claude Codeが自分で続きを促します——最大3回連続まで。この注記が出るのはそれを使い切ったあとです。v2.1.246より前は、最初の切断でそのままターンを終えていました。--output-format json を使っている場合、このメッセージは result フィールドに入ります。
Q6. サブエージェント（Task）でも出ます。
サブエージェントも同じく自動継続します。切れた応答がテキストのみなら、Claude Codeがサブエージェントに続きを促し、継続を使い切って初めてこの注記が最後のメッセージになります。v2.1.257より前は、最初の切断で注記を出していました。
Q7. 自分のネットワークが悪いのでしょうか？
その可能性はありますが、それだけとは限りません。Issue #86473の報告者は、curl と素のNode.jsによる同サイズのPOSTがどちらも完走することを示したうえで、CLIだけが落ちると報告しています。まずVPN／プロキシを外して再現するか確かめ、次に別回線で試してください。両方とも変わらなければ、手元だけの問題ではないと判断できます。
Q8. タイムアウトを伸ばせば減りますか？
このメッセージについては期待できません。時間切れではなく接続そのものが失われた、という判定だからです。タイマー（CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS など）を伸ばして効くのは The response stopped arriving、つまり接続は生きているのに無音になるほうの症状です。
Q9. どのバージョンを使っているか確認するには？
claude --version で確認できます。画面に lost と出ているならv2.1.227以降、closed と出ているならそれより前です。接続まわりの挙動は版によって変わっており、公式CHANGELOGではv2.1.198で「応答途中の短いネットワーク断がターンを中断していた問題」が修正されています。更新は最初に試す価値が高い一手ですが、根治の保証ではありません——上で挙げた2件のIssueは、どちらもそれより新しい版での報告です。
Q10. 企業ネットワークで頻発します。見るべき設定は？
公式のネットワーク設定ドキュメントが要点を押さえています。①SOCKSプロキシは非対応なので使わない、②プロキシ変数はシェルのexportではなく ~/.claude/settings.json の env ブロックに置く（バックグラウンドのエージェントにはシェルの環境が届かないため）、③mTLSを使っているなら証明書のローテーションに注意する——の3点です。設定が読めたかどうかは claude --debug のログか /status の表示で確認できます。
関連記事
- API Error: Connection closed mid-responseの原因と対処——Claude Codeで応答が途中で切れる
- Claude Codeで「court」が無限ループしResponse stalled mid-streamで止まる——原因と対処
- Claude Codeのネットワーク・プロキシ・TLS証明書エラー（Unable to connect）の原因と対処
- Claude Codeの「529 Overloaded」「500」サーバーエラーの原因と対処
- Claude Codeで「court」やinvokeタグが出力される——ツール呼び出しが実行されないエラーの原因と対処
- Claude Codeのよくあるエラーと対処法まとめ
参考にした一次情報
- Claude Code — Error reference（公式ドキュメント）：4つの文言の定義、v2.1.227の改名、
continueによる復帰、Automatic retriesの分岐、環境変数 - Claude Code — Enterprise network configuration（公式ドキュメント）：4つのストリーム監視タイマーと既定値、プロキシ設定、SOCKS非対応、mTLSの再読み込み
- anthropics/claude-code — CHANGELOG（公式）：v2.1.198「応答途中の短いネットワーク断がターンを中断していた問題」の修正
- Issue #86473 — ECONNRESET / Connection lost mid-response（v2.1.229 / Windows 11）
- Issue #85979 — ECONNRESET が v2.1.228 でも継続（Windows 11）
- Claude のサービス稼働状況（公式ステータスページ）
