Meu setup Cursor + Claude Code em 2026 (o que uso de verdade)

Eu uso o Cursor como editor principal e o Claude Code no terminal para tarefas longas e repetitivas, e a regra que separa os dois é simples: se eu preciso ver e guiar a mudança, fico no Cursor; se eu consigo descrever o resultado e verificar no final, mando para o Claude Code. Neste post eu mostro o setup que uso de verdade no dia a dia, sem lista de “50 extensões obrigatórias”: configurações, rules, skills, escolha de modelo, cuidados de privacidade e os erros que eu mesmo cometi até chegar aqui.

Não é um guia definitivo. É o que funciona para mim, como desenvolvedor de software trabalhando em projetos web e back-end. Copie o que fizer sentido e descarte o resto.

Por que eu uso os dois (e não só um)

Durante um tempo eu tentei escolher um lado. Não funcionou. As duas ferramentas resolvem problemas parecidos, mas com ergonomias diferentes:

Cursor é ótimo quando eu estou com o código aberto, lendo, ajustando e quero sugestões no contexto do arquivo. O autocomplete, o chat com seleção de trecho e o diff visual de cada edição me deixam no controle.
Claude Code brilha quando a tarefa é “faça X em vários arquivos, rode os testes e me avise”. Ele roda no terminal, executa comandos, lê a saída e itera. Eu posso deixar rodando em outra aba enquanto reviso outra coisa.

O ponto não é qual é “melhor”. É qual dá menos atrito para a tarefa da vez.

Configurações do Cursor que eu mudo logo de cara

Quando instalo o Cursor numa máquina nova, eu passo por estes pontos antes de escrever qualquer linha:

Privacy Mode ligado. Fica nas configurações gerais do Cursor. Com ele ativo, o código não é usado para treino nem guardado pelos provedores além do necessário para responder. Para projeto de cliente, isso não é opcional.
Arquivo .cursorignore na raiz do projeto, excluindo .env, dumps de banco, chaves e pastas de build. Mais sobre isso na seção de privacidade.
Indexação do código ativada só em projetos onde faz sentido. Em monorepo gigante, eu limito o que entra no índice para o agente não se perder em código legado que ninguém toca.
Auto-run de comandos no modo agente: desligado ou com allowlist. Eu deixo o agente rodar npm test, git status e git diff sem pedir. Qualquer coisa que instala pacote, apaga arquivo ou faz push precisa da minha confirmação.

Screenshot descrito: na tela de configurações do Cursor, a aba de privacidade aparece com o toggle “Privacy Mode” ligado e, logo abaixo, a seção de indexação mostrando o caminho do projeto e o número de arquivos indexados. É a primeira tela que eu abro.

Rules: o que eu coloco (e o que eu parei de colocar)

Rules são instruções persistentes que o Cursor injeta no contexto do agente. Eu uso rules de projeto em .cursor/rules/, versionadas no Git junto com o código. Assim, qualquer pessoa do time (e qualquer agente) recebe as mesmas instruções.

No começo eu escrevia rules enormes, com tudo que eu achava importante. O resultado era o agente ignorando metade. Hoje eu sigo três princípios:

Curtas e específicas. “Use Zod para validar input de rotas da API” funciona. “Escreva código limpo” não muda nada.
Escopo por pasta. Regras de front-end só carregam quando o agente mexe em arquivos de front-end.
Só o que o agente erra de verdade. Se ele já faz certo sozinho, a regra é ruído.

Um exemplo real de rule que eu uso num projeto Node com TypeScript:

---
description: Padrões para rotas da API
globs: src/api/**/*.ts
alwaysApply: false
---

- Toda rota valida o body com Zod antes de qualquer lógica.
- Erros de negócio usam a classe AppError (src/lib/errors.ts). Nunca lance Error genérico.
- Não acesse o banco direto na rota: chame o service correspondente em src/services/.
- Toda rota nova precisa de teste em tests/api/ cobrindo caso feliz e input inválido.
- Não adicione dependências novas sem perguntar.

