Como usar Claude Code Projects para coordenar tarefas em paralelo

Entender como usar Claude Code Projects começa por esta ideia: em uma conversa, você entrega um fluxo de trabalho de desenvolvimento ao Claude Code, e esse coordenador abre e acompanha threads separadas na nuvem para cada tarefa. O ganho não está em multiplicar janelas de chat. Está em perder menos tempo repetindo o contexto do repositório, distribuindo sessões e procurando a branch ou o pull request que exige sua atenção.

A experiência reformulada começou a ser liberada em 17 de setembro de 2026, e o acesso ainda é seletivo. Este guia mostra como verificar sua conta, configurar um repositório descartável, enviar duas tarefas independentes, revisar o trabalho entregue e entender exatamente qual contexto acompanha cada thread.

Claude Code Projects funciona como coordenador, não como pasta

Um projeto do Claude Code reúne uma conversa persistente com o Claude e as sessões na nuvem que ela inicia como threads. Pense nessa conversa como o chefe de uma oficina: você entrega o briefing, e bancadas separadas executam os trabalhos. Cada bancada tem seu próprio workspace, janela de contexto e branch do Git, enquanto o chefe recebe os relatórios e mantém a fila organizada.

Isso é diferente da experiência anterior de Projects no chat do Claude e no Cowork. A versão antiga agrupa conversas e arquivos de referência. A nova versão beta do Claude Code Projects inclui um coordenador que encaminha o trabalho para threads na nuvem, acompanha o status e leva o contexto do projeto para novas threads.

Toda thread começa com os repositórios e arquivos do projeto, instruções, memória, ambiente na nuvem selecionado, conectores da conta e os arquivos CLAUDE.md, skills e plugins presentes nos repositórios. As threads não herdam ferramentas que só existem no seu computador.

O custo direto de software favorece quem já assina um plano elegível do Claude. O Claude Pro custa $20 por mês, ou $17 mensais em um pagamento anual de $200, e o Max parte de $100 por mês. Projects não cobra uma taxa separada pela máquina virtual na nuvem. A ressalva está no consumo: cada thread é uma sessão completa do Claude Code, então o trabalho em paralelo esgota mais rapidamente os limites do mesmo plano.

Como comparação, as assinaturas individuais de agentes de programação verificadas para este guia vão de $10 a $200 por mês entre GitHub Copilot e Cursor. Se o Claude já é seu agente de programação, Projects não acrescenta outra licença à pilha. O que muda é o custo de coordenação; a necessidade de julgamento de engenharia continua a mesma.

Primeiro, confirme se sua conta recebeu a versão beta

Ter acesso exige mais do que simplesmente encontrar algum recurso chamado Projects no Claude.

1. Entre com uma conta Claude Pro ou Max.
2. Abra claude.ai/code ou a aba Code no aplicativo para desktop.
3. Procure Projects na barra lateral esquerda.
4. Se a opção não aparecer, a liberação ainda não chegou à sua conta. Entre na lista de espera da Anthropic e, enquanto isso, use sessões comuns na nuvem.

A primeira leva favorece contas Pro e Max que já usaram sessões na nuvem e não têm o Projects antigo no chat do Claude ou no Cowork. Contas Team e Enterprise ainda não receberam essa versão beta reformulada. Os Projects antigos continuam funcionando enquanto a Anthropic migra a experiência.

Se você ainda precisa instalar o Claude Code, autenticar a conta e fornecer contexto por meio de um CLAUDE.md no repositório, comece pelo guia geral de configuração do Claude Code. Projects se apoia nessas práticas de repositório, não as substitui.

Como usar Claude Code Projects com um repositório descartável

Escolha um repositório pequeno no GitHub que possa ser descartado sem preocupação. A meta do primeiro teste é observar o roteamento, o contexto, as branches e o consumo — não confiar uma migração de produção a um coordenador em versão beta.

1. Corrija o acesso ao GitHub antes de criar o projeto

