Содержание

Когда 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 — работа продолжится с последнего завершённого блока.

② Про название
Переименованный closed

До v2.1.227 на экране было Connection closed mid-response. Материалы под старым названием применимы без поправок.

③ Если повторяется
Разделите слои

Действия зависят от того, где рвётся: на машине, на маршруте или на стороне сервиса. Есть отчёты, где обычный HTTPS проходит, а падает только Claude Code.

1. Первое, что стоит сделать — вывод на экране никуда не делся

Прежде чем что-то чинить, снимем главное недоразумение. Даже когда появилось это сообщение, всё, что успело появиться на экране, сохраняется. Ничего не выбрасывается.

Официальный справочник ошибок объясняет группу сообщений, которые заканчиваются словами «The response above may be incomplete.», так: если стриминг сорвался уже после того, как Claude завершил блок текста или вызов инструмента, повторная отправка запроса грозит выполнить тот же вызов инструмента дважды, поэтому Claude Code сохраняет завершённую часть и вместо того, чтобы выбросить ход целиком, добавляет эту пометку.

Значит, действий всего три.

Шаг 1
Прочитайте сохранившийся вывод

Claude Code сохраняет все завершённые блоки, а последний блок, который на момент окончания хода был ещё не дописан, отбрасывает. Чаще всего не хватает пары фраз в конце либо последнего вызова инструмента.

Шаг 2
Ответьте continue

Это ровно та процедура восстановления, которую описывает документация: работа продолжится с последнего завершённого блока. Не повторяйте исходное задание с нуля — так уже выполненные операции запустятся повторно.

Шаг 3
Проверьте операции с побочными эффектами

Если обрыв случился посреди записи файла или выполнения команды, истина о том, что успело выполниться, — это запись на экране. Посмотрите фактическое состояние через git status и только потом идите дальше.

Вне интерактивной сессии продолжение происходит само. По официальному справочнику, в неинтерактивных сессиях — запуск с -p, Agent SDK, облачные сессии — Claude Code сам просит Claude продолжить, если оборванный ответ состоял только из текста и не содержал вызовов инструментов: до трёх раз подряд. Пометка появляется только тогда, когда эти продолжения исчерпаны. Субагенты продолжают работу так же автоматически.

2. Официальное определение — четыре сообщения об обрыве

Первое, что стоит усвоить: эта фраза — пометка, которую добавляет сам Claude Code, а не тело ответа с ошибкой, пришедшее от API. Поэтому при внешне одинаковом «оборвалось на середине» Claude Code меняет концовку формулировки в зависимости от причины. Официальный справочник перечисляет четыре варианта.

API Error: Server error mid-response. The response above may be incomplete.
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.
Тема этой статьи
Connection lost mid-response

Официальное пояснение состоит из одной мысли — «соединение потеряно». Поток шёл нормально, но пропало само соединение, которое его несло.

Сбой на стороне сервера
Server error mid-response

Посреди потока пришёл overloaded или 5xx. По документации сам этот текст появился только в v2.1.199: раньше частичный вывод выбрасывали и весь ход считали ошибкой.

Причина на вашей стороне
Your computer went to sleep mid-response

Claude Code обнаружил, что компьютер ушёл в сон посреди ответа. После пробуждения соединение считается разрушенным, и чтение прекращается.

Не обрыв, а тишина
The response stopped arriving

Соединение остаётся открытым, но данные перестают приходить, и сторожевой таймер потока обрывает ожидание. Это остановка, а не разрыв: причина и лечение другие.

Сначала точно определите, какую из четырёх карточек вы видели. Ощущение «оборвалось на середине» во всех случаях одинаковое, но Claude Code выбирает формулировку уже после того, как разобрался с причиной. Если написано lost, это вердикт «соединение потеряно», а не «сервер вернул 5xx» и не «истёк таймаут».

3. В v2.1.227 «closed» переименовали в «lost»

Здесь центр статьи. Сразу после четырёх пояснений официальный справочник ошибок помещает такое примечание.

