PTENES
MÓDULO 2.3

🛠️ Configuración: settings.json y permisos

Domina el settings.json: jerarquía user vs project, sistema allow/ask/deny, qué liberar con seguridad, modos de operación y cómo crear un CLAUDE.md eficiente.

6
Temas
50
Minutos
Básico
Nivel
Config
Tipo
1

📄 El archivo settings.json

O settings.json es el punto central de configuración de Claude Code. Controla lo que Claude puede hacer, qué herramientas están disponibles, hooks de automatización y comportamientos predeterminados.

~/.claude/ settings.json global (usuario) merge .claude/ settings.json project (override) resultado Config activa project prevalece Claude Code usa Jerarquía: user proporciona los valores predeterminados · project los sobrescribe

Estructura básica de 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"
}

💡 Crea el archivo si no existe

En una instalación limpia, el archivo aún no existe. Créalo con mkdir -p ~/.claude && touch ~/.claude/settings.json y completa. Claude Code también ofrece el comando /config para edición guiada.

2

🔒 Sistema de permisos: allow / ask / deny

Cada herramienta que Claude usa se puede configurar en tres estados. El estado predeterminado (sin config) es ask — Claude pregunta antes de ejecutar.

✓ allow

Se ejecuta sin pedir confirmación

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

Usa para operaciones seguras y repetitivas

⚡ ask (predeterminado)

Pide confirmación cada vez

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

Seguro, pero genera interrupciones frecuentes

✗ deny

Bloquea completamente la acción

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

Usa para proteger operaciones destructivas

Sintaxis de glob en los patrones

# 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

✅ Qué liberar de forma segura

Aquí tienes la configuración recomendada para desarrollo local. Producción y CI/CD tienen reglas diferentes.

settings.json recomendado para desarrollo 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 permitir (allow)

  • ✓Read — leer nunca causa daños
  • ✓git status/diff/log — solo consultan
  • ✓npm test/lint/build — operaciones de desarrollo
  • ✓Write dentro de src/ — alcance limitado
  • ✓Herramientas MCP de lectura (ej.: listado de BD)

✗ Mantener como ask o deny

  • ✗rm, rmdir — eliminación irreversible
  • ✗git push — el commit va al remoto
  • ✗sudo — riesgo sistémico
  • ✗DROP TABLE / DELETE (base de datos)
  • ✗Bash(*) sin restricciones en máquinas de producción
4

🔀 Modos de operación

Además de settings.json, los flags de línea de comandos controlan el comportamiento de sesiones específicas. Son útiles para automatización, CI/CD y scripts.

1

Modo interactivo (predeterminado)

Claude pide confirmación para acciones no autorizadas

claude  # abre REPL com confirmações
2

Modo print (no interactivo)

Para scripts y pipelines: responde y termina

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

Modo dangerously-skip-permissions

Solo desarrollo local — ejecuta todo sin confirmación

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

Flags útiles 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"

💡 Regla de oro para CI/CD

En pipelines automatizados, configura permisos explícitos en el .claude/settings.json del proyecto (versionado en el repo). Así, los permisos se pueden auditar mediante git y no dependen de la configuración local de cada desarrollador.

5

📝 CLAUDE.md: instrucciones persistentes

O CLAUDE.md Claude lo lee automáticamente en cada sesión. Es el «briefing» del proyecto: contexto, convenciones y comandos especiales. Invierte bien en él.

Plantilla eficaz de CLAUDE.md

# 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

✓ Qué incluir en CLAUDE.md

  • ✓Stack y versiones exactas del proyecto
  • ✓Convenciones de nombres y estilo
  • ✓Comandos frecuentes del proyecto
  • ✓Reglas de negocio críticas
  • ✓Qué NO hacer (restricciones)

✗ Qué no incluir

  • ✗Credenciales o secretos de cualquier tipo
  • ✗Documentación detallada de la API (se hace demasiado extensa)
  • ✗Código fuente directamente en CLAUDE.md
  • ✗Contenido desactualizado: mantenlo actualizado

Generar CLAUDE.md automáticamente

# 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 en la práctica

La separación entre la configuración global (user) y la del proyecto permite valores predeterminados personales que no interfieren en otros proyectos.

Ejemplo: dos proyectos, configuraciones 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 *)"]
  }
}

💡 Versiona la configuración del proyecto

Agrega .claude/settings.json al git del proyecto. Así, todo el equipo usa los mismos permisos y el historial de cambios queda en el repositorio. Solo ~/.claude/settings.json es personal y no debe versionarse.

✅ Resumen del Módulo 2.3

✓
settings.json controla todo: permisos, herramientas, modelo, hooks
✓
allow/ask/deny con patrones glob para un control granular
✓
Lectura siempre segura, escritura con alcance definido, destrucción siempre ask/deny
✓
Project sobrescribe user — versiona la configuración del proyecto en git
✓
CLAUDE.md se lee en cada sesión: contexto persistente sin repetirlo

Siguiente módulo:

2.4 — MCP y tu primer proyecto: conectar herramientas externas y crear el primer flujo real de extremo a extremo.