Claude Desktop 0x80070020: no arranca tras actualizar

Q: ¿Cuál es la forma más rápida de arreglarlo?

Cierra sesión en Windows una vez y vuelve a iniciarla (Inicio → tu icono de usuario → «Cerrar sesión»). No es reiniciar el PC, ni cerrar sesión en la app/cuenta de Claude. Según #53247, el handle huérfano que hay detrás persiste por sesión de usuario de Windows, así que puede que no haga falta reiniciar todo el PC. Si aun así no se recupera, reinicia el PC.

Q: Vi «basta con detener el servicio»: ¿funciona?

Para este fallo se reporta que no funciona (#48003, #53247). Stop-Service CoworkVMService se reinicia y el error reaparece, y Reset-AppxPackage y reiniciar los distintos servicios tampoco lo resolvieron. Es más racional probar primero a cerrar sesión.

Q: ¿El archivo está realmente bloqueado?

No. El diálogo se lee como «el archivo está en uso», pero la verificación (handle.exe / Process Explorer) confirmó que no hay ningún bloqueo de archivo en el espacio de usuario (#53247). Lo real es un fallo en la capa de contenedor (conversión Job Object → Silo) de AppX/Desktop Bridge; el código genérico 0x80070020 (ERROR_SHARING_VIOLATION) simplemente se traduce de esa manera.

Q: Entonces, ¿cuál es la causa, al final?

El problema en la capa de contenedor está confirmado, pero el desencadenante tiene dos explicaciones sin resolver: (1) CoworkVMService (inicio automático) reteniendo el Job Object (#57221), y (2) un fallo al arrancar que deja sin hacer la limpieza de Silo/Job, dejando un handle huérfano (#53247). Como detener el servicio no lo arregla, lo que contradice a (1), por ahora no puede afirmarse con rotundidad.

Q: ¿Hay una corrección oficial?

En el momento de la investigación, no se ha publicado ninguna corrección oficial permanente. El issue central #53247 sigue abierto. En el issue, correcciones permanentes como cambiar el servicio a inicio bajo demanda (Manual) están en fase de propuesta.

Q: ¿Pasa en cada actualización?

🔴 No puede afirmarse con rotundidad. En el equipo había la sensación de que «pasa en cada actualización», pero el registro de eventos solo lo mostró en 2 de 6 actualizaciones (los registros más antiguos pueden haber desaparecido por el límite de tamaño del log, así que queda indeterminado). La frecuencia puede variar según el equipo.

Q: ¿Cómo evito que vuelva a pasar?

Hay un reporte de que abandonar la versión MSIX (Store) y cambiar a la versión Squirrel (instalador) resolvió tanto el problema de actualización como el de arranque (#57221). Desinstalas por completo la versión de Store y luego instalas la versión con instalador desde el sitio oficial o mediante winget. Si tienes restricciones como una política de distribución corporativa, compruébalo antes.

Claude Desktop 0x80070020: no arranca tras actualizar

Contenido

1. Conclusión: primero cierra sesión en Windows para recuperarlo
2. Síntoma: aparece al abrir la app tras una actualización
3. La solución: lo que funciona y lo que no
4. Qué es realmente el error: no es un bloqueo de archivo (confirmado)
5. Dos explicaciones enfrentadas, aún sin resolver
6. Compruébalo en tu propio equipo (PowerShell)
7. Problemas distintos que es fácil confundir
Resumen
Preguntas frecuentes

Justo después de actualizar Claude Desktop (Windows), al intentar abrir la app aparece un cuadro de diálogo que dice «Hay otro programa que está usando este archivo en este momento» y la aplicación no arranca, y se queda así hasta que reinicias el PC. Es un fallo conocido reportado en la versión de Microsoft Store (MSIX) de Claude Desktop (GitHub #53247 y otros).

Vayamos primero a la conclusión. No hace falta necesariamente reiniciar por completo el PC. En muchos casos basta con cerrar la sesión de Windows y volver a iniciarla para recuperarlo (no es reiniciar el PC ni cerrar sesión en Claude). A continuación separamos lo que funciona, lo que no y qué es realmente el error, dividido en confirmado / inferido / sin confirmar. Este artículo se basa en los registros de investigación de un único equipo (Windows 11 Home, 10.0.26200) contrastados con issues conocidos de GitHub.

⚠️ Etiquetas de confianza en este artículo: ✅ Confirmado = verificado directamente en los registros del equipo o en un issue / 🟡 Inferido = interpretación a partir de indicios / 🔴 Sin confirmar = no determinado. No afirmamos cosas que no podemos probar, como que «la causa es un bloqueo de archivo».

0x80070020 · APPMODEL-RUNTIME 215 / 208

Orden de recuperación que conviene probar primero

① Cierra sesión en Windows → inicia sesión

Inicio → tu icono de usuario → «Cerrar sesión». Lo más rápido; puede que no haga falta reiniciar todo el PC (#53247)

② Reinicia el PC

Fiable pero pesado. Cuando ① no lo recupera

③ Cambia a la versión Squirrel

Solución permanente que evita la reaparición (autor de #57221)

1. Conclusión: primero cierra sesión en Windows para recuperarlo

El daño real de este fallo es «no poder abrir la app», pero recuperarlo no exige necesariamente reiniciar por completo el PC. Según el análisis de #53247, el «handle huérfano» que está detrás del problema persiste por sesión de usuario de Windows, de modo que basta con cerrar la sesión de Windows y volver a iniciarla para eliminarlo. Casi todo el mundo reinicia el PC entero por reflejo, así que esto ahorra ese tiempo.

«Cerrar sesión» se refiere a Windows: no es reiniciar el PC ni cerrar sesión en Claude

El cierre de sesión del que hablamos es cerrar la sesión de tu cuenta de usuario de Windows (Inicio → tu icono de usuario abajo a la izquierda → «Cerrar sesión»). Las apps abiertas se cierran, pero el PC no se apaga y es más rápido que reiniciar. No es cerrar sesión en la app/cuenta de Claude, ni tampoco volver a abrir la app: eso no lo arregla.

✅ Si quieres arreglarlo ya: cierra sesión → inicia sesión. Hay casos reportados en los que esto permite volver a abrir la app (#53247).
✅ Si quieres arreglarlo con seguridad: reinicia el PC. Pesado, pero fiable.
✅ Si quieres que no vuelva a pasar: abandona la versión MSIX y cambia a la versión Squirrel (instalador) (más abajo; según el autor de #57221).

2. Síntoma: aparece al abrir la app tras una actualización

La secuencia típica: después de aplicarse una actualización de Claude Desktop, al abrir la app aparece un cuadro de diálogo al estilo del Explorador de Windows que dice «Hay otro programa que está usando este archivo en este momento», y no arranca. Cerrarla y volver a abrirla da lo mismo, y no se recupera hasta reiniciar el PC (o cerrar sesión).

Y algo clave: el texto de este diálogo no refleja con precisión lo que está pasando (detalles en §4). Además, la actualización en sí se completó con éxito: lo que falla no es la actualización, sino «abrir la app». Esto afecta a la versión de Microsoft Store (MSIX) de Claude Desktop.

3. La solución: lo que funciona y lo que no

Esta es la mayor trampa. Por internet encontrarás afirmaciones del tipo «se arregla deteniendo el servicio», pero para este fallo se reporta que eso no funciona. Separemos con claridad lo que funciona de lo que no.

✅ Funciona (reportado)

Cerrar sesión en Windows → iniciar sesión (lo más rápido; puede que no haga falta reiniciar el PC)
Reiniciar el PC (fiable)
Cambiar a la versión Squirrel (permanente; evita la reaparición)

🔴 Se reporta que NO funciona (no recomendado)

Stop-Service CoworkVMService (se reinicia y reaparece)
taskkill sobre todos los procesos de Claude/Cowork
Reset-AppxPackage / Add-AppxPackage -Register
Reiniciar AppXSvc, ClipSVC, vmcompute, etc.

Los elementos de la derecha aparecen registrados como probados y fallidos tanto en #48003 como en #53247. Tienden a hacer perder tiempo, así que lo racional es probar primero a cerrar sesión.

Solución permanente: cambiar a la versión Squirrel (instalador)

Si topar con esto en cada actualización te resulta insoportable, el autor de #57221 afirma que desinstalar la versión MSIX y cambiar a la versión con instalador (Squirrel) resolvió tanto el problema de actualización como el de arranque. En esencia, los pasos son:

Desinstala por completo la versión de Store (MSIX) de Claude Desktop.
Instala la versión con instalador desde la descarga oficial de Claude o mediante winget (por ejemplo, winget install Anthropic.Claude).
A partir de ahí, la actualización automática la lleva a la última versión.

🟡 La razón que se da es que así se sale de las restricciones de C:\Program Files\WindowsApps y de la capa del contenedor AppX. El comportamiento puede variar según el entorno, así que revisa tu caso de uso (política de distribución corporativa, etc.) antes de cambiar.

4. Qué es realmente el error: no es un bloqueo de archivo (confirmado)

El diálogo se lee como «el archivo está en uso», pero en los registros del equipo el fallo está en otro sitio. El registro de eventos Microsoft-Windows-AppModel-Runtime/Admin anota lo siguiente (✅ confirmado en el equipo):

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. El código que Windows traduce de forma genérica como «el proceso no puede acceder al archivo porque está siendo usado por otro proceso». Eso es en realidad lo que dice el diálogo.
`[LaunchProcess]`	Un fallo de arranque, no un fallo de actualización (la actualización ya se completó).
Dónde falla	Al crear el contenedor Desktop AppX: en concreto, en el paso que convierte el Job Object en un Silo.

Y ✅ se ha verificado que «no existe ningún bloqueo de archivo». En #53247, al comprobarlo con handle.exe y Process Explorer no apareció ningún bloqueo de archivo en el espacio de usuario. Por tanto, «porque otro programa retiene el archivo» es incorrecto, al menos como bloqueo en el espacio de usuario. Lo real es un problema en la capa de contenedor (Job/Silo) de AppX/Desktop Bridge.

5. Dos explicaciones enfrentadas, aún sin resolver

Que se trata de «un problema en la capa de contenedor» está confirmado, pero sobre el desencadenante hay dos posturas y no está zanjado. Evitamos afirmar una sola y presentamos ambas.

Postura A: el servicio retiene el Job Object (#57221)

El servicio incluido CoworkVMService (cuenta SYSTEM, inicio automático) retiene el Job Object del paquete y bloquea la creación del contenedor del nuevo paquete. En el equipo, el error ocurrió en el mismo segundo que una reinstalación del servicio, coherente con esta postura (🟡 indicios).

Postura B: un fallo al arrancar omite la limpieza (#53247)

Si el proceso de Claude se cae al arrancar, la limpieza de Silo/Job del lado del kernel no se ejecuta y queda un handle huérfano. Los arranques posteriores fallan entonces al convertir el job del mismo paquete. Que cerrar sesión lo arregle es coherente con esta postura.

Fíjate en la tensión: si la postura A (el servicio retiene) fuera correcta, «detener el servicio» debería arreglarlo, pero se reporta que no (§3). Por esta contradicción, no está zanjado cuál es la causa principal. 🔴 Por ahora, lo honesto es presentar ambas.

Además, este síntoma está confirmado en varios idiomas. El autor de #53247 usa un entorno en portugués, donde el diálogo dice «Há um outro programa usando este arquivo no momento» (otro programa está usando este archivo en este momento): el mismo síntoma que el texto en inglés o japonés.

🔴 Estado de una corrección oficial: en el momento de la investigación, no se ha publicado ninguna corrección oficial permanente. El issue central #53247 sigue abierto (Open) (sin responsable asignado). En el issue se proponen correcciones permanentes —cambiar CoworkVMService de inicio automático a bajo demanda (Manual), o mover el binario del servicio fuera de WindowsApps—, pero están en fase de propuesta.

6. Compruébalo en tu propio equipo (PowerShell)

Puedes comprobar si tu incidencia es la misma que la de este artículo (no se necesitan permisos de administrador). Si aparecen los eventos 215/208 y 0x80070020, es el mismo problema.

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

Para contrastarlo con tu historial de actualizaciones y ver la configuración actual del servicio incluido:

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 distintos que es fácil confundir

Claude Desktop (Windows) tiene otros fallos con códigos de aspecto parecido que son fáciles de confundir. Son distintos del 0x80070020 de este artículo (un fallo de arranque), así que conviene diferenciarlos.

Síntoma	Código	Diferencia con este fallo
Este artículo: no arranca tras actualizar	`0x80070020`	—
La actualización falla (#49655)	`0x80073CF6`	Un fallo de actualización, no de arranque. Código distinto.
La reinstalación se queda atascada en «Servicing» (#51132)	`0x80073D28`, etc.	Un atasco en el despliegue. Código distinto.

Además, cuando se actualiza la CLI de Claude Code (el claude.exe que gestiona la app de escritorio), puedes ver EPERM: operation not permitted, unlink ... claude.exe, pero eso es solo un fallo al borrar la versión antigua —la nueva se instaló bien— y no tiene relación con este fallo.

Resumen

✅ Primero cierra sesión en Windows → inicia sesión: recuperarlo no requiere necesariamente reiniciar por completo el PC (#53247). Si eso falla, reinicia el PC.
🔴 Detener o volver a registrar el servicio se reporta que no funciona: tiende a hacer perder tiempo, así que evítalo.
✅ La causa real no es un «bloqueo de archivo»: es un fallo en la capa de contenedor AppX (conversión Job→Silo). El texto del diálogo no refleja la realidad.
🔴 El desencadenante tiene dos explicaciones sin resolver: el servicio que retiene el Job Object (#57221) frente a un fallo al arrancar que deja limpieza pendiente (#53247). Aún no hay corrección oficial.
✅ La solución permanente es cambiar a la versión Squirrel: se reporta que resuelve tanto el problema de actualización como el de arranque (#57221).

Este artículo se basa en los registros de investigación de un único equipo (Windows 11 Home, 10.0.26200) contrastados con issues de GitHub. Úsalo sabiendo, con honestidad, que puede no reproducirse igual para todos los usuarios y que los detalles finos de la causa siguen sin resolverse.

Preguntas frecuentes

Q1. ¿Cuál es la forma más rápida de arreglarlo?

Cierra sesión en Windows una vez y vuelve a iniciarla (Inicio → tu icono de usuario → «Cerrar sesión»). No es reiniciar el PC, ni cerrar sesión en la app/cuenta de Claude. Según #53247, el handle huérfano que hay detrás persiste por sesión de usuario de Windows, así que puede que no haga falta reiniciar todo el PC. Si aun así no se recupera, reinicia el PC.

Q2. Vi «basta con detener el servicio»: ¿funciona?

Para este fallo se reporta que no funciona (#48003, #53247). Stop-Service CoworkVMService se reinicia y el error reaparece, y Reset-AppxPackage y reiniciar los distintos servicios tampoco lo resolvieron. Es más racional probar primero a cerrar sesión.

Q3. ¿El archivo está realmente bloqueado?

No. El diálogo se lee como «el archivo está en uso», pero la verificación (handle.exe / Process Explorer) confirmó que no hay ningún bloqueo de archivo en el espacio de usuario (#53247). Lo real es un fallo en la capa de contenedor (conversión Job Object → Silo) de AppX/Desktop Bridge; el código genérico 0x80070020 (ERROR_SHARING_VIOLATION) simplemente se traduce de esa manera.

Q4. Entonces, ¿cuál es la causa, al final?

El problema en la capa de contenedor está confirmado, pero el desencadenante tiene dos explicaciones sin resolver: (1) CoworkVMService (inicio automático) reteniendo el Job Object (#57221), y (2) un fallo al arrancar que deja sin hacer la limpieza de Silo/Job, dejando un handle huérfano (#53247). Como detener el servicio no lo arregla, lo que contradice a (1), por ahora no puede afirmarse con rotundidad.

Q5. ¿Hay una corrección oficial?

En el momento de la investigación, no se ha publicado ninguna corrección oficial permanente. El issue central #53247 sigue abierto. En el issue, correcciones permanentes como cambiar el servicio a inicio bajo demanda (Manual) están en fase de propuesta.

Q6. ¿Pasa en cada actualización?

🔴 No puede afirmarse con rotundidad. En el equipo había la sensación de que «pasa en cada actualización», pero el registro de eventos solo lo mostró en 2 de 6 actualizaciones (los registros más antiguos pueden haber desaparecido por el límite de tamaño del log, así que queda indeterminado). La frecuencia puede variar según el equipo.

Q7. ¿Cómo evito que vuelva a pasar?

Hay un reporte de que abandonar la versión MSIX (Store) y cambiar a la versión Squirrel (instalador) resolvió tanto el problema de actualización como el de arranque (#57221). Desinstalas por completo la versión de Store y luego instalas la versión con instalador desde el sitio oficial o mediante winget. Si tienes restricciones como una política de distribución corporativa, compruébalo antes.