Во время работы Claude Desktop внезапно зависает, и все открытые сессии Claude Code умирают разом. Вы снимаете приложение принудительно, пытаетесь запустить снова — и иногда оно уже не открывается. В такие моменты в последней строке лога почти всегда стоит одна и та же фраза.
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Эта статья разбирает, что означает тот самый exitCode 101457950 (он же 0x060C201E), почему вместе с ним встают совершенно посторонние сессии, и что здесь реально можно сделать, а чего сделать нельзя.
⚠️ Метки достоверности в этой статье: ✅ Подтверждено — задокументировано в открытых issue либо измерено на машине автора / 🟡 По сообщениям — сообщений несколько, официального подтверждения нет / 🔴 Не подтверждено — утверждать как факт нельзя. Anthropic не публиковала по этому симптому ни официального объяснения причины, ни сообщения об исправлении (в пределах проверенного на 15 августа 2026 года).
Одна вкладка утягивает за собой все сессии
— потому что процесс GPU в приложении один и общий для всех
1. Короткий ответ — сломался не Claude Code, а оболочка вокруг него
Начнём с разделения. Даже если ощущение такое, что «упал Claude Code», падает не Claude Code (CLI). Падает процесс GPU той десктопной оболочки (Electron), внутри которой он работает.
✅ Подтверждено: проверить это просто — достаточно заглянуть в конец %APPDATA%\Claude\logs\main.log. Если строка непосредственно перед перезапуском — GPU process gone, это наш случай. Лог на ней обрывается, а следующая строка — уже Starting app.
И вот что важно: теряется процесс, а не данные. История переписки и транскрипты записаны на диск, так что после перезапуска сессию можно открыть заново и читать дальше. А вот с работой, которая выполнялась в этот момент, дело обстоит иначе — к ней вернёмся в §6.
2. Симптом — не «падает», а «зависает»
Самое неприятное в этой поломке — приложение не исчезает, а остаётся на экране и не отвечает. Ни окна об аварийном завершении, ни автоматического перезапуска. Оно просто висит, пока пользователь не заметит и не снимет его принудительно.
На машине автора (Windows 11 / RTX 2080 Ti / 32 ГБ ОЗУ) 14 августа 2026 года это наблюдалось трижды, и самый долгий промежуток от смерти процесса GPU до принудительного завершения составил около 30 минут. Всё это время восемь открытых сессий стояли.
Три признака, по которым это опознаётся
- Встаёт не одна сессия, а все — если остановилась ровно одна, причина другая. Если несколько сессий перезапустились в одну и ту же минуту, упало само приложение
- Лог обрывается на полуслове — при нормальном завершении дальше идут строки процедуры выхода. Здесь сразу после
GPU process goneпрекращается сама запись - Дампов нет — если в
%APPDATA%\Claude\Crashpad\не прибавилось дампов, это не нативное падение на стороне CLI
3. Почему вместе с ним встают посторонние сессии
Здесь суть этой поломки — и одновременно причина, по которой настройками её обойти не получится.
Electron (Chromium) сводит всю отрисовку в отдельный процесс GPU. И этот процесс существует в единственном экземпляре на приложение. Все окна, все вкладки, все сессии пользуются им сообща.
То есть если одна-единственная страница, открытая во встроенном браузере, убивает процесс GPU, вместе с ней встают сессии, не имеющие к этой странице никакого отношения. Разделения по вкладкам и по сессиям здесь нет. ✅ Подтверждено: так по замыслу устроена модель процессов Chromium, и развести их настройками на стороне пользователя невозможно.
Один процесс GPU — общий для всего сразу
4. Спусковой крючок — чаще всего встроенный браузер, но не только он
✅ Подтверждено: самый частый спусковой крючок в опубликованных issue — встроенный браузер (панель браузера). В #80444 записано, как процесс GPU умирает через 15–36 секунд после того, как открытая во вкладке страница запускает определение возможностей WebGL/WebGPU, — и все четыре раза с одним и тем же 0x060C201E.
#82967 ещё конкретнее: там спусковой крючок сведён к снятию скриншота для предпросмотра браузерным инструментом (capturePreviewScreenshotIfChanged). В #83478 сообщают о воспроизведении при «постоянно обновляющемся предпросмотре, оставленном открытым».
🟡 По сообщениям: но браузер — не единственный спусковой крючок. В #68049 сообщают о падении с тем же exitCode прямо при запуске в среде ARM64, без каких-либо действий в браузере. В #83028 пишут о воспроизведении на встроенной графике Intel. Сказать «если не пользоваться браузером, этого точно не случится» нельзя.
💡 Замеры на машине автора (обобщать их нельзя): изучая ИИ-инструменты, автор за один день около 18 раз проделал одно и то же — открывал во встроенном браузере подряд четыре страницы с интервалом 1–2 секунды, и в трёх случаях из этих раз процесс GPU умирал. Падает не каждый раз, а только когда совпадает неудачное сочетание тяжёлых страниц. Это наблюдения на одной машине, поэтому саму частоту переносить на другие конфигурации нельзя.
5. Как убедиться по логам
Гадать не нужно: достаточно посмотреть три файла. И учтите, что каталога ~/.claude/logs не существует.
| Что смотреть | Путь | Как читать |
|---|---|---|
| Само приложение | %APPDATA%\Claude\logs\main.log | Если строка прямо перед перезапуском — GPU process gone, это наш случай |
| Окно браузера | %APPDATA%\Claude\logs\unknown-window.log | Если в то же время есть CONTEXT_LOST_WEBGL, значит и со стороны отрисовки GPU действительно отвалился |
| Нативное падение | %APPDATA%\Claude\Crashpad\ | Если дампов не прибавилось, дело не в стороне CLI |
⚠️ Предупреждение про requestAdapter в том же логе — не виновник. Строка «The powerPreference option is currently ignored when calling requestAdapter() on Windows.» не является признаком аварии: это обычное сообщение Chromium о том, что в Windows powerPreference не действует (Chrome for Developers / Chromium issue 40268366). Она появляется на любой странице, использующей WebGPU, даже когда ничего не падает. Само её присутствие ничего не доказывает.
Нормальное завершение отличается от аварийного по exitCode. «Завершение» бывает разным по смыслу, а гоняться стоит только за нужным.
| exitCode | Шестнадцатеричный | Что это значит |
|---|---|---|
101457950 | 0x060C201E | Сигнатура нашего случая. За ней и следим |
-1073741205 | 0xC000026B | Выход из системы или завершение её работы. Норма |
1073807364 | 0x40010004 | Намеренное завершение. Норма |
6. Восстановление — когда «Восстановить» возвращает приложение, а когда нет
Обычно достаточно снять приложение принудительно и запустить заново. Проблема начинается тогда, когда вы пытаетесь его запустить, а оно уже не открывается.
✅ Подтверждено: после аварии GPU Windows иногда считает пакет MSIX «изменённым» и отказывается его запускать. В #80444 это записано как appxState=2 (Modified), и там же сообщают, что каждый раз выручало восстановление: Параметры → Приложения → Claude → Дополнительные параметры → «Восстановить». В #81836 тоже пишут, что «Восстановить» возвращает приложение.
Дальше идёт, пожалуй, самая практичная часть статьи. Есть и сообщения о том, что «Восстановить» не помогает. В #82967 состояние пакета дошло до Modified, NeedsRemediation, и автор сообщает, что восстановление отказывало всегда, а вернуть приложение удалось только полным удалением и установкой заново.
Порядок действий, если приложение перестало запускаться
- Завершите фоновые процессы — пока они держат файлы, восстановление отклоняют с сообщением о том, что приложение запущено
- «Восстановить» — Параметры → Приложения → Установленные приложения → Claude → Дополнительные параметры. Данные при этом сохраняются
- Если и это не помогло — удалить и установить заново (придётся войти в аккаунт ещё раз)
Подробности процедуры и ответ на вопрос, пропадут ли история переписок и сессии, собраны в статье о починке через «Восстановить», когда приложение не удаётся открыть.
Про данные. Транскрипты остаются на диске, так что после перезапуска их можно перечитать. Но в #81698 сообщают: «вся работа, которая шла в этот момент, потеряна целиком; результаты параллельно запущенных субагентов тоже исчезли». Сохранённое остаётся, а выполняющееся не возвращается — эти две вещи стоит держать раздельно.
7. Что можно сделать и чего сделать нельзя
К сожалению, полноценного обходного пути нет. Можно лишь реже нажимать на спусковой крючок, — а среди ходящих по сети советов попадаются и такие, о которых сообщают, что они не работают, поэтому разделим их.
- Не открывать тяжёлые страницы во встроенном браузере. Уводить их в обычный браузер
- Не открывать много страниц сразу. Делать паузы между ними
- Не оставлять предпросмотр открытым (условие воспроизведения из #83478)
- Отключить сам браузерный инструмент — обходной путь, который называют в #82967. Но так прекращается только то, что вызвано браузером, и на падения при запуске (#68049) это не действует
- Не копить длинную работу в одной сессии. После восстановления перечитывать придётся меньше
--disable-gpuиспользовать не выйдет — в сборке MSIX флаг отклоняется с сообщением об отказе в доступе (#82967)- Обновление приложения не лечит — на машине автора всё повторилось и на обновлённой версии
- Изоляция процесса GPU — невозможна по устройству (§3)
- Правка планирования GPU и настроек драйвера — в #82967 сообщают, что перепробовали несколько вариантов без эффекта
🟡 По сообщениям: если у вас гибридная графика (конфигурация с переключением между встроенным и дискретным GPU), стоит попробовать жёстко закрепить за Claude нужный GPU: Параметры → Система → Дисплей → Графика в Windows. Основание лежит на стороне Chromium: в Windows выбор GPU через powerPreference не действует — Chrome пока не умеет задействовать два GPU одновременно и сводить их вывод, и это отслеживается как Chromium issue 40268366. То есть приложение не может само зафиксировать, на каком GPU рисовать, и остаётся полагаться только на настройку уровня ОС. Но сообщений о том, что это помогло именно в нашем случае, найти не удалось, так что рассчитывать на этот совет сильно не стоит.
8. Похожее, но другое — принудительное закрытие при обновлении из Store
В сборке из Microsoft Store (MSIX) собственное автообновление приложения отключено. Вместо него Store сам принудительно закрывает работающее приложение и подменяет его. Приложение исчезает прямо посреди работы, поэтому это легко спутать с аварией GPU.
По логу они различаются однозначно. При обновлении из Store остаётся строка Windows session ending (close-app), а GPU process gone не появляется. Если при следующем запуске сменилась версия — вопрос закрыт.
Избежать этого нельзя, поэтому единственное смягчение — ставить обновления до того, как садиться за длинную работу.
Итог
- Что это на самом деле: не поломка Claude Code, а падение процесса GPU десктопного приложения (
exitCode 101457950/0x060C201E) - Почему встают все: процесс GPU — общий ресурс, существующий в единственном экземпляре на приложение. Одна вкладка утягивает за собой все сессии. Настройками их не разделить
- Спусковой крючок: чаще всего встроенный браузер. Но есть и сообщения о падении при запуске, так что он не единственный
- Как убедиться: посмотреть в
main.logстроку прямо перед перезапуском.GPU process gone— это наш случай - Восстановление: снять принудительно → запустить заново. Если не запускается — «Восстановить». Есть сообщения и о состоянии, при котором «Восстановить» уже не помогает
- Данные: сохранённое остаётся, но работа, которая выполнялась в момент аварии, не возвращается
- Официального сообщения об исправлении нет (на 15 августа 2026 года)
Частые вопросы
В. Пропадёт ли история переписок?
О. Нет. Транскрипты записаны на диск, поэтому после перезапуска их можно открыть заново и прочитать. Но работа, которая выполнялась в момент аварии, теряется — есть сообщение о том, что вместе с ней исчезли и результаты параллельно запущенных субагентов (#81698).
В. Поможет ли обновление приложения?
О. Не обязательно. На машине автора та же сигнатура повторилась и на обновлённой версии. При этом в #80444 сообщают о регрессии, начавшейся с конкретной версии, так что вероятность столкнуться с этим от версии к версии может меняться.
В. Поможет ли обновление драйвера GPU?
О. Это слабое средство. Если бы причина была на уровне драйвера, в системном журнале Windows записывался бы TDR (событие с идентификатором 4101), но на машине автора за 30 дней не оказалось ни одной такой записи. В #68049 тоже сообщают, что проблема вернулась и после обновления драйвера, и после чистой переустановки.
В. Может, дело в нехватке памяти или в раздувшихся транскриптах?
О. На машине автора обе версии не подтвердились. В момент аварии все процессы Electron вместе занимали около 1,7 ГБ, а свободной памяти было 14,8 ГБ из 31,9 ГБ. Нашлась и сессия с транскриптом, выросшим до 98,5 МБ, но со временем падений это никак не коррелировало.
В. А если остановилась только одна сессия — это то же самое?
О. Нет. Здесь зависает само приложение, поэтому картина всегда «встало всё сразу». Если встала ровно одна, ищите другую причину. Когда ответ просто обрывается на полуслове, это уже Connection closed mid-response или response stalled mid-stream.
Похожие статьи
- Claude Desktop не открывается — чиним кнопкой «Восстановить» (что делать с последствиями)
- «Файл занят другой программой» (0x80070020) (другая проблема: не запускается после обновления)
- Обзор ошибок Claude Code
