Você está no meio do trabalho e, de repente, o Claude Desktop congela e todas as sessões abertas do Claude Code morrem de uma vez. Você força o encerramento, tenta abrir de novo e às vezes descobre que o aplicativo simplesmente não inicia mais — e, nessa hora, a última linha do log quase sempre é a mesma.
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Este artigo explica o que significa esse exitCode 101457950 (ou seja, 0x060C201E), por que sessões que não têm nada a ver com o problema caem junto, e o que dá e o que não dá para fazer na prática.
⚠️ Rótulos de confiança usados neste artigo: ✅ Confirmado = registrado em uma issue pública ou medido na máquina do autor / 🟡 Relatado = há vários relatos, mas nenhuma confirmação oficial / 🔴 Não confirmado = não dá para afirmar. A Anthropic não publicou nenhuma explicação oficial de causa nem anúncio de correção para esse sintoma (até onde foi possível verificar em 15 de agosto de 2026).
Uma única aba derruba todas as sessões
— porque o processo de GPU é um recurso compartilhado, e só existe um por aplicativo
1. A conclusão — não é uma falha do Claude Code, é uma falha do recipiente
Vale começar separando as coisas. Mesmo que pareça que "o Claude Code caiu", não é o Claude Code (a CLI) que está caindo. Quem cai é o processo de GPU do aplicativo desktop (Electron) que hospeda a CLI.
✅ Confirmado: o diagnóstico é simples, basta olhar o fim de %APPDATA%\Claude\logs\main.log. Se a linha imediatamente anterior ao reinício for GPU process gone, é este problema. O log é interrompido ali, e a linha seguinte já é Starting app.
E o ponto importante é que o que se perde é o processo, não os dados. O histórico de conversas e as transcrições são gravados em disco, então basta reabrir a sessão depois de reiniciar para continuar lendo de onde parou. O trabalho que estava em execução é outra história, e voltamos a isso na §6.
2. O sintoma — ele não "cai", ele "trava"
A parte mais incômoda desse defeito é que o aplicativo não desaparece: ele fica ali, sem responder. Não aparece caixa de diálogo de erro, e ele não reinicia sozinho. Ele simplesmente fica congelado até você perceber e forçar o encerramento.
Na máquina do autor (Windows 11 / RTX 2080 Ti / 32GB de RAM), nas três ocorrências observadas em 14 de agosto de 2026, o intervalo mais longo entre a morte do processo de GPU e o encerramento forçado foi de cerca de 30 minutos. Durante todo esse tempo, as 8 sessões abertas permaneceram paradas.
Três formas de identificar
- Não é uma sessão, são todas — se apenas uma sessão parou, a causa é outra. Se várias sessões reiniciaram dentro do mesmo minuto, quem caiu foi o aplicativo
- O log é cortado no meio — em um encerramento normal, seguem-se as linhas do processo de saída. Aqui, a própria escrita para logo depois de
GPU process gone - Não há dumps — se nenhum dump novo apareceu em
%APPDATA%\Claude\Crashpad\, não foi uma falha nativa do lado da CLI
3. Por que sessões sem relação nenhuma caem junto
É aqui que está a essência do defeito — e também o motivo de não ser algo que se resolve mexendo em configurações.
O Electron (Chromium) concentra o trabalho de renderização em um processo dedicado, o processo de GPU. E esse processo existe uma única vez por aplicativo. Todas as janelas, todas as abas e todas as sessões o compartilham.
Ou seja: se uma única página aberta no navegador interno matar o processo de GPU, sessões que não têm o menor parentesco com aquela página caem no mesmo instante. Não há isolamento por aba nem por sessão. ✅ Confirmado: isso é assim por projeto no modelo de processos do Chromium, e não existe configuração do lado do usuário que permita separá-los.
Um único processo de GPU, compartilhado por tudo
4. O gatilho — o navegador interno é o mais comum, mas não é o único
✅ Confirmado: nas issues públicas, o gatilho mais frequente é o navegador interno (o painel de navegador). A #80444 registra o processo de GPU morrendo de 15 a 36 segundos depois que uma página aberta em uma aba do navegador executou a detecção de recursos de WebGL/WebGPU — nas quatro vezes com o mesmo 0x060C201E.
A #82967 é ainda mais específica e aponta o gatilho para a captura de screenshot de pré-visualização da ferramenta de navegador (capturePreviewScreenshotIfChanged). A #83478 relata reprodução ao "deixar aberta uma pré-visualização que se atualiza continuamente".
🟡 Relatado: dito isso, o navegador não é o único gatilho. A #68049 relata a mesma falha, com o mesmo exitCode, acontecendo na inicialização em um ambiente ARM64, sem nenhuma interação com o navegador. A #83028 diz que reproduz em uma GPU integrada Intel. Não dá para dizer que "sem usar o navegador nunca acontece".
💡 Medição na máquina do autor (não generalizável): durante pesquisas sobre ferramentas de IA, a operação de abrir 4 páginas em sequência no navegador interno, com 1 a 2 segundos de intervalo, foi repetida cerca de 18 vezes no mesmo dia, e em 3 delas o processo de GPU morreu. Não cai sempre: só cai quando a combinação de páginas pesadas se encaixa. Como se trata da observação de uma única máquina, a frequência em si não pode ser transposta para outros ambientes.
5. Confirmando pelo log
Em vez de ficar no palpite, três arquivos bastam para confirmar. E atenção: o diretório ~/.claude/logs não existe.
| O que olhar | Caminho | Como interpretar |
|---|---|---|
| O aplicativo em si | %APPDATA%\Claude\logs\main.log | Se a linha imediatamente anterior ao reinício for GPU process gone, é este problema |
| A janela do navegador | %APPDATA%\Claude\logs\unknown-window.log | Um CONTEXT_LOST_WEBGL no mesmo horário mostra que, também do lado da renderização, a GPU caiu |
| Falha nativa | %APPDATA%\Claude\Crashpad\ | Se nenhum dump novo apareceu, a falha não é do lado da CLI |
⚠️ O aviso sobre requestAdapter que aparece no mesmo log não é o culpado. A linha "The powerPreference option is currently ignored when calling requestAdapter() on Windows." não é sinal de falha: é uma mensagem normal do Chromium avisando que powerPreference não tem efeito no Windows (Chrome for Developers / Chromium issue 40268366). Ela aparece sempre que uma página usa WebGPU, mesmo sem nenhuma falha. Não use a presença dela como evidência.
O exitCode distingue a falha de um encerramento normal. Todos são "encerramentos", mas com significados diferentes, e vale perseguir apenas o que importa.
| exitCode | Hexadecimal | Significado |
|---|---|---|
101457950 | 0x060C201E | A assinatura deste problema. É o que investigar |
-1073741205 | 0xC000026B | Logoff ou desligamento do sistema. Normal |
1073807364 | 0x40010004 | Encerramento intencional. Normal |
6. Recuperação — quando o Reparar resolve e quando não resolve
Forçar o encerramento e reabrir costuma bastar. O problema é o caso em que você tenta reabrir e o aplicativo não inicia mais.
✅ Confirmado: depois de uma falha de GPU, o Windows pode julgar que o pacote MSIX foi "modificado" e recusar a inicialização. A #80444 registra isso como appxState=2 (Modified) e relata que Configurações → Aplicativos → Claude → Opções avançadas → Reparar recuperou o aplicativo todas as vezes. A #81836 diz o mesmo: o Reparar traz o aplicativo de volta.
Daqui em diante vem a parte mais prática do artigo. Também existem relatos em que o Reparar não funciona. Na #82967, o estado do pacote avançou até Modified, NeedsRemediation, e o autor relata que o Reparar falhava sempre, e só a remoção completa seguida de reinstalação resolveu.
A ordem quando ele não inicia mais
- Encerre os processos residentes — enquanto eles seguram os arquivos, o Reparar é recusado com a alegação de que o aplicativo está em execução
- Reparar — Configurações → Aplicativos → Aplicativos instalados → Claude → Opções avançadas. Os dados são preservados
- Se nem isso resolver, desinstale e reinstale (será preciso entrar na conta de novo)
O passo a passo detalhado, e a resposta sobre se o histórico de conversas ou as sessões são perdidos, estão reunidos em o procedimento de reparo para "Não é possível abrir este aplicativo".
Sobre os dados. As transcrições continuam em disco, então dá para relê-las depois de reiniciar. Ainda assim, a #81698 relata: "perdi por inteiro o trabalho que estava em execução, incluindo os resultados de todos os subagentes que rodavam em paralelo". O que já foi salvo permanece, mas o que estava em andamento não volta — vale manter essas duas coisas separadas na cabeça.
7. O que dá para fazer e o que não dá
Infelizmente, não existe solução definitiva. O que dá para fazer é tornar o gatilho menos provável — e, como no meio disso circulam também "soluções" que os relatos dizem não funcionar, vale separar os dois lados.
- Não abrir páginas pesadas no navegador interno. Passe-as para o navegador de verdade
- Não abrir várias páginas de uma vez. Deixe um intervalo entre elas
- Não deixar uma pré-visualização aberta indefinidamente (a condição de reprodução da #83478)
- Desativar o recurso de navegador — a solução alternativa apontada pela #82967. Mas isso só interrompe a parcela causada pelo navegador, e não tem efeito sobre a variante que cai na inicialização (#68049)
- Não acumular trabalhos longos em uma única sessão. A releitura na recuperação fica mais leve
--disable-gpunão é utilizável — na versão MSIX ele é recusado com "acesso negado" (#82967)- Atualizar o aplicativo não corrige — na máquina do autor, o problema voltou na versão já atualizada
- Isolar o processo de GPU — impossível por arquitetura (§3)
- Mexer no agendamento de GPU ou nas configurações do driver — a #82967 relata ter tentado várias e nenhuma surtiu efeito
🟡 Relatado: se você usa uma GPU híbrida (uma configuração que alterna entre a integrada e a dedicada), pode valer a pena tentar fixar a preferência de GPU do Claude em Configurações → Sistema → Vídeo → Gráficos, no Windows. A justificativa vem do lado do Chromium: no Windows, a escolha de GPU via powerPreference não tem efeito — porque o Chrome ainda não consegue compor usando duas GPUs de forma seletiva, e isso é acompanhado como a Chromium issue 40268366. Ou seja, o aplicativo não tem como fixar em qual GPU vai renderizar, e quem quiser fixar precisa recorrer à configuração do sistema operacional. Dito isso, não foi encontrado nenhum relato de que isso tenha funcionado para este problema, então não crie muitas expectativas.
8. Um fenômeno diferente que se confunde com este — o encerramento forçado por atualização da loja
Na versão da Microsoft Store (MSIX), a atualização automática do próprio aplicativo está desativada. Em vez dela, é a loja que encerra à força o aplicativo em execução para substituí-lo. Como o aplicativo some de repente no meio do trabalho, é fácil confundir isso com a falha de GPU.
O log distingue os dois com clareza. Em uma atualização da loja, fica registrada a linha Windows session ending (close-app), e GPU process gone não aparece. Se a versão tiver mudado na próxima inicialização, está confirmado.
Esse caso não tem como ser evitado, então a única mitigação é deixar as atualizações em dia antes de entrar em um trabalho longo.
Resumo
- O que é de fato: não é uma falha do Claude Code, e sim uma falha do processo de GPU do aplicativo desktop (
exitCode 101457950/0x060C201E) - Por que tudo cai junto: o processo de GPU é um recurso compartilhado, e só existe um por aplicativo. Uma única aba derruba todas as sessões. Nenhuma configuração isola isso
- Gatilho: o navegador interno é o mais comum. Mas há relatos de falha na inicialização, então não é o único
- Como confirmar: olhe a linha imediatamente anterior ao reinício em
main.log. Se forGPU process gone, é este problema - Recuperação: forçar o encerramento → reabrir. Se ele não abrir mais, Reparar. Há relatos que avançam até o ponto em que o Reparar não funciona
- Dados: o que já foi salvo permanece, mas o trabalho em execução não volta
- Não há nenhum anúncio oficial de correção (até 15 de agosto de 2026)
FAQ
P. O histórico de conversas é apagado?
R. Não. As transcrições são gravadas em disco, então basta reabrir depois de reiniciar para lê-las. Porém, o trabalho que estava rodando no instante da falha é perdido — há relato de perda até dos resultados de subagentes que rodavam em paralelo (#81698).
P. Atualizar o aplicativo resolve?
R. Não necessariamente. Na máquina do autor, o problema voltou com a mesma assinatura na versão já atualizada. Ainda assim, a #80444 relata o caso como uma regressão a partir de uma versão específica, então é possível que a frequência varie conforme a versão.
P. Atualizar o driver da GPU resolve?
R. É uma aposta fraca. Se a causa estivesse na camada do driver, o log de sistema do Windows registraria um TDR (evento de ID 4101) — e, na máquina do autor, não houve um único em 30 dias. A #68049 também relata reincidência mesmo depois de atualizar o driver e reinstalar do zero.
P. Não seria falta de memória ou uma transcrição gigante?
R. Na máquina do autor, as duas hipóteses foram descartadas. No momento da falha, o total de todos os processos do Electron era de cerca de 1,7GB, e havia 14,8GB livres de 31,9GB. Também havia sessões com transcrições que chegaram a 98,5MB, mas sem correlação com os horários das quedas.
P. É o mesmo problema quando apenas uma sessão para?
R. Não. Como aqui é o próprio aplicativo que congela, este problema sempre derruba tudo. Se foi só uma, suspeite de outra causa. Se a resposta apenas é cortada no meio, o caso é da família de Connection closed mid-response ou de response stalled mid-stream.
Artigos relacionados
- Claude Desktop "Não é possível abrir este aplicativo" — o procedimento de reparo (o que fazer depois desta falha)
- "Há um outro programa usando este arquivo no momento" (0x80070020) (outro problema, quando ele não abre depois de uma atualização)
- Panorama geral dos erros do Claude Code