«До v2.1.227 Connection lost mid-response отображалось как Connection closed mid-response, а The response stopped arriving — как Response stalled mid-stream»
— официальный справочник ошибок Claude Code (перевод автора)

То есть две формулировки заменили одновременно. Если свести соответствия в таблицу, получится вот что.

Текст до 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 Обрыв до того, как вышел хоть один символ (частичного вывода нет)
Response stalled while thinking, before producing a response The response stalled before a response was produced Остановка при открытом соединении до того, как вышел хоть один символ

Обратите внимание: третья строка — не то же самое, что сообщение из этой статьи. mid-response означает «оборвалось после того, как часть вывода уже появилась», а before a response was produced — «оборвалось, не выдав ни символа». Переименование затронуло обе строки, но смысл и последующее поведение у них разные. Подробнее — в следующей главе.

Что меняет знание об этом переименовании

Практическая польза здесь тройная.

Старые материалы применимы как есть

По запросу «Connection closed mid-response» сразу находятся и issue на GitHub, и разборы. Явление то же самое, переводить в уме ничего не нужно.

Это подсказка о версии

Если на экране lost, значит ваш Claude Code — v2.1.227 или новее. И наоборот: closed означает более старую сборку.

Помогает искать дубликаты issue

Одно и то же явление заведено под двумя именами, поэтому искать issue нужно по обеим формулировкам, иначе существующий отчёт останется незамеченным.

🟡 В CHANGELOG этого нет. Переименование описано только в официальной документации: в пределах проверки автора в пункте v2.1.227 официального CHANGELOG изменение формулировки не упомянуто. Со стороны пользователя это выглядит так, будто слово в один день просто поменялось. Не делайте из смены текста вывод, что «появилась какая-то новая ошибка».

⚠️ До v2.1.222 сообщение вообще могло быть ложным. Официальный справочник ошибок прямо пишет: «Claude Code до v2.1.222 выдавал это уведомление и в случаях, когда соединение обрывалось или зависало уже после завершения ответа, и сообщал об ошибке хода при полном ответе». То есть на старых сборках вывод доходил целиком, а сообщение об ошибке всё равно появлялось. Если claude --version меньше 2.1.222, обновитесь до того, как начнёте локализовать причину: видимой ошибки может не существовать.

4. Почему запрос не повторяется автоматически

Claude Code вовсе не бездействует. По разделу «Automatic retries» официального справочника, временные сбои автоматически повторяются с экспоненциальной задержкой, до десяти раз. Раз сообщение всё-таки появилось, значит Claude Code решил, что здесь повторять нельзя.

Развилка проходит ровно по одному признаку — «успел ли Claude что-нибудь завершить».

Повтор выполняется
Обрыв до того, как что-либо завершено

Если соединение упало, пока Claude не завершил ни одной части ответа, включая размышление, Claude Code отправляет запрос заново с той же задержкой, и ход продолжается. Так же и в случае, когда текст уже начал идти.

Если размышление закончилось, но ни текст, ни вызов инструмента ещё не начались, повтор идёт максимум два раза с коротким интервалом, а при дальнейших падениях ход завершается сообщением Connection lost before a response was produced.

Повтор не выполняется ← эта статья
Обрыв после завершения блока

Если обрыв случился после того, как завершён блок текста или вызов инструмента (либо после размышления что-то уже началось), Claude Code не отправляет запрос заново. Потому что тот же вызов инструмента мог бы выполниться дважды.

Вместо этого он сохраняет завершённую часть, выполняет завершённые вызовы инструментов и продолжает ход с их результатов. И добавляет ту самую пометку.

Такая конструкция выглядит неудобной, но на деле выбрана в пользу безопасности. При автоматической переотправке операции с побочными эффектами — «переписал файл», «выполнил команду» — рисковали бы выполняться дважды при каждом обрыве. Поэтому документация предлагает не переотправку, а continue: это единственный способ не заставлять модель переделывать уже сделанное.

Что видно на экране во время повторов