Também mantenho um AGENTS.md na raiz com o básico do projeto: como rodar, como testar, estrutura de pastas. O Cursor lê esse arquivo, e outras ferramentas de agente também, então eu não preciso duplicar a mesma informação em três lugares.

Skills: para tarefas que se repetem

Rules dizem como escrever código. Skills dizem como executar um procedimento. Eu uso skills para coisas que faço toda semana e que têm passos fixos, por exemplo:

Criar uma migration nova seguindo o padrão do projeto e rodar contra o banco local.
Preparar um release: atualizar changelog, conferir versão, rodar a suíte completa.
Investigar um erro do Sentry: pegar o stack trace, achar o commit que mexeu naquele trecho, propor correção com teste.

Uma skill é basicamente um arquivo SKILL.md numa pasta, com um nome, uma descrição de quando usar e os passos. Um esqueleto do que eu uso:

---
name: nova-migration
description: Use quando precisar criar ou alterar tabela no banco.
---

1. Gere o arquivo com `npm run db:migration:new -- nome_descritivo`.
2. Escreva o `up` e o `down`. O `down` precisa desfazer o `up` por completo.
3. Rode `npm run db:migrate` e depois `npm run db:rollback` para provar que o down funciona.
4. Rode `npm run db:migrate` de novo e os testes de repositório.
5. Me mostre o SQL gerado antes de qualquer commit.

O passo 5 é o que mais me salvou. Eu sempre quero ver o SQL antes de virar commit.

Claude Code CLI vs. chat do Cursor: como eu decido

Essa é a pergunta que mais recebo. Minha regra prática:

Vou para o chat/agente do Cursor quando

Estou explorando código que não conheço e quero perguntar sobre trechos específicos.
A mudança é pequena ou média e eu quero aprovar cada edição no diff.
O trabalho é muito visual (componente de UI, CSS) e eu vou ajustar junto.
Preciso de autocomplete enquanto escrevo eu mesmo.

Vou para o Claude Code quando

A tarefa tem um critério de pronto claro: “os testes passam”, “o lint passa”, “a build sai”.
É refatoração mecânica em muitos arquivos (renomear, trocar uma API depreciada, migrar padrão de import).
Quero rodar algo em modo não interativo, num script ou em CI, com claude -p "...".
Preciso que ele rode comandos, leia a saída e tente de novo várias vezes.

No Claude Code eu mantenho um CLAUDE.md na raiz (muitas vezes só apontando para o AGENTS.md) e um .claude/settings.json com permissões. Este é o tipo de configuração que eu deixo versionada:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push:*)"
    ]
  }
}

Com isso, o Claude Code roda teste e lint sem me perguntar, mas não lê arquivo de segredo nem faz push. Push é sempre comigo.

Screenshot descrito: meu terminal dividido em dois painéis. À esquerda, o Claude Code rodando uma refatoração, mostrando a lista de arquivos editados e a saída do npm run test. À direita, o Cursor aberto no diff do mesmo branch, onde eu reviso enquanto ele trabalha.

Como eu escolho o modelo

Eu não fico preso a um modelo só, e também não troco a cada lançamento. Minha lógica é por tipo de tarefa:

Planejamento e debugging difícil: o modelo mais forte de raciocínio que eu tiver disponível. Aqui eu aceito esperar mais e pagar mais, porque um plano errado custa muito mais caro depois.
Implementação de um plano já definido: um modelo rápido e bom de código. Se o plano está claro, não preciso do mais caro.
Edições pequenas, renomear, escrever teste simples: o mais rápido disponível. Velocidade importa mais que profundidade.

Um hábito que vale ouro: quando o modelo erra duas vezes a mesma coisa, eu não insisto na mesma conversa. Abro uma conversa nova, com contexto limpo, e reescrevo o pedido melhor. Na maioria das vezes o problema era o meu pedido, não o modelo.