Para trabalhar com código, o repositório precisa estar no github.com. A conta conectada do GitHub deve ter permissão de push, e o Claude GitHub App precisa estar instalado nesse repositório. Um token criado por /web-setup pode permitir que uma sessão comum na nuvem clone o repositório, mas não basta para uma thread do projeto.

GitHub Enterprise Server, GitLab e Bitbucket não são compatíveis como repositórios de código de um projeto nesta versão beta. Se o repositório pertencer a uma organização, talvez um proprietário precise aprovar a instalação do GitHub App e a autorização por SSO.

2. Crie um projeto com escopo restrito

Abra Projects, selecione New project e adicione:

• Nome: algo claramente temporário, como Parser Project Test.
• Objetivo: uma frase, como Improve parser coverage and documentation without changing behavior.
• Contexto: adicione somente o repositório descartável.

Apenas o nome é obrigatório. Um objetivo restrito dá ao coordenador um limite útil, e trabalhar com um único repositório evita as diferenças de configuração que aparecem em projetos com vários repositórios.

3. Adicione uma instrução permanente

Abra Project settings > Memory > Project instructions. Dê a todas as threads o mesmo critério de conclusão e o mesmo limite de aprovação. Por exemplo:

Comece pela branch padrão. Use uma branch por thread. Execute os testes relevantes antes de informar que terminou. Não faça merge, não altere o CI nem adicione dependências sem pedir autorização na thread. Se faltar acesso, diga qual item está ausente e pare.

As instruções do projeto podem ter até 16,000 caracteres, mas vale manter o primeiro teste curto. Comandos de build específicos do repositório continuam pertencendo ao CLAUDE.md desse repositório. Requisitos, decisões e armadilhas que surgirem no projeto devem ficar na memória do projeto.

4. Confira o ambiente na nuvem

Abra Project settings > Environment. Toda nova thread usa o ambiente selecionado aqui. É ele que controla o acesso à rede, as variáveis de ambiente, as credenciais de API e as ferramentas instaladas por um script de configuração.

O ambiente padrão hospedado pela Anthropic acessa uma lista permitida de serviços comuns e traz ferramentas pré-instaladas. Ele não recebe automaticamente seu banco de dados local, VPN, emulador de dispositivo, configuração de shell ou credenciais que só existem no computador. Configure o ambiente antes de atribuir qualquer trabalho que dependa desses recursos.

5. Envie duas tarefas que não possam colidir

Coloque as duas tarefas em uma só mensagem para observar o coordenador separar trabalhos sem relação entre si. Faça com que elas afetem arquivos diferentes. Por exemplo:

Comece agora, sem pedir confirmação. Crie uma thread para adicionar testes unitários de entradas malformadas no parser. Crie uma segunda thread para corrigir exemplos desatualizados no guia da API. Não altere o comportamento do parser em produção e não faça merge de nenhuma das branches.

Segundo a Anthropic, várias tarefas independentes na mesma mensagem se transformam em threads separadas. Cada thread de código cria uma branch a partir da branch padrão do repositório, a menos que você determine outra coisa. Usar arquivos distintos é importante porque branches separadas ainda podem entrar em conflito quando duas threads alteram o mesmo código.

6. Revise as threads, não apenas o resumo do coordenador

Abra o cartão de cada thread e registre:

O Overview organiza o trabalho nos estados Ready for review, Waiting on you, Working, Landing, Idle e Resolved. As outras abas reúnem arquivos do projeto, pull requests e rotinas. O coordenador recebe os relatórios das threads, mas não enxerga cada etapa; por isso, a transcrição da thread continua sendo o lugar certo para auditar o trabalho.

7. Teste se o próximo trabalho recebe o contexto salvo

Quando as duas threads terminarem, peça ao coordenador que memorize uma regra inofensiva, como Documentation changes must preserve every runnable example. Em seguida, abra uma nova e pequena thread de documentação e peça que ela informe as regras de branch e de documentação do projeto antes de editar qualquer coisa.

