O capítulo 1 tratou do modelo mental. Este capítulo trata de colocar a mão na massa. O objetivo é um só: fazer a sua primeira instrução passar, no seu próprio repositório.
Os comandos que você vai digitar cabem em poucas linhas. O resto do tempo vai para entender o que você está aprovando. Se pular isso, vai voltar aqui mais tarde.
São cinco portas de entrada — escolha a sua
O Claude Code costuma ser apresentado como "uma ferramenta de terminal", mas há cinco portas de entrada. O que está por dentro é o mesmo. Muda só a embalagem.
A coisa em si. Digite claude e pronto. É o que este curso assume.
Fica dentro do editor. Você lê os diffs na visualização que já conhece.
Entra na família IntelliJ. Se você desenvolve ali, não precisa sair.
Use sem abrir um terminal. O modo se escolhe no seletor ao lado do campo de entrada.
Acessível mesmo sem ambiente de desenvolvimento à mão. A troca de modo é no mesmo seletor.
Na primeira hora, use o terminal. Não por ser mais confortável, e sim porque ele conta mais coisas. Quando algo emperra, você vê a mensagem crua, e as soluções que as pessoas registram partem do terminal. Sobre como o Claude Code se posiciona ao lado das ferramentas embutidas no editor, como Cursor ou GitHub Copilot, veja o capítulo 1 do curso de coding com IA.
Instalar
O caminho padrão é o npm. Com o Node.js já instalado, uma linha resolve (se node -v imprimir uma versão, está pronto). O -g quer dizer "instale de um jeito que dê para chamar de qualquer pasta".
npm install -g @anthropic-ai/claude-code
claude
Onde um proxy ou uma restrição regional bloqueia o npm, dá para instalar por um gerenciador de pacotes.
brew install --cask claude-code # macOS / Homebrew
winget install Anthropic.ClaudeCode # Windows / WinGet
Fique com um único método de instalação. Instale pelo npm e depois de novo pelo Homebrew e aparece Multiple claude installations found. Não saber qual delas está rodando torna todo o diagnóstico daqui em diante mais difícil. Os requisitos variam conforme o ambiente, então, na dúvida, vá à documentação oficial.
Fazer login — conta ou chave de API
Na primeira execução você escolhe como entrar. Com uma conta Claude, o navegador abre e, assim que você entra e concede o acesso, está autenticado. O que você gasta é a cota do seu plano, e ela aparece na forma de limites e horários de reinício. Uma chave de API funciona com saldo em vez de cota, e para quando o saldo acaba. Uso pessoal aponta para a primeira; CI e automação, para a segunda.
Qual das duas está disponível para você depende do seu contrato, então isto não é uma regra. Há só uma coisa para guardar.
Uma chave de API no seu ambiente tem prioridade sobre o login da assinatura. Se você um dia colocou ANTHROPIC_API_KEY na configuração do shell para testar e esqueceu, o seu login correto passa a ser ignorado em favor daquela chave. A maioria dos relatos do tipo "pago um plano e ele diz que meu saldo acabou" é isso.
Com quais credenciais você está rodando agora é o que o /status responde. Olhe antes de desconfiar.
/status # com quais credenciais estou rodando
env | grep ANTHROPIC # ainda há uma chave no meu ambiente?
unset ANTHROPIC_API_KEY # se houver, tire. remova do arquivo de config também
/login # entre de novo e confirme com /status
O que acontece na primeira execução
Depois de autenticado, entre primeiro na pasta em que você quer trabalhar e só então inicie. O Claude Code trata "a pasta em que você está" como alvo, então, se errar, ele começa a ler um lugar que não tem nada a ver.
cd my-project
claude
O prompt esperando entrada é a porta da conversa. Aqui, não peça uma reescrita de cara. Faça do seu primeiro movimento um pedido que termina só em leitura: "Leia o README e os diretórios principais e explique o que este projeto faz".
São três motivos. Leitura não pede confirmação nem no modo padrão, então o pedido passa antes de você conhecer a etiqueta da aprovação. Você já conhece este projeto, então consegue corrigir a resposta. E isso testa a conexão, a autenticação e a pasta de trabalho de uma vez só, sem quebrar nada. Se algo parecer estranho, dá para resolver antes de partir para as escritas.
O loop instruir → diff → aprovar
Assim que a leitura funcionar, peça uma reescrita pequena. Daqui em diante são sempre os mesmos quatro tempos.
Diga em português mesmo. Se souber dizer onde corrigir, diga.
Ele acha e lê os arquivos que parecem relacionados. É o STEP 1 do capítulo 1.
"Vou mudar isto aqui" sai linha a linha, e ele para nesse ponto.
Deixe passar e a mudança entra. Se estiver errada, recuse e coloque a diferença em palavras.
Você: "Acrescente uma seção de Windows no README"
↓
[BUSCAR] procurar o README ← leitura. não para
↓
[LER] ler README.md ← leitura. não para
↓
[EDITAR] adicionar 3 linhas ao README ← aparece um diff, e ele para
↓
Você: aprovar / recusar e dizer o que mudar
Recusar não é fracasso. Como você consegue ser específico depois de ver o diff, não precisa mirar em uma primeira instrução perfeita. É justamente isso que faz esse formato ser bom.
Mantenha cada pedido no tamanho de "um diff que você consegue ler até o fim". Quanto maior o pedido, mais longo o diff, e diffs longos são aprovados sem leitura. Uma aprovação que você apertou sem ler não é aprovação, é aprovação automática. Como dividir o trabalho está no capítulo 3.
Em qual modo começar
Quem decide onde ele para é o modo de permissão. No terminal você alterna com Shift+Tab; no VS Code, no aplicativo de desktop e no navegador, com o seletor ao lado do campo de entrada.
As leituras são automáticas. Edições e comandos são confirmados toda vez. Use este no primeiro dia.
As edições dentro da pasta de trabalho passam automaticamente. Para quem lê os diffs todos juntos depois.
Ele investiga, mas não edita o código-fonte. Aprove o plano e ele passa a executar.
Um modelo avaliador separado barra só as operações perigosas e deixa o resto correr sem confirmação. Há condições.
Confirmações e verificações de segurança ficam ambas desligadas. Só em ambientes isolados. Não é coisa para mexer no primeiro dia.
O que o Shift+Tab percorre são os três primeiros. O modo automático entra no ciclo quando as condições são atendidas, e na primeira vez aparece uma confirmação de adesão. Ignorar permissões só fica ativo quando você inicia com a flag específica dele. Para fixar um modo desde o início, passe claude --permission-mode plan. Existe ainda o dontAsk, que nunca aparece no seletor: ele executa apenas o que você já permitiu, e existe só nas configurações e na CLI.
A resposta para o primeiro dia é "deixe no padrão". Cada confirmação é treino para distinguir uma leitura de uma escrita de uma execução. Afrouxe depois de conseguir distinguir; ao contrário, você afrouxa alguma coisa sem saber o quê. O segundo modo a buscar é o modo de planejamento.
Alguns lugares seguem protegidos em todos os modos. Escritas em caminhos sensíveis como .git, .claude e arquivos de configuração do shell nunca são aprovadas automaticamente em nenhum modo, exceto ignorar permissões. Afrouxar uma coisa não afrouxa tudo.
Os modos estão detalhados no artigo sobre os modos de permissão, e escrever regras de permitir e negar por ferramenta está no artigo sobre regras de permissão e o settings.json. E note que o bypass não é a resposta para "as confirmações são chatas". Ele não defende nem contra um deslize seu nem contra uma instrução plantada em algo que ele leu. Para reduzir os avisos, comece escrevendo regras que permitem só as operações em que você confia. Esse trabalho de desenho é o capítulo 5.
CLAUDE.md — pare de se repetir
Dois dias de uso e você percebe que está dando os mesmos avisos toda hora. "Não mexa nesta pasta". "Rode o lint antes de commitar". Digitar isso a cada vez desperdiça o seu tempo e o seu contexto. Então coloque um CLAUDE.md na raiz do projeto. O Claude Code lê esse arquivo automaticamente ao iniciar e trabalha com base no que está escrito ali.
# Este projeto
- TypeScript / Next.js. O gerenciador de pacotes é o npm
- Respostas e comentários no código em português
## Não mexer
- Nada dentro de src/legacy/ (é de outro time)
- .env e tudo que deriva dele
## Verificação
- Depois de uma mudança, rode npm run lint e npm test
- Não diga que terminou enquanto houver erros de tipo
O que entra é decidido por "coisas que a IA não tem como saber".
Qual comando prova que funciona. É a entrada de maior valor, porque é ela que viabiliza o STEP 3 do capítulo 1.
Saída gerada, território de outros times, arquivos que guardam segredos. Mais as convenções que o código não revela, tipo "páginas novas vão aqui".
Coisas como "escreva código legível". Ninguém consegue julgar se foi cumprido, e isso só dilui as linhas que você realmente quer que sejam obedecidas.
Como fazer o arquivo crescer também já está resolvido. Comece com poucas linhas. Deu o mesmo aviso duas vezes, acrescente uma linha. Se tentar ser exaustivo, acaba com um arquivo longo e vago que ninguém segue. Quando um arquivo "não está sendo seguido", a causa costuma ser uma de três: coisa demais, abstrato demais ou contraditório.
Regras de permissão e escolha de modelo podem morar separadas em .claude/settings.json (projeto) e ~/.claude/settings.json (pessoal), mas algumas linhas de CLAUDE.md bastam de sobra para o primeiro dia. Escolher entre eles é o capítulo 6.
As três coisas que mais quebram no primeiro dia
As pessoas travam de maneiras previsíveis, e no primeiro dia é quase sempre uma destas três.
Está instalado, mas não em um lugar de onde dá para chamar. Acrescente ~/.local/bin (no Windows, %USERPROFILE%\.local\bin) ao seu PATH. Uma instalação duplicada também pode causar isso.
O clássico: uma ANTHROPIC_API_KEY antiga sobrepondo a assinatura. Confira com /status e então limpe a variável de ambiente e entre de novo.
O Claude Code queima de 10 a 100 vezes os tokens de um chat. Os vaivéns e as leituras de arquivo se acumulam.
O terceiro item costuma ser mal interpretado. Uma mensagem no sentido de "o servidor está limitando requisições temporariamente" é uma limitação temporária do lado do servidor, não a cota do seu plano, e passa depois de uma espera curta. Se você bateu mesmo na cota é o /usage que diferencia.
claude doctor # checagem geral de instalação, configuração, MCP e contexto
/status # com quais credenciais estou rodando
/context # o detalhamento do que está comendo o contexto
claude update # na dúvida, vá para a versão mais recente (resolve muita coisa)
Esse claude update do fim ganha o lugar dele em silêncio. Uma boa quantidade de falhas simplesmente desaparece ao subir de versão, então rodá-lo antes de começar a investigar poupa você de perseguir um problema que já não existe. As correções sintoma a sintoma estão no artigo sobre erros comuns e como resolver. O procedimento de diagnóstico é o capítulo 4.
Resumo
- Cinco portas de entrada. O que está por dentro é o mesmo, mas na primeira hora o terminal ganha pelo tanto que ele conta
- A instalação padrão é
npm install -g @anthropic-ai/claude-code. Se falhar, Homebrew ou WinGet. Fique com um único método - Entre com uma conta (cota) ou uma chave de API (saldo). Uma chave no ambiente sobrepõe a assinatura: na dúvida,
/status - Faça do seu primeiro movimento um pedido só de leitura. Ele testa a conexão, a autenticação e a pasta de trabalho de uma vez, e não quebra nada
- O ciclo é instruir → diff → aprovar. Divida os pedidos até chegar a um diff que você consegue ler até o fim. Aprovação sem leitura é aprovação automática
- O modo do primeiro dia é o padrão (pedir permissão), o segundo é o modo de planejamento. Caminhos protegidos como
.gitse mantêm em todos os modos, exceto o bypass - Comece o
CLAUDE.mdna raiz com poucas linhas. Escreva como verificar, o que não tocar e as convenções da casa, e deixe os lugares-comuns de fora - Os travamentos do primeiro dia são PATH, uma chave no ambiente e uso. Primeiros movimentos:
claude doctor//status//context
Com a primeira instrução aprovada, o próximo trabalho é encaixar isso no dia a dia. Siga para o capítulo 3, "O fluxo do dia a dia".