Guia de Approval y Sandbox para Claude Code | Configuracion segura para el trabajo diario

Tener approval activado no significa que Claude Code ya sea seguro. Cuando aparecen demasiados dialogs, la gente deja de leer. Cuando allow es demasiado amplio, el agente puede ejecutar acciones que en realidad debian parar en manos humanas.

Este articulo responde a la pregunta operativa que aparece despues de empezar con Claude Code: que debe ser automatico, que debe pedir approval y que debe estar prohibido. Si quieres el contexto completo, combina esta lectura con harness engineering, permissions guide y security failure cases.

Approval no es lo mismo que seguridad

La configuracion diaria suele necesitar tres capas:

Control	Funcion	Ejemplos
permission rules	Separar allow / ask / deny	secrets, comandos destructivos, deploy
approval flow	Frenar antes de efectos irreversibles	git push, publish, send
sandbox	Reducir lo que puede tocar el shell	build, validacion, scripts exploratorios

La referencia oficial debe ser permissions, settings y hooks. La idea central es simple: lo reversible debe ser rapido; lo irreversible debe ser lento.

Una division practica para el uso diario

Accion	Recomendacion	Motivo
Leer archivos, buscar, revisar diffs	allow	Bajo riesgo
Build, test, lint, analytics	allow	No debe frenar la iteracion
Editar codigo en una rama	ask o allow por sesion	Depende del repo
git push, deploy, publish, send	ask	Tienen efecto externo
Leer .env, rm -rf, git reset --hard	deny	El dano potencial es alto
Escrituras a APIs externas	ask	Afectan sistemas reales

Base util para .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Si tu entorno no soporta sandbox, compensa moviendo mas acciones con side effects a ask.

Hooks para reducir errores repetidos

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

La combinacion util es:

• bloquear secrets antes del commit
• forzar build antes del deploy
• ejecutar validaciones despues de editar

Tres workflows reales

1. Sitio de contenido

No basta con escribir el articulo. Hay que revisar analytics, elegir el tema, crear locales, hacer build, deployar, abrir la URL publica y verificar mobile con Playwright.

2. Repositorio de aplicacion

Claude Code puede leer, refactorizar en una rama y correr tests con mucha seguridad. Push a ramas compartidas, migraciones, APIs de produccion e infraestructura deberian quedarse en ask.

3. Outreach y operaciones

Investigar, clasificar y redactar puede ser automatico. Enviar correos, cambiar registros reales o publicar activos no.

Fallos comunes

1. Poner todo en ask y cansarse de aprobar.
2. Convertir --dangerously-skip-permissions en costumbre.
3. Confundir build correcto con release correcto.

El tercer error es muy frecuente en contenido multilenguaje: la build pasa, pero la URL publica sigue vieja o una locale no salio.

Lo que cambiamos hoy

En ClaudeCodeLab endurecimos la regla diaria:

• publicar un articulo nuevo en cada run
• avanzar tambien una tarea existente
• verificar mobile con Playwright
• comprobar en produccion todas las URLs del mismo slug

La seguridad real no sale de una advertencia vaga, sino de reglas operativas concretas.

Siguiente paso

Empieza con el cheatsheet gratuito. Si quieres configuraciones, hooks y patrones listos para copiar, revisa la English products page. Si necesitas ayuda para rollout, review flow o limites de automatizacion segura, usa la consultation page.