Esse teste percorre dois caminhos de contexto. As instruções do projeto devem chegar a toda nova thread como um briefing fixo. A memória do projeto deve transportar a decisão salva por meio do MEMORY.md. O CLAUDE.md do repositório continua sendo uma terceira camada separada, destinada às regras próprias daquela base de código.

O que acompanha cada thread e o que fica de fora

O modo mais rápido de interpretar Projects de forma errada é imaginar que uma thread na nuvem seja uma cópia remota do seu computador. Não é. Trata-se de uma sessão nova na nuvem, montada com contextos do projeto, do repositório, da conta e do ambiente.

Projetos com vários repositórios têm uma armadilha importante. Todos os arquivos CLAUDE.md, skills e plugins dos repositórios são carregados, mas isso não vale para regras de permissão, hooks e configurações de env de cada repositório. Coloque as regras compartilhadas entre repositórios nas instruções do projeto e as variáveis de ambiente no ambiente na nuvem.

Threads paralelas não significam threads ilimitadas

A Anthropic não documenta um número fixo de threads que podem rodar ao mesmo tempo. Você pode pedir ao coordenador que execute duas por vez, mas isso funciona como preferência, não como cota obrigatória. O limite rígido, que é separado, fica em 200 novas threads por dia somando seus projetos.

Threads em execução consomem o plano. O coordenador também consome enquanto lê relatórios e decide o que acontece em seguida. Uma thread que monitora um pull request desperta e volta a usar o plano quando o CI falha ou chega um comentário de revisão. Já um projeto ocioso, sem threads em execução, pull requests monitorados ou novas mensagens, não consome nada enquanto permanece parado.

Novos projetos usam, por padrão, o Opus com esforço alto nas threads e esforço baixo no coordenador. Antes de iniciar um lote grande, abra Project settings > General e escolha o modelo e o nível de esforço mais baratos capazes de executar cada tarefa. Depois, solicite um número pequeno de threads simultâneas. A pergunta útil não é quantas threads Projects consegue abrir, e sim quantos resultados você consegue revisar antes que a fila vire ruído.

Os sete casos de uso que mais se beneficiam

1. Liderança de plataforma coordenando uma migração entre repositórios

Conecte os repositórios de servidor, web e mobile e defina para o projeto um único objetivo: aposentar um endpoint obsoleto. Threads separadas podem atualizar cada cliente em branches próprias, enquanto o coordenador acompanha a ordem e os bloqueios. O ganho é ter uma só fila de revisão, em vez de três sessões de agentes sincronizadas manualmente. Esse é o melhor encaixe porque o objetivo dura mais que uma sessão e o trabalho se divide com clareza por repositório.

2. Manutenção alimentando a fila de bugs de um serviço

Quem mantém o serviço pode colar novos relatos de bugs e stack traces no mesmo projeto à medida que chegam. O coordenador pode encaminhar uma regressão à thread que já investiga aquela área ou abrir outra com as armadilhas salvas no projeto. O ganho está em repetir menos briefings e manter um registro duradouro de qual bug aguarda acesso, revisão ou decisão.

3. Responsável por release executando verificações independentes

Distribua entre threads separadas a suíte de testes, os links de documentação, a auditoria de dependências e o rascunho das notas de release. Mantenha cada tarefa em modo somente leitura até revisar as descobertas. O coordenador consegue mostrar o que passou e o que exige uma resposta sem misturar todas as evidências em uma transcrição enorme. O ganho é reduzir o tempo entre o checklist e a decisão, preservando a palavra final de quem responde pela release.

4. Liderança de refatoração dividindo uma grande mudança por fronteiras

Para uma migração maior que uma janela de contexto, atribua módulos ou pacotes independentes a threads separadas e registre a invariante nas instruções do projeto. Cada thread valida a própria branch e envia o resultado. O ganho é avançar em paralelo com um único critério permanente de conclusão. O risco está na sobreposição arquitetural: duas branches que mexem na mesma abstração compartilhada ainda podem provocar conflitos de merge comuns.

