MÓDULO 2.3

🛠️ Configuração: settings.json e permissões

Domine o settings.json: hierarquia user vs project, sistema allow/ask/deny, o que liberar com segurança, modos de operação e como criar um CLAUDE.md eficiente.

6
Tópicos
50
Minutos
Básico
Nível
Config
Tipo
1

📄 O arquivo settings.json

O settings.json é o ponto central de configuração do Claude Code. Ele controla o que o Claude pode fazer, quais ferramentas estão disponíveis, hooks de automação e comportamentos padrão.

~/.claude/ settings.json global (user) merge .claude/ settings.json project (override) resultado Config ativa project vence Claude Code usa Hierarquia: user fornece defaults · project sobrescreve

Estrutura básica do settings.json

// ~/.claude/settings.json (user global)
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Bash(git *)",
      "Bash(npm *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)"
    ]
  },
  "model": "claude-sonnet-4-5"
}

💡 Crie o arquivo se não existir

Na instalação limpa, o arquivo não existe ainda. Crie com mkdir -p ~/.claude && touch ~/.claude/settings.json e popule conforme sua necessidade. Claude Code também oferece o comando /config para edição guiada.

2

🔒 Sistema de permissões: allow / ask / deny

Cada ferramenta que o Claude usa pode ser configurada em três estados. O estado padrão (sem config) é ask — o Claude pergunta antes de executar.

✓ allow

Executa sem pedir confirmação

"allow": [
  "Read(**)",
  "Bash(git *)"
]

Use para operações seguras e repetitivas

⚡ ask (padrão)

Pede confirmação a cada vez

// sem config =
// comportamento ask
// para Write, Edit,
// Bash genérico

Seguro mas gera interrupções frequentes

✗ deny

Bloqueia completamente a ação

"deny": [
  "Bash(rm *)",
  "Bash(drop *)",
  "Bash(sudo *)"
]

Use para proteger operações destrutivas

Sintaxe de glob nos patterns

