PTENES
MODULE 2.3

🛠️ Configuration: settings.json and Permissions

Master settings.json: user vs. project hierarchy, the allow/ask/deny system, what you can safely allow, operating modes, and how to create an effective CLAUDE.md.

6
Topics
50
Minutes
Basic
Level
Config
Type
1

📄 The settings.json file

O settings.json is Claude Code's central configuration point. It controls what Claude can do, which tools are available, automation hooks, and default behaviors.

~/.claude/ settings.json global (user) merge .claude/ settings.json project (override) result Active config project takes precedence Claude Code uses Hierarchy: user provides defaults · project overrides

Basic settings.json structure

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

💡 Create the file if it doesn't exist

In a clean installation, the file doesn't exist yet. Create it with mkdir -p ~/.claude && touch ~/.claude/settings.json and populate it as needed. Claude Code also offers the command /config for guided editing.

2

🔒 Permission System: Allow / Ask / Deny

Each tool Claude uses can be configured in one of three states. The default state (with no config) is ask — Claude asks before executing.

✓ allow

Runs without asking for confirmation

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

Use for safe, repetitive operations

⚡ ask (default)

Asks for confirmation every time

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

Safe, but causes frequent interruptions

✗ deny

Completely blocks the action

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

Use to protect destructive operations

Glob syntax in 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

✅ What to safely allow

Here's the recommended configuration for local development. Production and CI/CD have different rules.

settings.json recommended for local development

{
  "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
    ]
  }
}

✓ Safe to allow

  • ✓Read — reading never causes damage
  • ✓git status/diff/log — only query information
  • ✓npm test/lint/build — dev operations
  • ✓Write within src/ — limited scope
  • ✓Read-only MCP tools (e.g., database listing)

✗ Keep as ask or deny

  • ✗rm, rmdir — irreversible deletion
  • ✗git push — commit goes to remote
  • ✗sudo — system-wide risk
  • ✗DROP TABLE / DELETE (database)
  • ✗Unrestricted Bash(*) on production machines
4

🔀 Operating modes

In addition to settings.json, command-line flags control behavior for specific sessions. Useful for automation, CI/CD, and scripts.

1

Interactive mode (default)

Claude asks for confirmation for actions that aren't allowed

claude  # abre REPL com confirmações
2

Print mode (non-interactive)

For scripts and pipelines—responds and exits

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

dangerously-skip-permissions mode

Local dev only — runs everything without confirmation

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

Useful flags for 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"

💡 Golden rule for CI/CD

In automated pipelines, configure explicit permissions in the .claude/settings.json of the project (versioned in the repo). This makes permissions auditable through git and independent of each developer's local configuration.

5

📝 CLAUDE.md: persistent instructions

O CLAUDE.md is read automatically by Claude in every session. It's the project "briefing" — context, conventions, and special commands. Invest in it wisely.

Efficient CLAUDE.md template

# 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

✓ What to include in CLAUDE.md

  • ✓Project stack and exact versions
  • ✓Naming and style conventions
  • ✓Frequently used project commands
  • ✓Critical business rules
  • ✓What NOT to do (restrictions)

✗ What not to include

  • ✗Credentials or secrets of any kind
  • ✗Detailed API documentation (gets too long)
  • ✗Source code directly in CLAUDE.md
  • ✗Outdated content—keep it current

Generate CLAUDE.md automatically

# 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

🌐 User vs. project settings in practice

Separating global (user) settings from project settings lets you personal defaults that don't interfere in other projects.

Example: two projects, different configs

# ~/.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 *)"]
  }
}

💡 Version the project settings

Add .claude/settings.json to the project’s git. This way, the whole team uses the same permissions and the change history stays in the repository. Only ~/.claude/settings.json is personal and should not be version controlled.

✅ Module 2.3 Summary

✓
settings.json controls everything: permissions, tools, model, hooks
✓
allow/ask/deny with glob patterns for granular control
✓
Reading is always safe, scoped writing, destruction always ask/deny
✓
Project overrides user — version the project settings in git
✓
CLAUDE.md is read in every session — persistent context without repetition

Next Module:

2.4 — MCP and your first project: connect external tools and build your first real end-to-end workflow.