5. Engenharia de agência mantendo o aplicativo de um cliente

Crie um projeto privado para o repositório, as instruções e o ambiente de um único cliente. Ao longo do contrato, envie pequenas correções, pedidos de revisão e trabalhos de documentação. O ganho é manter a continuidade sem misturar o contexto de clientes diferentes. Como Projects pertence a um só usuário e não pode ser compartilhado durante a versão beta, ele funciona como uma central pessoal de entrega, não como um portal de colaboração com o cliente.

6. Liderança de engenharia de suporte analisando falhas recorrentes de integração

Projects não exige um repositório. Envie uma exportação dos tickets de suporte e a documentação de integração; depois, encarregue threads de classificar falhas, verificar exemplos e redigir um briefing de correção. Os arquivos produzidos chegam à Library. O ganho é ter um conjunto reutilizável de contexto do projeto e trilhas de evidências separadas para análise e redação.

7. Fundador solo eliminando um backlog variado

Envie um lote pequeno com uma tarefa de testes, uma de documentação e uma auditoria do repositório. Oriente o coordenador a rodar apenas duas threads e a propor qualquer mudança destrutiva antes de executá-la. O ganho é liberar atenção: o fundador revisa branches concluídas em vez de acompanhar cada sessão de perto. O encaixe é ruim quando todas as tarefas precisam do mesmo arquivo ou de um serviço acessível somente pelo computador do fundador.

Três produtos complementares que vale a pena criar

A versão beta não oferece uma API documentada para Projects. Por isso, os produtos mais sensatos no curto prazo ficam ao lado desse fluxo: preparam contexto, inspecionam o estado no GitHub ou ajudam uma pessoa a revisar as entregas.

1. Auditor de prontidão para projetos, a melhor oportunidade

Crie um GitHub App somente leitura que verifique se um repositório está pronto para agentes de programação na nuvem. Ele inspecionaria instruções do repositório, comandos de teste, proteções de branch, cobertura do GitHub App, segredos obrigatórios e dependências de rede; depois, produziria um rascunho de instruções para o projeto e um checklist do ambiente na nuvem.

A demanda por esse trabalho já aparece nas buscas: “ai powered coding agent” recebe 8,100 buscas por mês nos EUA, com intenção comercial. Os planos individuais oficiais de agentes de programação conferidos para este guia custam de $10 a $200 por mês, mas uma licença paga não torna o repositório seguro para trabalho paralelo na nuvem.

A menor versão que pode ser vendida analisa um repositório do GitHub, faz seis perguntas sobre o ambiente e exporta um briefing pronto para colar. A ressalva é o risco de plataforma. A Anthropic ou o GitHub podem incorporar rapidamente as verificações de configuração; por isso, o produto precisa oferecer suporte a vários agentes e um histórico de auditoria útil, não apenas um template específico para Claude.

2. Painel do ciclo de entrega com IA

Crie um painel apoiado no GitHub que agrupe branches, pull requests, status de CI, comentários de revisão e aprovações humanas por objetivo de entrega. Ele atenderia à liderança técnica que usa vários agentes de programação e precisa de um painel neutro de revisão.

“AI software development life cycle” recebe 720 buscas por mês nos EUA, tem dificuldade de palavra-chave 4 e CPC de $18.13. A menor versão lê eventos do GitHub e os converte em quatro estados: em andamento, bloqueado, pronto e entregue. Ela nunca precisa de acesso privado à transcrição de um projeto do Claude.

A ressalva é a diferenciação. O GitHub e os fornecedores de agentes já exibem boa parte desses estados. O produto só vence se conectar o trabalho entre fornecedores, preservar evidências de aprovação e explicar por que uma mudança está bloqueada, em vez de apenas desenhar uma fila mais bonita.

