Claude Code Desktop: La Guía Completa de 2026 (Chat, Cowork, Code)
Claude Code Desktop App es una app nativa para macOS, Windows y Linux (beta) que reúne tres pestañas en una sola ventana: Chat (conversación normal, sin acceso a archivos - como claude.ai), Cowork (un agente autónomo en segundo plano que corre dentro de una VM en sandbox, en tu dispositivo o remota) y Code (el Claude Code completo con una interfaz gráfica - sesiones paralelas, revisión visual de diff, tareas programadas - sin necesidad de terminal). No reemplaza a la CLI; es solo otra forma de ejecutar el mismo Claude Code.
- Los requisitos de versión y de plan y los límites de plataforma de este artículo se contrastaron con la documentación oficial en el momento en que lo escribí (2026-08-20). Las funciones de Desktop cambian rápido, así que revisa la documentación en vivo antes de depender de una ruta de menú exacta.
¿Qué es Claude Code Desktop App? (Chat vs Cowork vs Code)
En corto: es una app nativa (no un envoltorio web) con tres pestañas separadas, cada una pensada para un trabajo distinto. No tienes que elegir "Desktop o CLI" - Desktop es solo otra superficie sobre el mismo Claude Code basado en terminal que quizá ya conoces.
| Pestaña | Qué hace | Acceso a archivos |
|---|---|---|
| Chat | Conversación general, Q&A, lluvia de ideas - parecido a la experiencia de claude.ai | Ninguno |
| Cowork | Agente autónomo en segundo plano, ejecuta tareas largas dentro de una VM en sandbox (en el dispositivo o remota) y avisa cuando termina | Solo dentro de su propio sandbox, no en tus archivos locales |
| Code | Asistente de programación interactivo - el foco de esta guía | Acceso directo a los archivos locales de tu proyecto |
Las tres pestañas comparten una cuenta y una app, pero el modelo de ejecución es distinto en cada una: Chat nunca toca tus archivos, Cowork corre dentro de una VM aislada, y Code es donde Claude Code de verdad lee y edita código en tu máquina - la misma mecánica que ya conoces de la CLI, solo que con una barra lateral, pestañas y un diff visual en lugar de desplazar registros del terminal.
¿Por qué dividir en tres pestañas en vez de una sola ventana de chat? Porque estos tres trabajos conllevan riesgos distintos: un Q&A no necesita permiso de escritura sobre tus archivos, un agente en segundo plano que corre durante decenas de minutos no debería leer directo de tu disco, y editar código es lo contrario - solo sirve si puede tocar archivos reales. Dividir en pestañas significa que reconoces el modo de una sesión con solo mirar en qué pestaña está, en vez de tener que recordar qué permisos le concediste a ese chat en concreto.
Instalar la app Desktop - macOS, Windows, Linux (beta), WSL
Desktop requiere un plan Pro, Max, Team o Enterprise (no está disponible en Free) - revisa tu plan actual antes de instalar, ya que la disponibilidad de funciones por plan puede cambiar.
| Plataforma | Cómo instalar | Notas |
|---|---|---|
| macOS | .dmg universal (corre tanto en Intel como en Apple Silicon) | No hace falta elegir la arquitectura por separado |
| Windows | Instalador x64 o ARM64 | Requiere tener Git for Windows ya instalado; reinicia después de instalar |
| Linux (beta) | Repositorio apt oficial | Solo Ubuntu 22.04+/Debian 12+, solo x86_64/arm64; aún sin Computer Use ni dictado |
| WSL | Corre en Windows, pero la sesión se ejecuta dentro de tu distro WSL2 | Usa rutas Linux nativas, necesita git dentro de la distro; aún sin terminal integrado, conectores, plugins, explorador de archivos ni @mención |
Algunos detalles fáciles de pasar por alto: Windows necesita Git for Windows preinstalado (no viene incluido en el instalador), y en la beta de Linux falta todavía un conjunto de funciones "que estaría bien tener", como Computer Use y dictado por voz - sigue en beta, no esperes paridad total con macOS/Windows. En WSL, Claude Code corre de verdad dentro de tu distro Linux (rutas como /home/user/project, no C:\Users\...), así que los hooks de git, los permisos y los symlinks se comportan todos como Linux real - a cambio, pierdes temporalmente algunas comodidades de la interfaz, como el explorador de archivos integrado.
Si puedes elegir, ¿qué plataforma va más fluida ahora mismo? Para la mayoría de lectores, macOS y Windows son las dos builds estables con todas las funciones - listas para usar de inmediato, sin concesiones. Linux sigue en beta, así que, si necesitas Computer Use o dictado, quédate en la CLI o espera una versión estable. WSL tiene sentido si ya trabajas dentro de una distro Linux en Windows y no quieres que Desktop te aleje de tus rutas y herramientas de siempre - solo asume las comodidades de interfaz que faltan, mencionadas arriba.
Empieza tu primera sesión en la pestaña Code
El flujo de configuración es directo: elige un entorno (Local / Cloud / SSH / WSL) → elige la carpeta del proyecto → elige un modelo → elige un modo de permisos → escribe la tarea → revisa el diff. Nada de esto requiere escribir un comando en el terminal.
El modo de permisos decide cuánto puede hacer el agente por su cuenta antes de necesitar que apruebes algo:
- Manual - pide aprobación en cada cambio de archivo y en cada comando.
- Accept edits - aplica las ediciones de archivos automáticamente, pero aún pregunta antes de comandos de shell arriesgados.
- Plan - solo lee y planifica, sin cambiar archivos hasta que apruebes el plan.
- Auto - ejecuta la mayor parte de la tarea de forma continua, y solo se detiene en acciones de mayor riesgo.
- Bypass - se salta casi todas las confirmaciones, el equivalente a
--dangerously-skip-permissionsen la CLI - úsalo con mucho cuidado de verdad.
Si vienes de la CLI, un buen hábito: elige Plan la primera vez que ejecutes en un repositorio que no conoces, lee con atención el plan que propone el agente y, solo cuando confíes en él, sube a Accept edits o Auto.
Las cuatro opciones de entorno no son solo nombres distintos - deciden dónde corre realmente tu código. Local corre en tu propia máquina, leyendo y escribiendo archivos de verdad. Cloud corre dentro de un sandbox alojado por Anthropic, útil si tu máquina va justa de potencia o si aún no quieres concederle acceso directo de escritura. SSH se conecta a una máquina remota que administras (un equipo de desarrollo, un servidor interno) y ejecuta el agente allí. WSL corre dentro de tu distro Linux en Windows, como vimos en la sección de instalación. Elegir el entorno equivocado es el motivo más común de que un agente "no vea" un archivo que creías que sí - el primer paso de depuración es comprobar en qué entorno está corriendo de verdad.
Sesiones paralelas y aislamiento con Git worktree
Aquí es donde Desktop claramente gana a hacer malabares a mano con pestañas de terminal: cada pestaña de sesión en la barra lateral corre automáticamente en su propia Git worktree, con valor por defecto <project-root>/.claude/worktrees/ (puedes cambiar la ubicación y el prefijo de la rama). Eso significa que dos sesiones pueden trabajar en el mismo repositorio a la vez sin pisarse - cada una obtiene su propia rama y su directorio de trabajo.
Para navegar entre sesiones: Ctrl+Tab rota por las pestañas de la barra lateral, y mantener Ctrl/Cmd mientras haces clic abre la vista dividida para ver dos sesiones en paralelo. Si hay un archivo en gitignore que aún quieres que vea cada worktree (un .env.local de ejemplo, un certificado de desarrollo), decláralo en .worktreeinclude para que se copie a cada nueva worktree en vez de copiarlo tú a mano.
Un ejemplo práctico: tienes dos trabajos independientes en el mismo repositorio - arreglar un bug de una API y escribir pruebas para una función no relacionada. En vez de hacerlos uno tras otro, abre dos pestañas de sesión, cada una con su worktree y su rama, y deja que ambas corran en paralelo mientras te ocupas de otra cosa; cuando las dos terminen, revisa cada diff por separado y haz el merge de una en una - sin riesgo de que los dos agentes se pisen los archivos, ya que nunca comparten un directorio de trabajo.
Revisión visual de diff y monitoreo de PR
Cada cambio muestra un indicador de estadística de diff, como
+12 -1, justo en la pestaña de la sesión, con comentarios de línea inline cuando quieres responder directo sobre el código en vez de escribirlo de vuelta en el chat.
El botón "Review code" ejecuta una pasada de revisión automática, pero solo señala problemas de alta señal - errores de compilación, bugs de lógica, agujeros de seguridad - y no minucias de estilo o lint (menos ruido). Si usas GitHub, Desktop también tiene interruptores de auto-corrección y auto-merge para CI: el agente arregla una ejecución de CI que falló y hace el merge en cuanto queda en verde, pero eso solo funciona si tienes la CLI gh autenticada localmente, y el merge siempre es un squash-merge (sin opción de merge-commit ni rebase).
La ventaja de esta división: no tienes que releer el diff entero cazando lo que importa - "Review code" ya filtra los problemas de alta señal, y el estilo/formato sigue a cargo del lint/CI, como siempre. Si estás acostumbrada a revisar PRs en GitHub, la sensación es parecida - solo que revisas mientras el agente aún está corriendo, antes incluso de que se abra un PR de verdad, así que atrapas los problemas mucho antes que esperando a que el CI reporte.
Tareas programadas vs. Cloud Routines vs. /loop
Esta es la parte que más suele confundir, porque Claude Code ahora tiene tres mecanismos de programación distintos, no uno solo:
| Mecanismo | Corre en | ¿Requiere la máquina encendida? | Acceso a archivos locales | Intervalo mínimo |
|---|---|---|---|---|
| Cloud Routines | La nube de Anthropic | No | No | ~1 hora |
| Tareas programadas de Desktop | Tu máquina, mediante la app Desktop | Sí, y la máquina debe estar despierta (no en suspensión) | Sí | ~1 minuto |
CLI /loop | Tu máquina, mediante el terminal | Sí | Sí | ~1 minuto |
En corto: si necesitas que algo corra con la máquina apagada o la app cerrada, elige Cloud Routines (la contrapartida es no tener acceso a archivos locales y un intervalo mínimo mucho más grueso, alrededor de una hora en vez de un minuto). Si necesitas una tarea que lea o escriba archivos locales en un intervalo corto, usa una tarea programada de Desktop o el /loop de la CLI - pero ambos solo corren con la máquina encendida y despierta. Si la máquina se duerme justo cuando toca una ejecución, Desktop tiene un mecanismo de recuperación: al despertar, ejecuta exactamente una ejecución perdida (no acumula todas las que te perdiste). Para más sobre el lado de la nube, mira Claude Code Routines explicado.
Qué mecanismo encaja con qué trabajo: una tarea como "cada mañana, comprobar dependencias desactualizadas y abrir un PR de actualización" encaja con Cloud Routines - no necesita tu máquina para nada. Una tarea como "volver a correr la suite de pruebas cada vez que cambia un archivo mientras programo" encaja con el /loop de la CLI o una tarea de Desktop - necesita leer archivos locales de forma repetida en un intervalo corto, y de todos modos ya estás en tu máquina.
Panel del Simulador de iOS (solo macOS, beta)
Si desarrollas apps de iOS, Desktop tiene un panel que muestra el Simulador de iOS justo al lado de tu sesión de código - útil para dejar que el propio agente ejecute e inspeccione los resultados de UI, en vez de que tú cambies a una ventana aparte del Simulador. Algunos límites que conviene conocer: solo macOS, requiere Xcode 26.x (Xcode 27 no funciona por ahora por un cambio en el Device Hub), solo sesiones locales (no Cloud/SSH), hasta 4 dispositivos por sesión, y cada dispositivo necesita su propio consentimiento antes de que el agente pueda controlarlo. Una cosa para saber de antemano: las capturas del Simulador se envían a Anthropic bajo la política de retención normal - si tu app de prueba muestra datos sensibles en pantalla, sopésalo antes de activar este panel.
Por qué importa este panel a pesar de estar en beta: en lugar de que tú compiles, abras el Simulador y hagas una captura de un bug para describírselo al agente, ahora el propio agente ve el resultado de UI y puede recorrer el ciclo corregir-compilar-comprobar sin que tú hagas de intermediaria. A cambio, sigue siendo una función temprana - cuenta con reinicios ocasionales del panel o con los límites de versión de Xcode señalados arriba.
Sesiones desde Dispatch - empieza a trabajar desde tu teléfono
Dispatch es una conversación persistente en la pestaña Cowork: mandas una tarea por mensaje desde tu teléfono (la app Claude móvil o la web) y, si el contenido parece una tarea de dev, se enruta automáticamente a una sesión de la pestaña Code etiquetada como Dispatch en Desktop - recibes una notificación push cuando termina o cuando necesita tu aprobación. Algunos límites que conviene conocer: Dispatch está solo en los planes Pro/Max, todavía no en Team/Enterprise, y las aprobaciones de permisos concedidas en una sesión nacida de un Dispatch expiran a los 30 minutos (a diferencia de una sesión normal, donde la aprobación dura toda la sesión).
Un ejemplo práctico: estás lejos del escritorio, recibes una notificación push de que el CI falló y escribes desde el teléfono "arregla el fallo de build, vuelve a correr las pruebas y luego abre un PR" - Dispatch lo reconoce como una tarea de dev, levanta una sesión de la pestaña Code etiquetada como Dispatch y, para cuando vuelves a tu máquina, esa sesión ya lleva un rato corriendo, esperando que apruebes un permiso o revises el resultado, en vez de empezar de cero.
Desktop vs. CLI vs. Web - ¿cuál deberías usar?
Tres superficies del mismo Claude Code, que comparten configuración (CLAUDE.md, MCP, hooks, skills, settings) - así que alternar entre ellas no te cuesta nada, es solo una forma distinta de interactuar:
| Dimensión | Desktop | CLI | Web (claude.ai/code) |
|---|---|---|---|
| Sesiones paralelas con interfaz | Sí (pestañas + vista dividida) | Posible, pero gestionas el terminal/tmux por tu cuenta | Limitado |
| Revisión visual de diff | Sí, integrada | No (se lee vía git diff) | Sí, pero solo en la nube |
| Scripting / automatización | No (flag --print o Agent SDK no disponibles) | Sí (flags, --print, integración con CI/script) | No |
| Modos de permisos | Los 5 modos de arriba | Conjunto completo, incluido dontAsk | Limitado |
| Soporte de distros Linux | Solo Ubuntu/Debian (beta) | Mucho más amplio | No hace falta (nada que instalar) |
| Acceso a archivos locales | Sí | Sí | No - totalmente en la nube |
Algunos comandos de la CLI tienen una "traducción" directa a Desktop: elegir un modelo en el desplegable de la sesión equivale a la flag --model; volver a hacer clic en una pestaña de sesión antigua en la barra lateral equivale a --resume para continuar una sesión anterior; y el modo Bypass de Desktop es exactamente --dangerously-skip-permissions en la CLI. Una diferencia que vale la pena recordar: la CLI tiene un modo extra dontAsk que Desktop aún no tiene - si tu flujo de trabajo depende de él, quédate en la CLI para esa parte.
Para ser directa: si necesitas ejecutar Claude Code en un pipeline de CI, un script de automatización, o necesitas --print/Agent SDK, Desktop no es el lugar - eso sigue siendo territorio de la CLI. Si quieres acceso rápido desde un navegador sin instalar nada, usa Claude Code en la web. Si programas a diario y quieres sesiones paralelas con interfaz y diffs cómodos de mirar, Desktop es la opción más cómoda. Una pequeña comodidad: el comando /desktop en la CLI mueve tu sesión en curso directo a la app Desktop (por ahora solo macOS y Windows x64, y requiere inicio de sesión por suscripción - no es compatible con una API key).
Usar AgentKit en la pestaña Code de Desktop
Una pregunta que surge: ¿una skill o kit instalado vía AgentKit en la CLI también funciona en Desktop? Según la propia documentación de Desktop, la app lee la misma configuración ~/.claude que la CLI (skills, settings, MCP) - así que, en teoría, una skill instalada por AgentKit debería aparecer del mismo modo, invocada con / en la caja del prompt, parecido a cómo escribirías un comando estilo $ak: en la CLI. Para ser precisa: esto es una inferencia a partir de cómo Desktop describe la "configuración compartida", no algo que la propia documentación de AgentKit confirme directamente para la pestaña Code de Desktop - si esto importa para tu flujo de trabajo, pruébalo en tu propia máquina antes de depender de ello en un trabajo real. Para ver qué hace realmente AgentKit y si vale la pena, lee la reseña de AgentKit (agentkit.best).
Preguntas frecuentes (FAQ)
¿Claude Code Desktop es gratis?
No, no está en el plan Free. La pestaña Code necesita Pro, Max, Team o Enterprise; Dispatch, en concreto, está solo en Pro/Max, todavía no en Team/Enterprise. Revisa la disponibilidad de funciones de tu plan actual antes de instalar, ya que esto puede cambiar.
¿Todavía necesito instalar la CLI por separado?
Para el día a día de programación, no - Desktop ejecuta el Claude Code completo a través de la pestaña Code. Pero si necesitas scripting, uso en CI, --print o el Agent SDK, esos son exclusivos de la CLI; Desktop no los tiene.
¿Claude Code Desktop funciona en Linux?
Sí, pero sigue en beta: solo se admiten Ubuntu 22.04+ y Debian 12+, solo las arquitecturas x86_64/arm64, y funciones como Computer Use y dictado por voz aún no están como en macOS/Windows.
¿Cuál es la diferencia entre Desktop y Claude Code en la web?
La web (claude.ai/code) corre por completo en la nube, nunca toca los archivos locales de tu máquina y no necesita nada instalado. Desktop es una app nativa que lee y edita archivos directamente en tu máquina, con sesiones paralelas y revisión visual de diff - la contrapartida es que tienes que instalarlo y mantener la máquina encendida.
¿Puedo usar Claude Code Desktop con WSL?
Sí, en Windows: la sesión corre de verdad dentro de tu distro WSL2 con rutas Linux nativas, y necesita git instalado en la distro. Algunas funciones de interfaz, como el terminal integrado, los conectores, los plugins y la @mención, no están disponibles en modo WSL al momento de escribir esto.
¿Las tareas programadas corren si mi computadora está apagada?
Las tareas programadas de Desktop y el /loop de la CLI no - ambos necesitan la máquina encendida y despierta. Si está en suspensión cuando toca una ejecución, Desktop la recupera con exactamente una ejecución perdida en cuanto despierta. Si necesitas que algo corra sin importar el estado de tu máquina, usa Cloud Routines (contrapartida: sin acceso a archivos locales y un intervalo mínimo más grueso, alrededor de una hora).
Conclusión
Desktop no es un Claude Code diferente - es el mismo Claude Code con una interfaz gráfica encima para trabajo en paralelo, diffs visuales y programación sin terminal. Instálalo correctamente para tu plataforma (recuerda Git for Windows, recuerda que la beta de Linux todavía no tiene algunas funciones), elige el modo de permisos adecuado cuando estés empezando y usa la superficie correcta para cada trabajo - Desktop para la programación visual del día a día, CLI para scripts y CI, Web para acceso rápido sin instalar nada. Para profundizar en el lado de la CLI, mira qué es Claude Code.