Claude Code Desktop: O Guia Completo de 2026 (Chat, Cowork, Code)

- Os requisitos de versão, de plano e os limites de plataforma deste artigo foram conferidos na documentação oficial no momento em que escrevi (2026-08-20). Os recursos do Desktop mudam rápido, então confira a documentação ao vivo antes de depender de um caminho de menu exato.

O que é o Claude Code Desktop App? (Chat vs Cowork vs Code)

Resumindo: é um aplicativo nativo (não um invólucro web) com três abas separadas, cada uma feita para um trabalho diferente. Você não precisa escolher "Desktop ou CLI" - o Desktop é só mais uma superfície sobre o mesmo Claude Code baseado em terminal que você talvez já conheça.

As três abas compartilham uma conta e um aplicativo, mas o modelo de execução é diferente em cada uma: o Chat nunca toca nos seus arquivos, o Cowork roda dentro de uma VM isolada e o Code é onde o Claude Code de fato lê e edita código na sua máquina - a mesma mecânica que você já conhece da CLI, só que com uma barra lateral, abas e um diff visual no lugar de rolar logs no terminal.

Por que dividir em três abas em vez de uma só janela de chat? Porque esses três trabalhos carregam riscos diferentes: um Q&A não precisa de permissão de escrita nos seus arquivos, um agente em segundo plano rodando por dezenas de minutos não deveria ler direto do seu disco, e editar código é o oposto - só ajuda se puder tocar em arquivos de verdade. Dividir em abas significa que você identifica o modo de uma sessão só pela aba em que ela está, em vez de precisar lembrar quais permissões concedeu àquele chat específico.

Instalando o app Desktop - macOS, Windows, Linux (beta), WSL

O Desktop exige um plano Pro, Max, Team ou Enterprise (não está disponível no Free) - confira o seu plano atual antes de instalar, já que a liberação de recursos por plano pode mudar.

Alguns detalhes fáceis de deixar passar: o Windows precisa do Git for Windows pré-instalado (ele não vem junto no instalador), e no beta de Linux um conjunto de recursos "bons de ter", como Computer Use e ditado por voz, ainda não está lá - ainda é beta, não espere paridade total com macOS/Windows. No WSL, o Claude Code roda de verdade dentro da sua distro Linux (caminhos como /home/user/project, não C:\Users\...), então hooks do git, permissões e symlinks se comportam todos como Linux de verdade - em troca, você perde temporariamente algumas comodidades da interface, como o navegador de arquivos integrado.

Se você tem escolha, qual plataforma está mais tranquila agora? Para a maioria dos leitores, macOS e Windows são as duas builds estáveis com todos os recursos - dá para usar na hora, sem contrapartidas. O Linux ainda é beta, então, se você precisa de Computer Use ou ditado, fique na CLI ou espere uma versão estável. O WSL faz sentido se você já trabalha dentro de uma distro Linux no Windows e não quer que o Desktop te afaste dos seus caminhos e ferramentas de sempre - só aceite as comodidades de interface que faltam, mencionadas acima.

Comece sua primeira sessão na aba Code

O fluxo de configuração é direto: escolha um ambiente (Local / Cloud / SSH / WSL) → escolha a pasta do projeto → escolha um modelo → escolha um modo de permissão → digite a tarefa → revise o diff. Nada disso exige digitar um comando no terminal.

O modo de permissão decide quanto o agente pode fazer sozinho antes de precisar que você aprove algo:

• Manual - pede aprovação a cada mudança de arquivo e a cada comando.
• Accept edits - aplica edições de arquivo automaticamente, mas ainda pergunta antes de comandos de shell arriscados.
• Plan - só lê e planeja, sem mudar arquivos até você aprovar o plano.
• Auto - roda a maior parte da tarefa de forma contínua, parando só em ações de risco mais alto.
• Bypass - pula quase todas as confirmações, o equivalente ao --dangerously-skip-permissions na CLI - use com muito cuidado mesmo.

Se você está vindo da CLI, um bom hábito: escolha Plan na primeira vez que rodar em um repositório desconhecido, leia com atenção o plano proposto pelo agente e só então suba para Accept edits ou Auto quando confiar nele.