Пока идут повторы, рядом со спиннером показывается обратный отсчёт Retrying in Ns · attempt x/y. Сначала подпись — API error, но начиная с v2.1.198 с третьей попытки она сменяется конкретной причиной (если CLAUDE_CODE_MAX_RETRIES меньше трёх, смена происходит на последней попытке).

Кроме того, если запрос жив, но данные не приходят двадцать секунд, ещё до фактического сбоя появляется баннер Waiting for API response · will retry in … · check your network. Это индикация «сбоя ещё не было», а обратный отсчёт ведётся до момента, когда Claude Code сам оборвёт застрявшее соединение. По документации, до v2.1.185 порог составлял десять секунд и текст был другим.

5. Где именно рвётся — три слоя

От одной фразы «соединение потеряно» план действий не появляется. Мест, где может рваться, по большому счёту три, и проверяются они по-разному.

Слой 1
Ваша машина и канал

Переключение Wi-Fi, микроразрывы мобильного канала, сон, переподключение VPN-клиента.

Как проверить: воспроизводится ли на проводе или на другом канале. Если причина в сне, появляется отдельная формулировка, и это уже разделяет случаи.

Слой 2
Маршрут (прокси и шлюзы)

Корпоративный прокси, инспекция TLS, LLM-шлюз, VPN. Оборудование, которое считает долго открытый поток простаивающим и рвёт его, встречается нередко.

Как проверить: воспроизводится ли без HTTPS_PROXY. Строку прокси видно в /status.

Слой 3
Сторона сервиса и переиспользование соединений

Сбой на стороне сервиса либо случай, когда переиспользуемое соединение на самом деле уже мертво. Характерный признак — канал исправен, а падения продолжаются.

Как проверить: посмотреть status.claude.com. Если одинаково воспроизводится на нескольких каналах, дело не только в вашей стороне.

Легко упускаемая четвёртая возможность — ротация сертификатов mTLS. Если в корпоративной среде используются клиентские сертификаты, замена сертификата и ключа вызывает ошибки уровня соединения (сброс соединения, провал TLS-рукопожатия). По официальной документации по настройке сети, Claude Code при таких ошибках перечитывает оба файла и повторяет запрос с новой парой. Но это поведение появилось в v2.1.232: до неё старая пара удерживалась до перезапуска или повторного применения настроек. Проверить можно по строке Stale connection — reloaded rotated mTLS client material в логе claude --debug.

6. Что попробовать сейчас — чек-лист локализации

Пункты идут сверху вниз от большего эффекта при меньших усилиях. После каждого шага проверяйте, воспроизводится ли проблема.