# Ferramentas disponíveis para permissão:
Read(**)          # Leitura de qualquer arquivo
Read(src/**)      # Leitura apenas em src/
Write(**)         # Escrita em qualquer lugar
Write(src/**)     # Escrita apenas em src/
Edit(**)          # Edição de arquivos
Bash(*)           # Qualquer comando bash
Bash(git *)       # Apenas comandos git
Bash(npm test)    # Apenas npm test
Bash(npm *)       # Qualquer comando npm
mcp__*(*)         # Qualquer ferramenta MCP
3

✅ O que liberar com segurança

Aqui está a configuração recomendada para desenvolvimento local. Produção e CI/CD têm regras diferentes.

settings.json recomendado para dev local

{
  "permissions": {
    "allow": [
      "Read(**)",                   // leitura sempre segura
      "Edit(src/**)",              // edição dentro de src/
      "Write(src/**)",             // criação em src/
      "Bash(git status)",          // git somente leitura
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(npm test)",            // rodar testes
      "Bash(npm run lint)",
      "Bash(npm run build)"
    ],
    "deny": [
      "Bash(rm -rf*)",             // nunca deletar recursivo
      "Bash(sudo*)",               // sem sudo
      "Bash(git push*)",           // push requer revisão humana
      "Bash(git reset --hard*)"    // destrutivo
    ]
  }
}

✓ Seguro liberar (allow)

  • Read — leitura nunca causa dano
  • git status/diff/log — apenas consultam
  • npm test/lint/build — operações de dev
  • Write dentro de src/ — escopo limitado
  • Ferramentas MCP de leitura (ex: listagem de BD)

✗ Manter como ask ou deny

  • rm, rmdir — delete irreversível
  • git push — commit vai para remoto
  • sudo — risco sistêmico
  • DROP TABLE / DELETE (banco de dados)
  • Bash(*) sem restrição em máquinas de prod
4

🔀 Modos de operação

Além do settings.json, flags de linha de comando controlam o comportamento para sessões específicas. Úteis para automação, CI/CD e scripts.

1

Modo interativo (padrão)

Claude pede confirmação para ações não liberadas

claude  # abre REPL com confirmações
2

Modo print (não-interativo)

Para scripts e pipelines — responde e sai

claude --print "Gere um Dockerfile para Node.js 20"
# Output vai para stdout, sem REPL
3

Modo dangerously-skip-permissions

Apenas dev local — executa tudo sem confirmação

claude --dangerously-skip-permissions
# ⚠️  NUNCA usar em produção ou máquinas compartilhadas

Flags úteis para CI/CD

# Rodar tarefa específica em pipeline
claude --print --model claude-sonnet-4-5 \
  "Analise os testes que falharam e sugira correções"

# Modo não-interativo com permissões via settings
# (settings.json já tem allow para as ações necessárias)
echo "rode os testes e corrija falhas" | claude --print

# Com timeout (útil em pipelines)
timeout 120 claude --print "faça code review deste PR"

💡 Regra de ouro para CI/CD

Em pipelines automáticos, configure permissões explícitas no .claude/settings.json do projeto (versionado no repo). Assim as permissões são auditáveis via git e não dependem de configuração local de cada desenvolvedor.

5

📝 CLAUDE.md: instruções persistentes

O CLAUDE.md é lido automaticamente pelo Claude a cada sessão. É o "briefing" do projeto — contexto, convenções, comandos especiais. Invista bem nele.

Template de CLAUDE.md eficiente

# CLAUDE.md — meu-projeto

## Sobre o projeto
API REST em Node.js + Express + TypeScript.
Banco de dados: PostgreSQL com Prisma ORM.
Deploy: Railway. Domínio: api.meu-projeto.com

## Stack e versões
- Node.js 20 LTS
- TypeScript 5.3
- Express 4.18
- Prisma 5.x

## Convenções de código
- Arquivos em camelCase, pastas em kebab-case
- Imports absolutos via tsconfig paths (@/src/...)
- Testes com Vitest, não Jest
- Commits em português, formato: feat/fix/chore: mensagem

## Comandos úteis
- npm run dev     → servidor local na porta 3000
- npm test        → roda testes
- npm run migrate → aplica migrations Prisma

## Regras importantes
- NUNCA fazer push direto para main
- NUNCA modificar arquivos em /migrations manualmente
- Sempre rodar testes antes de commitar

✓ O que incluir no CLAUDE.md

  • Stack e versões exatas do projeto
  • Convenções de nomes e estilo
  • Comandos frequentes do projeto
  • Regras de negócio críticas
  • O que NÃO fazer (restrições)

✗ O que não colocar

  • Credenciais ou secrets de qualquer tipo
  • Documentação detalhada de API (fica grande demais)
  • Código-fonte diretamente no CLAUDE.md
  • Conteúdo desatualizado — mantenha-o vivo

Gerar CLAUDE.md automaticamente

# Dentro do REPL, gera CLAUDE.md a partir do projeto
/init

# Claude analisa o projeto e gera rascunho
# → revise e ajuste o arquivo gerado
# → commite no repo para toda a equipe usar
6

🌐 Settings user vs project na prática

A separação entre settings globais (user) e de projeto permite defaults pessoais que não interferem em outros projetos.

Exemplo: dois projetos, configs diferentes

# ~/.claude/settings.json (global — meu default pessoal)
{
  "permissions": {
    "allow": ["Read(**)", "Bash(git status)", "Bash(git diff*)"]
  },
  "model": "claude-sonnet-4-5"
}

# ~/projetos/app-pessoal/.claude/settings.json
// mais permissivo — projeto só meu
{
  "permissions": {
    "allow": ["Read(**)", "Write(**)", "Edit(**)", "Bash(npm *)"]
  }
}

# ~/projetos/app-trabalho/.claude/settings.json
// mais restritivo — código de produção
{
  "permissions": {
    "allow": ["Read(**)", "Edit(src/**)", "Bash(npm test)"],
    "deny": ["Bash(git push*)", "Bash(rm *)"]
  }
}

💡 Versione o settings do projeto

Adicione .claude/settings.json ao git do projeto. Assim toda a equipe usa as mesmas permissões e o histórico de mudanças fica no repositório. Apenas ~/.claude/settings.json é pessoal e não deve ser versionado.

Resumo do Módulo 2.3

settings.json controla tudo: permissões, ferramentas, modelo, hooks
allow/ask/deny com glob patterns para controle granular
Leitura sempre segura, escrita com escopo, destruição sempre ask/deny
Project sobrescreve user — versione o settings do projeto no git
CLAUDE.md é lido em toda sessão — contexto persistente sem repetição

Próximo Módulo:

2.4 — MCP e seu primeiro projeto: conectar ferramentas externas e fazer o primeiro fluxo real ponta a ponta.