As quatro opções de ambiente não são só nomes diferentes - elas decidem onde o seu código realmente roda. O Local roda na sua própria máquina, lendo e escrevendo arquivos de verdade. O Cloud roda dentro de um sandbox hospedado pela Anthropic, útil se sua máquina é fraquinha ou se você ainda não quer conceder acesso direto de escrita a ela. O SSH conecta a uma máquina remota que você gerencia (uma máquina de dev, um servidor interno) e roda o agente ali. O WSL roda dentro da sua distro Linux no Windows, como vimos na seção de instalação. Escolher o ambiente errado é o motivo mais comum de um agente "não enxergar" um arquivo que você achava que ele veria - o primeiro passo de depuração é checar em qual ambiente ele está rodando de fato.

Sessões paralelas e isolamento com Git worktree

É aqui que o Desktop claramente ganha de fazer malabarismo manual com abas de terminal: cada aba de sessão na barra lateral roda automaticamente na sua própria Git worktree, tendo como padrão <project-root>/.claude/worktrees/ (você pode mudar o local e o prefixo da branch). Isso significa que duas sessões podem trabalhar no mesmo repositório ao mesmo tempo sem se atrapalhar - cada uma ganha sua própria branch e diretório de trabalho.

Para navegar entre sessões: Ctrl+Tab circula pelas abas da barra lateral, e segurar Ctrl/Cmd enquanto clica abre a visão dividida, para você acompanhar duas sessões lado a lado. Se houver um arquivo no gitignore que você ainda quer que toda worktree enxergue (um .env.local de exemplo, um certificado de dev), declare-o no .worktreeinclude para que ele seja copiado para cada nova worktree em vez de você copiar na mão.

Um exemplo prático: você tem dois trabalhos independentes no mesmo repositório - corrigir um bug de API e escrever testes para um recurso não relacionado. Em vez de fazer um depois do outro, abra duas abas de sessão, cada uma com sua worktree e branch, e deixe as duas rodarem em paralelo enquanto você cuida de outra coisa; quando ambas terminarem, revise cada diff separadamente e faça o merge de uma por vez - sem risco de os dois agentes atrapalharem os arquivos um do outro, já que eles nunca compartilham um diretório de trabalho.

Revisão visual de diff e monitoramento de PR

Toda mudança mostra um indicador de estatística de diff, como +12 -1, bem na aba da sessão, com comentários de linha inline quando você quer responder direto no código em vez de digitar de volta no chat.

O botão "Review code" roda uma passada de revisão automática, mas ele só sinaliza problemas de alto valor - erros de compilação, bugs de lógica, brechas de segurança - e não implicâncias de estilo ou lint (menos ruído). Se você usa GitHub, o Desktop também tem alternadores de auto-correção e auto-merge para CI: o agente corrige uma execução de CI que falhou e faz o merge assim que ela fica verde, mas isso só funciona se você tiver a CLI gh autenticada localmente, e o merge é sempre um squash-merge (sem opção de merge-commit nem rebase).

A vantagem dessa divisão: você não precisa reler o diff inteiro caçando o que importa - o "Review code" já filtra os problemas de alto valor, e estilo/formatação continua a cargo do lint/CI, como de costume. Se você está acostumada a revisar PRs no GitHub, a sensação é parecida - só que você revisa enquanto o agente ainda está rodando, antes mesmo de abrir um PR de verdade, então pega os problemas bem mais cedo do que esperando o CI reportar.

Tarefas agendadas vs. Cloud Routines vs. /loop

Essa é a parte que mais costuma confundir, porque o Claude Code agora tem três mecanismos de agendamento distintos, não um só:

Resumindo: se você precisa que algo rode com a máquina desligada ou o app fechado, escolha Cloud Routines (a contrapartida é não ter acesso a arquivos locais e um intervalo mínimo bem mais grosseiro, cerca de uma hora em vez de um minuto). Se você precisa de uma tarefa lendo ou escrevendo arquivos locais em um intervalo curto, use uma tarefa agendada do Desktop ou o /loop da CLI - mas os dois só rodam com a máquina ligada e acordada. Se a máquina entra em suspensão bem na hora em que uma execução venceria, o Desktop tem um mecanismo de recuperação: ao acordar, ele roda exatamente uma execução perdida (ele não acumula todas as que você perdeu). Para mais sobre o lado da nuvem, veja Claude Code Routines explicado.

