Claude Desktop 0x80070020: não abre após atualizar

Q: Qual é a forma mais rápida de resolver?

Saia do Windows uma vez e entre de novo (Iniciar → ícone do seu usuário → "Sair"). Não é reiniciar o PC, e não é sair do aplicativo/conta do Claude. Conforme o #53247, o handle órfão por trás disso persiste por sessão de usuário do Windows, então um reinício completo do PC pode ser desnecessário. Se ainda assim não recuperar, reinicie o PC.

Q: Vi "basta parar o serviço" — isso funciona?

Para esse bug há relatos de que não funciona (#48003, #53247). O Stop-Service CoworkVMService reinicia e o erro volta a ocorrer, e nem o Reset-AppxPackage nem reiniciar os vários serviços resolveram. É mais racional tentar sair da sessão primeiro.

Q: Então, no fim das contas, qual é a causa?

O problema na camada de contêiner está confirmado, mas o gatilho tem duas explicações sem definição: (1) o CoworkVMService (início automático) segurando o Job Object (#57221), e (2) uma falha na inicialização que deixa a limpeza do Silo/Job por fazer, restando um handle órfão (#53247). Como parar o serviço não resolve, o que contradiz (1), não dá para afirmar com certeza por ora.

Q: Existe uma correção oficial?

No momento da investigação, nenhuma correção permanente oficial foi lançada. A issue central #53247 continua aberta (Open). Na issue, correções permanentes como mudar o serviço para início sob demanda (Manual) estão em fase de proposta.

Q: Acontece a cada atualização?

🔴 Não dá para afirmar com certeza. Na máquina havia a sensação de que "acontece a cada atualização", mas o log de eventos só o mostrou em 2 de 6 atualizações (registros mais antigos podem ter sido descartados pelo limite de tamanho do log, então fica indeterminado). A frequência pode variar de máquina para máquina.

Q: Como impedir que se repita?

Há um relato de que abandonar a versão MSIX (Store) e migrar para a versão Squirrel (instalador) resolveu tanto o problema de atualização quanto o de inicialização (#57221). Você desinstala completamente a versão da Store e depois instala a versão do instalador pelo site oficial ou via winget. Se você tiver restrições como uma política de distribuição corporativa, verifique antes.

Claude Desktop 0x80070020: não abre após atualizar

Conteúdo

1. Conclusão — saia do Windows primeiro para recuperar
2. Sintoma — aparece ao abrir depois de uma atualização
3. A solução — o que funciona e o que não funciona
4. O que o erro realmente é — não é um bloqueio de arquivo (confirmado)
5. Duas explicações concorrentes, ainda sem definição
6. Verifique na sua própria máquina (PowerShell)
7. Problemas diferentes fáceis de confundir
Resumo
FAQ

Logo depois de atualizar o Claude Desktop (Windows), ao tentar abrir o aplicativo surge uma caixa de diálogo com a mensagem "Há um outro programa usando este arquivo no momento" e o aplicativo não inicia — e ele continua quebrado até você reiniciar o PC. Esse é um bug conhecido, relatado na versão da Microsoft Store (MSIX) do Claude Desktop (GitHub #53247 e outros).

Vamos direto à conclusão. Um reinício completo do PC não é necessariamente preciso. Em muitos casos, apenas sair do Windows e entrar de novo já recupera (não é reiniciar o PC, nem sair da conta do Claude). Abaixo separamos o que funciona, o que não funciona e o que o erro realmente é, divididos em confirmado / inferido / não confirmado. Este artigo se baseia em registros de investigação de uma única máquina (Windows 11 Home, 10.0.26200) cruzados com issues conhecidas do GitHub.

⚠️ Rótulos de confiança neste artigo: ✅ Confirmado = verificado diretamente nos logs da máquina ou em uma issue / 🟡 Inferido = interpretação a partir de indícios circunstanciais / 🔴 Não confirmado = não foi determinado. Não afirmamos o que não conseguimos provar, como "a causa é um bloqueio de arquivo".

0x80070020 · APPMODEL-RUNTIME 215 / 208

Ordem de recuperação para tentar primeiro

① Sair do Windows → entrar de novo

Iniciar → ícone do seu usuário → "Sair". O mais rápido; um reinício completo do PC pode ser desnecessário (#53247)

② Reiniciar o PC

Confiável, mas pesado. Quando ① não resolve

③ Migrar para a versão Squirrel

Correção permanente que evita a recorrência (relator do #57221)

1. Conclusão — saia do Windows primeiro para recuperar

O prejuízo real desse bug é "não conseguir iniciar", mas recuperar não exige necessariamente um reinício completo do PC. Segundo a análise do #53247, o "handle órfão" por trás do problema persiste por sessão de usuário do Windows, então basta sair do Windows e entrar de novo para limpá-lo. A maioria das pessoas reinicia o PC inteiro por reflexo, então isso economiza esse tempo.

"Sair" é do Windows — não é reiniciar o PC nem sair da conta do Claude

O ato de sair aqui é sair da sua conta de usuário do Windows (Iniciar → ícone do seu usuário no canto inferior esquerdo → "Sair"). Os aplicativos abertos são fechados, mas o PC não desliga, e é mais rápido que reiniciar. Não é sair do aplicativo/conta do Claude, e não é reabrir o aplicativo — isso não resolve.

✅ Quer resolver agora: sair → entrar de novo. Há casos relatados em que isso permite abrir o aplicativo novamente (#53247).
✅ Quer resolver com certeza: reiniciar o PC. Pesado, mas confiável.
✅ Quer impedir a recorrência: abandonar a versão MSIX e migrar para a versão Squirrel (instalador) (veja abaixo; conforme o relator do #57221).

2. Sintoma — aparece ao abrir depois de uma atualização

A sequência típica: depois que uma atualização do Claude Desktop é aplicada, ao abrir o aplicativo surge uma caixa de diálogo no estilo do Explorador de Arquivos do Windows com "Há um outro programa usando este arquivo no momento", e ele não inicia. Fechar e reabrir dá no mesmo, e não recupera até reiniciar o PC (ou sair da sessão).

O ponto crucial: o texto dessa caixa de diálogo não reflete com precisão o que está acontecendo (detalhes na §4). Além disso, a própria atualização foi bem-sucedida — o que falha não é a atualização, mas "iniciar o aplicativo". Isso afeta a versão da Microsoft Store (MSIX) do Claude Desktop.

3. A solução — o que funciona e o que não funciona

Aqui está a maior armadilha. Pela internet você vai encontrar afirmações do tipo "parar o serviço resolve", mas para esse bug há relatos de que isso não funciona. Vamos separar com clareza o que funciona do que não funciona.

✅ Funciona (relatado)

Sair do Windows → entrar de novo (o mais rápido; um reinício do PC pode ser desnecessário)
Reiniciar o PC (confiável)
Migrar para a versão Squirrel (permanente; evita a recorrência)

🔴 Relatado como NÃO funciona (não recomendado)

Stop-Service CoworkVMService (reinicia e volta a ocorrer)
taskkill em todos os processos do Claude/Cowork
Reset-AppxPackage / Add-AppxPackage -Register
Reiniciar AppXSvc, ClipSVC, vmcompute etc.

Os itens da direita estão registrados como testados e falharam tanto no #48003 quanto no #53247. Eles tendem a desperdiçar tempo, então é racional tentar sair da sessão primeiro.

Correção permanente: migrar para a versão Squirrel (instalador)

Se enfrentar isso a cada atualização for insuportável, o relator do #57221 afirma que desinstalar a versão MSIX e migrar para a versão do instalador (Squirrel) resolveu tanto o problema da atualização quanto o de inicialização. O resumo dos passos:

Desinstale completamente a versão da Store (MSIX) do Claude Desktop.
Instale a versão do instalador pelo download oficial do Claude ou via winget (por exemplo, winget install Anthropic.Claude).
Depois disso, a atualização automática o mantém na versão mais recente.

🟡 A justificativa apresentada é que isso sai das restrições de C:\Program Files\WindowsApps e da camada de contêiner AppX. O comportamento pode variar conforme o ambiente, então verifique o seu caso de uso (política de distribuição corporativa etc.) antes de migrar.

4. O que o erro realmente é — não é um bloqueio de arquivo (confirmado)

A caixa de diálogo parece dizer "o arquivo está em uso", mas nos logs da máquina a falha está em outro lugar. O log de eventos Microsoft-Windows-AppModel-Runtime/Admin registra o seguinte (✅ confirmado na máquina):

Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
            Claude_..._x64__pzs8sxrjxfjjc
            because an error was encountered converting the job.

Event ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]

Elemento	Significado
`0x80070020`	ERROR_SHARING_VIOLATION. O código que o Windows genericamente exibe como "o processo não pode acessar o arquivo porque ele está sendo usado por outro processo". É isso que a caixa de diálogo realmente é.
`[LaunchProcess]`	Uma falha de inicialização, não uma falha de atualização (a atualização já foi bem-sucedida).
Onde falha	Ao criar o contêiner Desktop AppX — especificamente na etapa que converte o Job Object em um Silo.

E ✅ ficou verificado que "não existe bloqueio de arquivo". No #53247, a verificação com handle.exe e o Process Explorer mostrou nenhum bloqueio de arquivo no espaço do usuário. Portanto, "porque outro programa está segurando o arquivo" está errado, ao menos como um bloqueio no espaço do usuário. O que há de verdade é um problema na camada de contêiner (Job/Silo) do AppX/Desktop Bridge.

5. Duas explicações concorrentes, ainda sem definição

"Um problema na camada de contêiner" está confirmado, mas há duas visões sobre o gatilho, e a questão não está resolvida. Evitamos afirmar uma delas e apresentamos as duas.

Visão A: o serviço segura o Job Object (#57221)

O CoworkVMService incluído (conta SYSTEM, início automático) segura o Job Object do pacote e bloqueia a criação do contêiner do novo pacote. Na máquina, o erro ocorreu no mesmo segundo em que o serviço foi reinstalado, o que é consistente com essa visão (🟡 circunstancial).

Visão B: uma falha na inicialização pula a limpeza (#53247)

Se o processo do Claude trava na inicialização, a limpeza do Silo/Job no lado do kernel não é executada e um handle órfão permanece. As inicializações seguintes então falham ao converter o job do mesmo pacote. O fato de sair da sessão resolver é consistente com essa visão.

Note a tensão: se a Visão A (o serviço segurando) estivesse certa, "parar o serviço" deveria resolver — mas há relatos de que não resolve (§3). Por causa dessa contradição, qual das duas é a principal não está definido. 🔴 Por ora, apresentar as duas é a postura honesta.

Além disso, esse sintoma está confirmado em vários idiomas. O relator do #53247 usa um ambiente em português, no qual a caixa de diálogo mostra "Há um outro programa usando este arquivo no momento" — o mesmo sintoma do texto em inglês/japonês.

🔴 Situação de uma correção oficial: no momento da investigação, nenhuma correção permanente oficial foi lançada. A issue central #53247 continua aberta (Open) (sem responsável designado). Na issue, correções permanentes são propostas — mudar o CoworkVMService de início automático para sob demanda (Manual), ou mover o binário do serviço para fora de WindowsApps — mas estão em fase de proposta.

6. Verifique na sua própria máquina (PowerShell)

Você pode checar se o seu problema é o mesmo deste artigo (sem necessidade de privilégios de administrador). Se os eventos 215/208 e 0x80070020 aparecerem, é o mesmo problema.

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message | Format-List

Para cruzar com o seu histórico de atualizações e ver as configurações atuais do serviço incluído:

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
  Select-Object Name, StartMode, State, PathName

7. Problemas diferentes fáceis de confundir

O Claude Desktop (Windows) tem outros bugs com códigos parecidos que são fáceis de confundir. Eles são distintos do 0x80070020 deste artigo (uma falha de inicialização), então mantenha-os separados.

Sintoma	Código	Diferença em relação a este bug
Este artigo: não inicia depois da atualização	`0x80070020`	—
A atualização falha (#49655)	`0x80073CF6`	Uma falha de atualização, não de inicialização. Código diferente.
Reinstalação travada em "Servicing" (#51132)	`0x80073D28` etc.	Uma paralisação da implantação. Código diferente.

Além disso, quando o Claude Code CLI (o claude.exe que o aplicativo desktop gerencia) é atualizado, você pode ver EPERM: operation not permitted, unlink ... claude.exe, mas isso é apenas uma falha ao excluir a versão antiga — a nova foi instalada normalmente — e não tem relação com este bug.

Resumo

✅ Saia do Windows → entre de novo primeiro: a recuperação não exige necessariamente um reinício completo do PC (#53247). Se isso falhar, reinicie o PC.
🔴 Parar/reregistrar o serviço é relatado como algo que não funciona: tende a desperdiçar tempo, então evite.
✅ A causa real não é um "bloqueio de arquivo": é uma falha na camada de contêiner AppX (conversão Job→Silo). O texto da caixa de diálogo não reflete a realidade.
🔴 O gatilho tem duas explicações sem definição: o serviço segurando o Job Object (#57221) vs. falha na inicialização → handle órfão (#53247). Ainda sem correção oficial.
✅ A correção permanente é migrar para a versão Squirrel: relatado como algo que resolve tanto o problema de atualização quanto o de inicialização (#57221).

Este artigo se baseia em registros de investigação de uma única máquina (Windows 11 Home, 10.0.26200) cruzados com issues do GitHub. Use-o sabendo, com honestidade, que ele pode não reproduzir de forma idêntica para todos os usuários e que os detalhes finos da causa continuam sem definição.

FAQ

Q1. Qual é a forma mais rápida de resolver?

Saia do Windows uma vez e entre de novo (Iniciar → ícone do seu usuário → "Sair"). Não é reiniciar o PC, e não é sair do aplicativo/conta do Claude. Conforme o #53247, o handle órfão por trás disso persiste por sessão de usuário do Windows, então um reinício completo do PC pode ser desnecessário. Se ainda assim não recuperar, reinicie o PC.

Q2. Vi "basta parar o serviço" — isso funciona?

Para esse bug há relatos de que não funciona (#48003, #53247). O Stop-Service CoworkVMService reinicia e o erro volta a ocorrer, e nem o Reset-AppxPackage nem reiniciar os vários serviços resolveram. É mais racional tentar sair da sessão primeiro.

Q3. O arquivo está realmente bloqueado?

Não. A caixa de diálogo parece dizer "o arquivo está em uso", mas a verificação (handle.exe / Process Explorer) confirmou que não há bloqueio de arquivo no espaço do usuário (#53247). O que há de verdade é uma falha na camada de contêiner (conversão de Job Object → Silo) do AppX/Desktop Bridge; o código genérico 0x80070020 (ERROR_SHARING_VIOLATION) é simplesmente exibido dessa forma.

Q4. Então, no fim das contas, qual é a causa?

O problema na camada de contêiner está confirmado, mas o gatilho tem duas explicações sem definição: (1) o CoworkVMService (início automático) segurando o Job Object (#57221), e (2) uma falha na inicialização que deixa a limpeza do Silo/Job por fazer, restando um handle órfão (#53247). Como parar o serviço não resolve, o que contradiz (1), não dá para afirmar com certeza por ora.

Q5. Existe uma correção oficial?

No momento da investigação, nenhuma correção permanente oficial foi lançada. A issue central #53247 continua aberta (Open). Na issue, correções permanentes como mudar o serviço para início sob demanda (Manual) estão em fase de proposta.

Q6. Acontece a cada atualização?

🔴 Não dá para afirmar com certeza. Na máquina havia a sensação de que "acontece a cada atualização", mas o log de eventos só o mostrou em 2 de 6 atualizações (registros mais antigos podem ter sido descartados pelo limite de tamanho do log, então fica indeterminado). A frequência pode variar de máquina para máquina.

Q7. Como impedir que se repita?

Há um relato de que abandonar a versão MSIX (Store) e migrar para a versão Squirrel (instalador) resolveu tanto o problema de atualização quanto o de inicialização (#57221). Você desinstala completamente a versão da Store e depois instala a versão do instalador pelo site oficial ou via winget. Se você tiver restrições como uma política de distribuição corporativa, verifique antes.