Claude Code no terminal: 7 upgrades de workflow para power users

O Claude Code "vanilla" já é útil logo de cara. Você instala, dá um prompt e ele constrói o que você precisa. Esse é o setup de vibe-coding da maioria das pessoas — e funciona.

A versão do Claude Code usada por quem personalizou o terminal é outra história. Essa pessoa já pré-aprovou os comandos bash em que confia, então o Claude quase nunca pede permissoão. Um CLAUDE.md fica na raiz do projeto, então o Claude já conhece as convenções assim que a sessão abre. E quando a sessão começa a se confundir, o comando que ela usa não é reiniciar.

Este artigo fecha a lacuna entre esses dois setups do Claude Code — em sete upgrades. Nenhum leva mais de dez minutos para configurar, e cada um se paga em menos de uma semana.

Se você nunca abriu o Claude Code, nosso guia principal do Claude Code é um ponto de partida melhor. Tudo abaixo assume que você já sabe dar prompts e aceitar chamadas de ferramentas.

1. pare de reaprovar os mesmos comandos

Por padrão, toda nova invocação de ferramenta pede sua aprovação. Beleza na primeira vez que você roda pytest. Chato na terceira. Na décima, você está martelando Enter sem nem ler o prompt. É o pior dos dois mundos: você se treinou a ignorar a verificação de segurança e ainda está perdendo tempo com ela.

Claro, existe o modo "dangerously bypass permissions" ou modo "auto". Falamos bastante sobre os trade-offs no meu tutorial sobre Auto Mode e Channels no Claude Code.

Definindo permissões no arquivo settings.json

A solução é um arquivo .claude/settings.json na raiz do projeto, com um bloco permissions que pré-aprova os padrões em que você confia e bloqueia os que não confia:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

As regras são avaliadas numa ordem fixa: primeiro deny, depois ask, depois allow. A primeira correspondência vence, então uma regra de deny sempre supera um allow posterior.

Dominando escopo e curingas

Três coisas costumam derrubar quem escreve isso pela primeira vez.

1. A primeira é escopo. Um .claude/settings.json do projeto sobrescreve seu ~/.claude/settings.json global. Então, se você permitiu Bash(rm *) globalmente e o projeto nega, o projeto vence. É o padrão certo, mas surpreende quem espera que os allows globais sejam "grudados".