Qual mecanismo combina com qual trabalho: uma tarefa como "toda manhã, verificar dependências desatualizadas e abrir um PR de atualização" combina com Cloud Routines - não precisa da sua máquina para nada. Uma tarefa como "rodar de novo a suíte de testes sempre que um arquivo mudar enquanto eu programo" combina com o /loop da CLI ou uma tarefa do Desktop - ela precisa ler arquivos locais repetidamente num intervalo curto, e você já está na sua máquina mesmo.

Painel do Simulador de iOS (só macOS, beta)

Se você desenvolve apps de iOS, o Desktop tem um painel que mostra o Simulador de iOS bem ao lado da sua sessão de código - útil para deixar o próprio agente rodar e inspecionar os resultados de UI, em vez de você trocar para uma janela separada do Simulador. Alguns limites que vale conhecer: só macOS, exige o Xcode 26.x (o Xcode 27 não funciona no momento por causa de uma mudança no Device Hub), só sessões locais (não Cloud/SSH), até 4 dispositivos por sessão, e cada dispositivo precisa do próprio consentimento antes de o agente poder controlá-lo. Uma coisa para já saber de antemão: capturas de tela do Simulador são enviadas à Anthropic sob a política normal de retenção - se o seu app de teste exibe dados sensíveis na tela, pese isso antes de ativar este painel.

Por que esse painel importa, mesmo sendo beta: em vez de você compilar, abrir o Simulador e tirar print de um bug para descrever ao agente, agora o próprio agente vê o resultado de UI e consegue fazer o ciclo corrigir-compilar-conferir sem você bancar o intermediário. Em troca, ainda é um recurso inicial - conte com reinícios ocasionais do painel ou com os limites de versão do Xcode citados acima.

Sessões via Dispatch - comece o trabalho pelo celular

O Dispatch é uma conversa persistente na aba Cowork: você manda uma tarefa por mensagem do celular (o app Claude mobile ou a web) e, se o conteúdo parecer uma tarefa de dev, ela é roteada automaticamente para uma sessão da aba Code marcada como Dispatch no Desktop - você recebe uma notificação push quando ela termina ou quando precisa da sua aprovação. Alguns limites que vale conhecer: o Dispatch está só nos planos Pro/Max, ainda não em Team/Enterprise, e as aprovações de permissão concedidas em uma sessão nascida de um Dispatch expiram depois de 30 minutos (diferente de uma sessão comum, em que a aprovação dura a sessão inteira).

Um exemplo prático: você está longe da mesa, recebe uma notificação push de que o CI falhou e digita pelo celular "corrija a falha de build, rode os testes de novo e depois abra um PR" - o Dispatch reconhece isso como uma tarefa de dev, sobe uma sessão da aba Code marcada como Dispatch e, quando você volta para a máquina, aquela sessão já está rodando há um tempo, esperando você aprovar uma permissão ou revisar o resultado, em vez de começar do zero.

Desktop vs. CLI vs. Web - qual você deve usar?

Três superfícies do mesmo Claude Code, compartilhando configuração (CLAUDE.md, MCP, hooks, skills, settings) - então alternar entre elas não te custa nada, é só uma forma diferente de interagir:

Alguns comandos da CLI têm uma "tradução" direta para o Desktop: escolher um modelo no menu suspenso da sessão equivale à flag --model; clicar de volta em uma aba de sessão antiga na barra lateral equivale ao --resume para continuar uma sessão anterior; e o modo Bypass do Desktop é exatamente o --dangerously-skip-permissions na CLI. Uma diferença que vale lembrar: a CLI tem um modo extra dontAsk que o Desktop ainda não tem - se o seu fluxo depende dele, fique na CLI para essa parte.