# Что сделать Зачем
1Ответить continueСначала не зафиксировать потерю. Быстрее, чем повторять задание, и без риска двойного выполнения
2Обновить Claude Code до последней версииПоведение вокруг соединений меняется от версии к версии. В v2.1.198 исправлена проблема «короткий сетевой разрыв посреди ответа прерывал ход»
3Разбить один ход на короткие«Прочитать кучу файлов и написать отчёт» делится на чтение и написание. Сокращается само время, пока поток открыт
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-прокси не поддерживаются. Если он есть, выберите другой маршрут
«В браузере Claude работает нормально» — не аргумент. Чат на claude.ai и CLI Claude Code по-разному устанавливают соединение и по-разному долго держат его открытым. Вполне возможно, что одно работает, а падает только другое (именно эту ситуацию описывает issue #85979, о котором ниже). Не спешите заключать, что «с аккаунтом всё в порядке, значит дело в настройках».

7. Настройка таймеров и повторов переменными окружения

Чтобы обрывать замолчавший поток, Claude Code держит четыре независимых таймера. Официальная документация по настройке сети перечисляет их так.

Таймер Условие обрыва Таймаут по умолчанию
First-byte deadline После отправки не пришёл ни один заголовок ответа 180 с для прямого API, иначе 300 с (плюс 1 с на каждые 32 КБ тела запроса)
Event-level watchdog Не удалось разобрать ни одного события ответа 300 с (работает у всех провайдеров)
Byte-level watchdog Не приходит ни байта, включая keep-alive-пинги SSE 180 с для прямого API, иначе 300 с
Body idle timeout Байты не приходят пять минут 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 Таймаут одного запроса (в миллисекундах, то есть 10 минут). На медленных каналах и через прокси его повышают
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS не задана Таймаут только байтового наблюдателя. Ограничивается диапазоном от 10 секунд до 30 минут
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS не задана Прямо задаёт срок ожидания первого байта. Доступна с v2.1.242
⚠️ Увеличение числа повторов не уменьшит это сообщение. Как показано в главе 4, это пометка для ситуации, где Claude Code намеренно избегает повтора. Повышение CLAUDE_CODE_MAX_RETRIES помогает против сбоев вида «падает до появления вывода», а на обрыв посреди ответа не влияет. Помогает другое — укорачивать один ход.

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 Claude Code обнаружил, что компьютер ушёл в сон во время ответа пересмотреть питание и сон (глава 6 этой статьи)
Connection lost before a response was produced Обрыв, не выдав ни символа (частичного вывода нет) случай с повтором. Глава 4 этой статьи
Unable to connect и ошибки SSL-сертификата Соединение вообще не устанавливается статью про сеть и прокси
в тексте появляются теги court и invoke Дело не в связи, а в том, что вызов инструмента не выполняется статью про тег court

Самая крупная развилка — «появился ли ответ на экране». Если не вышло ни символа, очередь подозревать само подключение и настройки: прокси, сертификаты, файрвол. Если часть вывода есть, это доказательство того, что соединение работало, и правильнее не менять настройки, а идти по разбору из этой статьи.

Вторая развилка — «обрыв или тишина»

Потеряно ли соединение или оно осталось открытым и замолчало — следующий шаг в этих случаях прямо противоположный.

Если обрыв (lost)

Подозревайте маршрут и переиспользование соединений. Увеличивать значения таймаутов бессмысленно — время не истекало, исчезло само соединение.

Если тишина (stopped arriving)

Вот здесь работают таймеры. Есть смысл править CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS и подобные, а также подозревать долгое молчание на стороне модели.

9. Реальные отчёты — когда ECONNRESET не прекращается

Самый неприятный сценарий — канал полностью исправен, а падает только Claude Code. В публичных issue есть два отчёта с очень основательной проверкой. Оба поданы либо уже под новым названием, либо содержат формулировку версии, вышедшей прямо перед ним.

Issue #86473 (v2.1.229, Windows 11)
Обычный HTTPS проходит, рвётся только CLI

Автор пишет, что после Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 появляется API Error: Connection lost mid-response. При этом POST на 60 КБ через curl и такой же по размеру POST через голый https.request в Node.js проходят полностью, а долгий SSE с другого хоста не прерывается.

Проверены MTU, Winsock LSP, воспроизведение на минимальной конфигурации и на двух не связанных между собой сетях — и всё равно не решено. Issue #86473 помечен как дубликат, но остаётся открытым.

Issue #85979 (v2.1.228, Windows 11)
На той же машине браузерная версия работает

Здесь Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. Автор полностью удалил антивирус, разобрался с VPN-фильтром, прокси и IPv6, сбросил Winsock — и всё равно одинаково воспроизвёл проблему в трёх сетях: офисный Wi-Fi, домашний Wi-Fi и раздача с телефона.

Приведено сопоставление: на той же машине и под тем же аккаунтом чат на claude.ai работает без сбоев. Issue #85979 тоже открыт (в статусе stale).

🟡 О достоверности этой главы. Оба отчёта выше — сообщения отдельных пользователей, а не официальное объяснение причин от Anthropic. В #85979 автор пишет, что поддержка сказала ему, будто «баг с переиспользованием старых соединений должен быть исправлен начиная с v2.1.227», но после обновления проблема повторилась — это пересказ переписки с поддержкой самим автором, а не опубликованная официальная позиция. Точно так же два интервала сбоя, упомянутые в #86473, — то, что, по словам автора, ему сообщила поддержка. Не читайте это как явление с установленными условиями воспроизведения.

И всё же из этих двух отчётов есть практический вывод: «ping проходит» и «curl проходит» не доказывают, что этой ошибки не будет. Обмен, при котором одно соединение держится открытым несколько минут в режиме стриминга, находится в других условиях, чем короткий запрос. Вместо того чтобы вкладывать время в диагностику своей сети, проще снизить частоту повторения, разбивая ход на короткие части.

10. Что подтверждено, а что нет

Чтобы не создавать ложных ожиданий, разделим то, что подтверждается официально, и всё остальное.

✅ Подтверждается официально
  • Формулировка описана в официальном справочнике ошибок, и её смысл — «соединение потеряно»
  • До v2.1.227 отображалось Connection closed mid-response (переименование того же самого)
  • Успевший пройти вывод сохраняется намеренно (переотправка грозит двойным выполнением)
  • Процедура восстановления — ответить continue
  • Обрыв до появления вывода повторяется автоматически (до десяти раз, экспоненциальная задержка)
  • Неинтерактивные сессии и субагенты продолжают сами (с v2.1.246 и v2.1.257 соответственно)
🟡 Есть отчёты, но не подтверждено
  • Обычный HTTPS исправен, а по ECONNRESET падает только CLI (отчёты #86473 и #85979)
  • Сопоставление «на той же машине и под тем же аккаунтом браузерная версия работает» (отчёт #85979)
  • Возможная причастность бага с переиспользованием соединений (пересказ ответа поддержки автором)
  • Упоминание о сбое на стороне сервиса в конкретные даты (тоже со слов автора)
🔴 Не опубликовано на момент написания
  • Официальное объяснение причины от Anthropic (публичных ответов в этих двух issue нет)
  • Причина переименования. В CHANGELOG упоминания о смене формулировки не найдено
  • #86473 и #85979 оба остаются открытыми

Коротко: симптом, смысл и процедура восстановления задокументированы официально, а официального объяснения, почему рвётся, пока нет. В такой ситуации надёжно работает не поиск причины, а приёмы, минимизирующие потери при обрыве: разбивать ход на короткие части, вести операции с побочными эффектами, сверяясь с фактическим состоянием, и держать версию свежей. Эти три пункта работают независимо от того, в чём причина.

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) работает против сбоев вида «падает до появления вывода». Помогает другое — укорачивать один ход.

Q5. То же самое с -p и в CI (неинтерактивный запуск)?

Поведение отличается. По официальному справочнику, в неинтерактивных сессиях Claude Code сам просит продолжить, если оборванный ответ состоял только из текста и не содержал вызовов инструментов, — до трёх раз подряд. Пометка появляется, когда эти продолжения исчерпаны. До v2.1.246 ход завершался на первом же обрыве. При использовании --output-format json это сообщение попадает в поле result.

Q6. Оно появляется и в субагентах (Task).

Субагенты тоже продолжают автоматически. Если оборванный ответ состоял только из текста, Claude Code просит субагента продолжить, и лишь исчерпав продолжения, оставляет эту пометку последним сообщением. До v2.1.257 пометка появлялась на первом же обрыве.

Q7. Может, дело в моей сети?

Такое возможно, но не обязательно только в ней. Автор issue #86473 показал, что POST одинакового размера через curl и через голый Node.js проходят полностью, и при этом падает только 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 исправлена «проблема, из-за которой короткий сетевой разрыв посреди ответа прерывал ход». Обновление — первый шаг с высокой отдачей, но не гарантия полного излечения: оба упомянутых выше issue поданы на более поздних сборках.

Q10. Проблема часто повторяется в корпоративной сети. Какие настройки смотреть?

Главное собрано в официальной документации по настройке сети. Пунктов три: ① SOCKS-прокси не поддерживаются, поэтому их не использовать; ② переменные прокси задавать не через export в шелле, а в блоке env файла ~/.claude/settings.json (фоновым агентам окружение шелла не достаётся); ③ при использовании mTLS следить за ротацией сертификатов. Прочитались ли настройки, видно в логе claude --debug или в выводе /status.

Похожие статьи

Первоисточники