2. A segunda são curingas em comandos de rede. Bash(curl http://github.com/ *) parece restritivo, mas não pega https://, opções antes da URL, redirects ou expansão de variáveis do shell. O padrão recomendado na documentação é negar Bash(curl *) por completo. Depois, use a ferramenta WebFetch com WebFetch(domain:github.com) para os domínios que você realmente quer permitir.

3. A terceira é espaço em branco. Bash(ls *) combina com ls -la mas não com lsof. Bash(ls*) pega os dois. O espaço antes do asterisco faz diferença, então vale ser intencional.

Alguns atalhos vivem ao lado das permissões nessa categoria de "pare de brigar com o terminal" e valem ser decorados no dia um:

• Shift+Tab alterna os modos de permissão (padrão, auto-aceitar, plano)

• Esc+Esc abre o seletor de rewind (mais sobre isso no #3)

• Ctrl+R faz busca reversa no histórico de prompts, como no bash e zsh

• Ctrl+U apaga do cursor até o início da linha

• Shift+Enter insere uma nova linha dentro do prompt

A maioria desses atalhos funciona nativamente nos terminais. Se não funcionar, rode o slash command /terminal-setup uma vez para instalar tudo.

2. faça o Claude Code lembrar do seu projeto

Cada sessão começa com uma janela de contexto limpa.

Por padrão, o Claude não lembra que você usa uv em vez de pip. Não lembra que seus testes vivem em tests/ e não em test/. E as convenções de API que você explicou em dez interações ontem também somem. A solução é um arquivo CLAUDE.md na raiz do projeto. Inicie o Claude Code a partir dessa pasta (ou de qualquer subpasta) e o arquivo é carregado no contexto automaticamente antes do seu primeiro prompt.

O jeito mais rápido de começar é /init. Rode dentro do projeto. O Claude lê a base de código e escreve um CLAUDE.md inicial com comandos de build, instruções de teste e convenções que ele conseguir inferir. Você vai editar depois, já que o /init entrega um baseline funcional — não um arquivo final.

Há três lugares onde o Claude busca contexto, empilhados um sobre o outro:

CLAUDE.md do projeto em ./CLAUDE.md vai junto no repositório. É igual para todos os contribuidores, então coloque aqui os fatos específicos do projeto:

• O gerenciador de pacotes e a versão da linguagem
• O comando de teste e onde os testes vivem
• O layout de diretórios e convenções não óbvias
• Qualquer coisa que um novo colega precisaria saber no primeiro dia

CLAUDE.md do usuário em ~/.claude/CLAUDE.md acompanha você em todos os projetos da sua máquina. É onde entram preferências pessoais: seu estilo de código, como você gosta de docstrings, as linguagens que você prefere. Não coloque fatos do projeto aqui, ou eles vão "vazar" para todo repo que você abrir.

Auto-memory é a terceira camada, e o próprio Claude escreve. Quando você o corrige durante a sessão ("aqui usamos snake_case, não camelCase"), ele registra a correção em ~/.claude/projects/<project>/memory/MEMORY.md. As primeiras 200 linhas ou 25 KB desse arquivo são carregadas no início de toda conversa no mesmo projeto. Você pode ver o que foi carregado com /memory — também dá para ligar ou desligar o auto-memory.

Uma regra de tamanho: mantenha cada CLAUDE.md com menos de 200 linhas. Passou disso, o arquivo começa a consumir contexto perceptível a cada turno, e o Claude segue arquivos longos com menos confiabilidade que os curtos. Se o seu estiver passando, divida em .claude/rules/ com escopos de caminho. Para ver o que realmente vale colocar em um CLAUDE.md, confira meu guia sobre como escrever o melhor CLAUDE.md.

3. pare de reiniciar sessões quando algo desandar

O instinto, quando uma sessão sai do trilho, é dar /clear e começar do zero. Na maioria das vezes, é o instinto errado. Reiniciar joga fora os caminhos de arquivo que o Claude estava editando, o teste que estava falhando ou as restrições que você definiu no começo. Uma sessão nova precisa reaprender tudo isso — e você paga esse reaprendizado em tokens e tempo.

O primeiro passo é reconhecer o sintoma. "Apodrecimento" de contexto tem alguns sinais claros:

• O Claude volta a pedir um caminho de arquivo que editou cinco interações atrás
• Repete uma sugestão que você já rejeitou
• Perde a noção de qual branch você está
• Você já o corrigiu duas vezes ou mais no mesmo ponto na mesma sessão

Quando perceber isso, você tem quatro opções — e elas não são intercambiáveis:

Compactando sua sessão

O /compact não é tão ruim quanto alguns usuários dizem.

Seu CLAUDE.md do projeto sobrevive a ele. O Claude relê o arquivo do disco após a compactação e o reinsere, então suas convenções não se perdem. Você também pode passar instruções de foco para guiar o resumo, como /compact keep the auth refactor decisions, drop the failed test runs. Essa é a diferença entre um resumo útil e um genérico.

Usando o "desfazer" do Claude Code

O seletor de rewind com Esc+Esc é o que a maioria não sabe que existe. Ele abre uma lista de todos os checkpoints de prompt da sessão. Ao escolher um, aparecem três opções: restaurar só a conversa, só o código ou ambos.

"Restaurar código e conversa" é o que a maioria precisa. Meia hora de turnos ruins some sem você abrir o git. É o mais perto que o Claude Code tem de um "desfazer" da sessão inteira.

Depois que você para de reiniciar, o próximo problema é encontrar as sessões de novo.

Nomeando e reabrindo sessões

claude -n <name> (ou --name) inicia uma sessão nomeada, e o nome aparece em /resume e no título do terminal. Quando você tem três frentes no mesmo repo (branch de experimento, refactor, debug), os nomes diferenciam cada uma. /rename troca o nome no meio da sessão se o escopo mudar.

Dica: use /color para distinguir ainda mais as sessões quando rodar várias na mesma janela do terminal.

Para reabrir uma sessão, há duas flags. claude --continue (ou -c) carrega a conversa mais recente no diretório atual. Use quando você já estava aqui e quer retomar.

claude --resume abre um seletor interativo, e claude --resume <name-or-id> pula direto para uma sessão específica. Trate sessões como branches do git: fluxos de trabalho diferentes merecem as suas próprias.

4. planeje o difícil, economize no fácil

O maior custo num setup personalizado não é o editor nem os atalhos. É ajustar o compute ao nível de dificuldade da tarefa. Três ferramentas trabalham juntas nisso: modo de plano, /effort e /model.

Usando o plan mode do Claude Code

O plan mode faz o Claude pensar na abordagem antes de tocar nos arquivos. Ele escreve o plano, você revisa, aprova ou ajusta, e só então ele executa.

Um truque simples que uso para deixar os planos à prova de falhas é este prompt:

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Isso lança vários subagentes para revisar o plano por diferentes ângulos e sugerir correções. É uma boa prática quando o arquivo de plano passa de 500 linhas.

O custo é que planejar + red-teaming adiciona dois turnos antes de qualquer código chegar, então para algo menor que um feature ou bug fix relevante, vira exagero.

Há cinco formas de entrar no plan mode:

O formulário inline (/plan refactor the auth module to use JWT) é o que muita gente não percebe. Ele define o modo e a tarefa num único passo. Para um passo a passo completo de workflows de revisão-primeiro, meu tutorial de plan mode do Claude Code vai a fondo.

Definindo o nível de esforço adequado

Effort é o próximo conceito. Ele controla quanto raciocínio estendido o Claude faz a cada turno. Effort mais alto = raciocínio mais profundo, mais tokens, resposta mais lenta.

/effort <level> e a flag --effort <level> na CLI aceitam todos os cinco valores. Low, medium, high e xhigh persistem entre sessões. Max é só para a sessão atual porque remove o limite de gasto de tokens — você define conscientemente cada vez. O padrão certo para o dia a dia é low ou medium. Guarde high ou xhigh para problemas realmente difíceis e max para momentos em que é melhor queimar tokens do que errar.

Um contraponto: um modelo em low com ótimo contexto muitas vezes supera o mesmo modelo em max com contexto ruim. Lapidar seu prompt costuma dar mais resultado do que aumentar o effort.

Escolhendo o modelo certo

A escolha do modelo é onde a economia real acontece. /model permite trocar no meio da sessão, e Option+P (macOS) / Alt+P (Win/Linux) troca sem apagar o que você já digitou. Aliases que valem conhecer:

• sonnet é o padrão para o dia a dia

• opus é para os problemas mais difíceis (o alias best também aponta para opus)

• haiku é quando você quer velocidade

• sonnet[1m] e opus[1m] são as variantes com contexto de 1M

• opusplan roda Opus no planejamento e Sonnet na execução

• default remove qualquer override e volta ao modelo recomendado

Se você usa Opus para tudo por padrão, mudar para Sonnet na maior parte do dia é o maior corte de gasto que você pode fazer.

Opus é a escolha certa quando você travou em algo difícil e quer o modelo mais potente nisso. Sonnet dá conta de quase todo o resto. A diferença de custo é grande o suficiente para que "vou de Opus para garantir" seja o hábito mais caro para deixar no piloto automático.

5. automatize o que você ainda faz à mão

Depois que a fricção vai embora, o próximo passo é automatizar o trabalho que ainda sobra para você.

Tarefas agendadas

É mais fácil do que descobrir como não fazer. Dois recursos cobrem boa parte: /loop para verificações recorrentes que você cuidaria manualmente, e hooks para garantias que um CLAUDE.md não assegura.

/loop reexecuta um prompt ou slash command em um agendamento recorrente. A sintaxe tem dois formatos:

• /loop 5m <prompt> roda o prompt a cada 5 minutos

• /loop <prompt> sozinho delega a cadência ao modelo, que decide quando rodar de novo

As unidades são s, m, h e d, com mínimo de um minuto. É preciso o Claude Code v2.1.72 ou superior.

Por exemplo, dá para configurar um watcher de testes: /loop 2m run the test suite and report failures. Em vez de lembrar de rodar testes após cada mudança (e esquecer metade das vezes), o Claude pega um teste quebrado no próximo tic de 2 minutos.

O mesmo padrão funciona para checar o deploy de staging (/loop 10m check if the staging deploy is green) ou dar tail nos logs durante um incidente intermitente (/loop 1m tail the last 50 lines of app.log and flag errors).

Loops vivem por 7 dias.

A tarefa roda uma última vez no sétimo dia e se apaga. Eles são escopo da sessão, então --continue ou --resume os traz de volta se você fechar e reabrir. Para parar um loop antes, pressione Esc. Se você precisa de agendamento que sobreviva ao fechamento (checagem noturna, resumo semanal), use Routines via /schedule.

Hooks

Hooks são a outra metade. Eles rodam comandos de shell em pontos específicos do fluxo do Claude, configurados em .claude/settings.json.

A razão para usar um hook em vez de uma instrução no CLAUDE.md é simples: CLAUDE.md é sugestivo, hooks são garantidos. O caso clássico é o "sempre rode o linter após editar" que o Claude pula às vezes. Um hook fecha essa lacuna.

Seis eventos cobrem a maioria dos casos:

Um hook PostToolUse mínimo que roda o linter após cada edição de arquivo:

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Um detalhe importante: só o código de saída 2 realmente bloqueia o Claude. Exit 1 é tratado como erro não bloqueante, e o Claude segue adiante — mesmo 1 sendo o código padrão de falha no Unix. Se seu hook precisa fazer cumprir uma regra, retorne 2.

E você não precisa escrever hooks na unha.

Peça ao Claude: "write a hook that runs ruff after every file edit" e ele redige o JSON para você. /hooks lista toda a configuração ativa de hooks, então você não precisa dar grep nos arquivos de configuração quando algo dispara do nada. Para o catálogo completo de eventos e os schemas JSON de stdin/stdout, confira meu tutorial de hooks do Claude Code.

6. fique de olho no custo de tudo isso

Loops, sessões longas e Opus como padrão queimam tokens. Três comandos deixam o gasto visível o suficiente para você gerenciar — e o hábito certo é só dar uma olhada neles, não ficar configurando.

/usage mostra seu plano, totais da sessão, custos por modelo e barras de progresso para as janelas de limite de taxa de 5 horas e semanal.

/context visualiza a janela de contexto atual como uma grade colorida, com alertas de capacidade e sugestões do que está ocupando espaço. Use quando a sessão parecer pesada e você estiver decidindo entre /compact e /clear.

/statusline configura uma barra persistente no rodapé do seu terminal. Ela pode mostrar o modelo, porcentagem de contexto, janelas de rate limit e qualquer outra coisa que dê para ler do JSON da sessão. É a que mais muda o comportamento, porque coloca números de custo na sua visão periférica enquanto você trabalha.

Você pode rodar /statusline e descrever em linguagem natural o que quer ver, e o Claude gera o script e atualiza as configs. A outra opção é escrever um shell script e apontar para ele em ~/.claude/settings.json:

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Para acompanhamento de longo prazo entre sessões, npx ccusage é uma ferramenta da comunidade que agrega o consumo de tokens ao longo do tempo. É de terceiros, não feita pela Anthropic, mas cobre a lacuna entre o /usage (escopo da sessão) e sua fatura mensal.

7. três recursos a mais que valem conhecer

Os seis upgrades acima são os que eu uso todo dia. Os três abaixo são recursos reais que uso com menos frequência, mas que você deve conhecer — para sacar na hora que precisar.

Usando push-to-talk com /voice

/voice ativa a ditado por push-to-talk. Segure Space, fale, solte — e o texto transcrito cai no seu prompt. É preciso a v2.1.69 ou superior, e 20 idiomas são suportados.

Voz ganha de digitação quando você está andando e pensando em voz alta ou ditando a intenção no começo de uma tarefa, antes de definir a redação. É pior para edições linha a linha, onde "mude a linha 47 para..." é mais fácil digitar.

Puxando sessões da nuvem com /teleport

/teleport (alias /tp) traz uma sessão da nuvem para o seu terminal local. Digamos que você começou uma tarefa longa no app web ou iOS e agora está de volta ao laptop. Rode claude --teleport para abrir um seletor e trazer a sessão para o terminal já com a branch certa feita checkout.

Alguns requisitos precisam alinhar:

• Estado limpo no git
• O repositório correto
• A mesma conta do claude.ai que rodou a sessão na nuvem
• A branch foi enviada para o remoto

Não confunda --teleport com --resume. O segundo só reabre sessões locais do histórico desta máquina. Para um passo a passo completo, nosso tutorial de controle remoto do Claude Code cobre o resto.

Fazendo perguntas paralelas com /btw

/btw serve para aquela pergunta rápida que você quer fazer sem quebrar o fluxo.

Imagine o Claude no meio de uma tarefa. Você já iniciou uma edição longa ou uma chamada de ferramenta e de repente precisa saber a regex para IPs ou qual flag faz X.

Basta digitar /btw <question>, e a resposta aparece em um overlay que você pode dispensar. A tarefa em andamento continua, e a resposta não entra no histórico da conversa — você não precisa abrir uma nova sessão para uma consulta pontual nem poluir a sessão atual.

conclusão

A forma mais rápida de desistir de tudo deste artigo é tentar tudo no mesmo dia. Escolha dois ou três, crie memória muscular para eles e adicione o resto quando o primeiro conjunto estiver automático.

Três para começar — cada um para um momento diferente do dia, sem um atropelar o outro:

• Um CLAUDE.md enxuto do projeto mais duas ou três regras de curingas em .claude/settings.json para os comandos bash que você reaprova toda sessão. Esse é o hábito do setup da manhã — você só percebe quando as interrupções somem.

• A decisão entre /compact e /clear e o seletor de rewind com Esc+Esc. Esse é o hábito do meio da sessão — o gatilho é a hora em que o Claude volta a pedir um caminho de arquivo que ele sabia há uma hora.

• Um /loop para uma verificação recorrente que já te toma tempo. Esse é o hábito de fundo — e, quando está rodando, se paga sozinho.

Se a diferença entre Sonnet, Opus e Haiku ainda estiver meio nebulosa, nosso curso Introduction to Claude Models explica quando usar cada modelo. Isso deixa os comandos /effort e /model muito mais fáceis.