Para ser direta: se você precisa rodar o Claude Code em um pipeline de CI, um script de automação, ou precisa de --print/Agent SDK, o Desktop não é o lugar - isso ainda é território da CLI. Se você quer acesso rápido pelo navegador sem instalar nada, use o Claude Code na web. Se você programa todo dia e quer sessões paralelas com interface e diffs fáceis de olhar, o Desktop é a escolha mais confortável. Uma pequena comodidade: o comando /desktop na CLI move a sua sessão em andamento direto para o app Desktop (no momento, só macOS e Windows x64, e exige login por assinatura - não é compatível com uma API key).

Usando o AgentKit na aba Code do Desktop

Uma pergunta que aparece: uma skill ou kit instalado via AgentKit na CLI também funciona no Desktop? Pela própria documentação do Desktop, o app lê a mesma configuração ~/.claude que a CLI (skills, settings, MCP) - então, em tese, uma skill instalada pelo AgentKit deveria aparecer do mesmo jeito, invocada com / na caixa de prompt, parecido com o modo como você digitaria um comando estilo $ak: na CLI. Para ser precisa: isso é uma inferência a partir de como o Desktop descreve a "configuração compartilhada", não algo que a própria documentação do AgentKit confirme diretamente para a aba Code do Desktop - se isso importa para o seu fluxo, teste na sua própria máquina antes de depender disso num trabalho de verdade. Para ver o que o AgentKit realmente faz e se vale a pena, leia a análise do AgentKit (agentkit.best).

Perguntas frequentes (FAQ)

O Claude Code Desktop é gratuito?

Não, ele não está no plano Free. A aba Code precisa de Pro, Max, Team ou Enterprise; o Dispatch, especificamente, está só em Pro/Max, ainda não em Team/Enterprise. Confira as liberações de recurso do seu plano atual antes de instalar, já que isso pode mudar.

Ainda preciso instalar a CLI separadamente?

Para o dia a dia de programação, não - o Desktop roda o Claude Code completo pela aba Code. Mas, se você precisa de scripting, uso em CI, --print ou o Agent SDK, esses são exclusivos da CLI; o Desktop não os tem.

O Claude Code Desktop funciona no Linux?

Sim, mas ainda em beta: só Ubuntu 22.04+ e Debian 12+ são suportados, só as arquiteturas x86_64/arm64, e recursos como Computer Use e ditado por voz ainda não estão lá como no macOS/Windows.

Qual a diferença entre o Desktop e o Claude Code na web?

A web (claude.ai/code) roda inteiramente na nuvem, nunca toca nos arquivos locais da sua máquina e não precisa de nada instalado. O Desktop é um aplicativo nativo que lê e edita arquivos direto na sua máquina, com sessões paralelas e revisão visual de diff - a contrapartida é que você precisa instalá-lo e manter a máquina ligada.

Posso usar o Claude Code Desktop com o WSL?

Sim, no Windows: a sessão roda de verdade dentro da sua distro WSL2 com caminhos Linux nativos e precisa de git instalado na distro. Alguns recursos de interface, como o terminal integrado, conectores, plugins e @menção, não estão disponíveis no modo WSL até o momento em que escrevo.

As tarefas agendadas rodam se o meu computador estiver desligado?

As tarefas agendadas do Desktop e o /loop da CLI não rodam - ambos precisam da máquina ligada e acordada. Se ela estiver em suspensão quando uma execução venceria, o Desktop recupera com exatamente uma execução perdida assim que acorda. Se você precisa que algo rode independentemente do estado da máquina, use Cloud Routines (contrapartida: sem acesso a arquivos locais e um intervalo mínimo mais grosseiro, cerca de uma hora).

Conclusão

O Desktop não é um Claude Code diferente - é o mesmo Claude Code com uma interface gráfica por cima para trabalho paralelo, diffs visuais e agendamento sem terminal. Instale-o corretamente para a sua plataforma (lembre do Git for Windows, lembre de que o beta de Linux ainda está sem alguns recursos), escolha o modo de permissão certo quando estiver começando e use a superfície certa para cada trabalho - Desktop para a programação visual do dia a dia, CLI para scripts e CI, Web para acesso rápido sem instalar nada. Para se aprofundar no lado da CLI, veja o que é o Claude Code.