3. Roteador automatizado de políticas de revisão

Crie um GitHub App que aplique políticas de revisão específicas do repositório aos pull requests criados por agentes. Ele poderia exigir um artefato de teste para mudanças no parser, encaminhar alterações de cobrança a uma pessoa responsável e impedir que comentários de correção automática acionem automações privilegiadas.

“Automated code review” recebe 210 buscas por mês nos EUA e tem CPC de $63.33, um sinal forte de que esse público menor possui intenção comercial de alto valor. O MVP precisa de um arquivo de política, uma verificação de pull request e uma explicação compacta das evidências que estão faltando.

A ressalva é a sobreposição. As threads do Claude já monitoram pull requests e reagem a falhas de CI e comentários de revisão. Um produto novo deve governar riscos entre agentes e repositórios, não imitar mais um bot de revisão.

O que Claude Code Projects não resolve

Projects funciona melhor quando o trabalho pode ser dividido e o contexto necessário cabe no GitHub, em arquivos enviados, em conectores ou em um ambiente na nuvem. É a ferramenta errada para uma correção pontual que cabe em uma sessão, para atividades presas a um dispositivo local ou VPN e para equipes em que várias pessoas precisam conduzir o mesmo projeto.

Também não elimina os riscos comuns da entrega:

• Threads separadas podem criar conflitos de merge quando suas branches se sobrepõem.
• Um pedido de simultaneidade é uma instrução para o coordenador, não um controle rígido de orçamento.
• Threads em paralelo podem esgotar rapidamente os limites do Pro.
• Um sandbox pausado pode retomar a partir de um clone novo, e o trabalho sem commit pode ser perdido.
• A versão beta é pessoal, sem compartilhamento de projetos ou controles no nível da organização.
• Uma thread não pode ser movida posteriormente para outro projeto.

A conclusão direta é esta: use Projects para coordenar trabalhos que podem ser separados, não para terceirizar a arquitetura ou a aprovação. Comece com duas tarefas, inspecione as duas transcrições e só aumente a simultaneidade quando as branches e o consumo se mostrarem previsíveis.

Perguntas frequentes

O Claude Code tem acesso a projetos?

Algumas contas Claude Pro e Max selecionadas podem usar a versão beta reformulada de Projects em claude.ai/code, na aba Code do aplicativo para desktop e nos aplicativos móveis do Claude. Se Projects não aparecer na barra lateral de Code, a liberação ainda não chegou àquela conta. O comando de terminal chamado claude project gerencia um estado de diretório local que não tem relação com esse recurso.

Como usar projetos no Claude Code?

Crie um projeto no Claude Code, adicione um objetivo e apenas os repositórios ou arquivos necessários, escreva uma instrução permanente curta, selecione o ambiente na nuvem e envie uma ou mais tarefas à conversa com o coordenador. Antes de fazer qualquer merge, revise cada thread no Overview e inspecione sua branch, transcrição, validação e consumo.

O Claude Code pode trabalhar em um projeto existente?

Sim. Você pode criar um projeto a partir de um repositório existente no github.com ou selecionar Continue as a project em uma sessão existente na nuvem. Repositórios de código exigem acesso de push pela conta conectada do GitHub e a instalação do Claude GitHub App.

Quais são as principais diferenças entre Claude Projects e Claude Code?

Claude Code é o agente de programação executado em uma sessão local ou na nuvem. Um projeto reformulado do Claude Code é a camada de coordenação: uma conversa inicia e acompanha várias sessões do Claude Code na nuvem, fornece a elas o contexto compartilhado do projeto e reúne seus status. Até a migração chegar, o Projects antigo no chat do Claude e no Cowork continua funcionando como um workspace de arquivos e conversas.

Se você quer um fluxo de agentes pronto para projetos, estruturado em torno dos seus repositórios, aprovações e ambiente na nuvem, conheça os sistemas de produção com IA.