E eu não vou te passar ranking de modelo aqui. Isso muda rápido demais, e o que importa é você testar no seu código, com as suas tarefas.

Privacidade: o que eu faço para não vazar nada

Ferramenta de IA no editor tem acesso ao seu código. Isso inclui, se você deixar, o seu .env. Os cuidados que eu tomo:

Privacy Mode no Cursor sempre ligado em projeto de trabalho.

.cursorignore com tudo que é sensível. O meu padrão:

.env
.env.*
*.pem
*.key
secrets/
dumps/
*.sql.gz
coverage/
dist/

Regras de deny no Claude Code para os mesmos arquivos, como no exemplo acima.
Nada de colar dado real de cliente no chat. Se preciso de um exemplo de payload, eu anonimizo antes. LGPD não tem exceção para “era só para o prompt”.
Conferir a política da empresa. Alguns clientes proíbem enviar código para qualquer provedor externo. Nesses casos, eu não uso, e pronto.

Erros comuns que eu vejo (e que eu já cometi)

1. Rule gigante que ninguém lê

Arquivo de 400 linhas com “boas práticas” genéricas. O agente dilui tudo. Corte para o que ele erra de verdade.

2. Deixar o agente rodar qualquer comando

Auto-run total parece produtivo até o dia em que ele roda um comando destrutivo para “limpar o ambiente”. Use allowlist.

3. Aceitar o diff sem ler

O código parece certo, compila e passa no teste que o próprio agente escreveu. Isso não prova nada. Eu escrevi um post inteiro sobre isso: como eu reviso PR gerado por IA sem virar borracha.

4. Conversa infinita

Uma conversa com 80 mensagens tem contexto poluído. Quando a tarefa muda, abra outra conversa.

5. Pedir “melhore esse código”

Pedido vago gera mudança vaga. Diga o que é “melhor”: mais rápido, mais legível, sem dependência X, com teste para o caso Y.

6. Esquecer que o agente não conhece a regra de negócio

Ele sabe programar. Ele não sabe que cliente inadimplente não pode gerar pedido. Essa informação precisa estar no pedido, no AGENTS.md ou num teste.

Meu fluxo resumido

Abro a tarefa e penso no critério de pronto.
Se é exploratória ou visual: Cursor. Se tem critério claro e é mecânica: Claude Code.
Para tarefa grande, peço um plano primeiro, com o modelo mais forte, e só depois a implementação.
Testes e lint rodam automaticamente; push e instalação de pacote, nunca.
Reviso o diff completo antes de commitar, como se fosse PR de outra pessoa.

Perguntas frequentes

Preciso pagar pelos dois?

Não necessariamente. Comece com um. Se você vive no editor, o Cursor resolve a maior parte. Se você vive no terminal, o Claude Code pode ser suficiente. Eu uso os dois porque meu trabalho mistura os dois tipos de tarefa.

Rules do Cursor e CLAUDE.md conflitam?

Podem, se você escrever coisas diferentes em cada lugar. Por isso eu concentro o essencial no AGENTS.md e deixo os arquivos específicos de cada ferramenta curtos, só com o que é particular dela.

O Privacy Mode deixa o Cursor pior?

Na minha experiência, não notei diferença na qualidade das respostas. O que muda é o que acontece com seu código depois. Para projeto profissional, vale ligar.

Dá para usar Claude Code em CI?

Dá, com o modo não interativo (claude -p). Mas eu só uso para tarefas de leitura e sugestão, como revisar um diff e comentar. Deixar um agente alterar código e fazer merge sozinho em CI ainda não é algo que eu faço.

Qual o primeiro passo se eu nunca configurei nada?

Crie um AGENTS.md com como rodar e testar o projeto, e um .cursorignore com seus arquivos sensíveis. Só isso já melhora muito o resultado e reduz o risco.

Se você tem um setup diferente e funciona, me conta pelo contato. Eu atualizo este post conforme meu fluxo muda.