Approval y sandbox en Claude Code: dónde poner el freno cada día

“Bueno, igual sale el diálogo de aprobación, así que no pasa nada.”

Eso pensaba yo recién empezando. Cada vez que Claude Code iba a hacer algo, aparecía una confirmación. Yo la leía, pulsaba OK y me sentía un conductor prudente.

Dos semanas después me fijé en cómo se movía mi propio dedo y se me heló la sangre. Estaba pulsando Enter por reflejo, sin leer el texto de la confirmación. Lo que se convierte en “el flujo de siempre” deja de revisarse. El git push, las escrituras a una API externa… todo pasaba sin que yo mirara el contenido. Que no ocurriera un accidente fue pura suerte.

Los diálogos de aprobación no te hacen más seguro por el simple hecho de añadir más. Si hay demasiados, la gente deja de leerlos. Si hay muy pocos, se cuelan hasta las operaciones que no tienen vuelta atrás. Hoy quiero escribir sobre ese reparto, pero no centrado en los detalles de la configuración, sino en cómo decidir cada día.

Puntos clave

• La aprobación no es “parar todo” ni “dejar pasar todo”. El eje es: lo reversible, rápido; lo irreversible, lento. La línea se traza según si puedes hacer undo o no.
• El permission mode (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) se cambia según la fase del trabajo. Para explorar, plan; para corregir revisando sobre la marcha, acceptEdits.
• --dangerously-skip-permissions (es decir, bypassPermissions) no se usa en el día a día. En su lugar, usa el modo auto o el sandbox.
• El sandbox reduce a nivel de sistema operativo el “alcance” que Bash puede tocar. Funciona en macOS / Linux / WSL2, y no funciona en Windows nativo.
• En equipo, “dónde está el freno” no se deja al criterio de cada persona: se fija de forma física con reglas deny y hooks.

El formato concreto del archivo de configuración lo tienes en el artículo hermano referencia de permisos de Claude Code, y las recetas para combinar CLAUDE.md con los permisos están en CLAUDE.md × recetas de permisos. Este artículo se centra solo en la decisión operativa de “dónde poner el freno”.

La aprobación se decide por “¿se puede deshacer?”

Cuando dudes con el reparto, antes de medir si el riesgo técnico es grande o pequeño, hazte una sola pregunta:

“Esto, ¿lo puedo deshacer dentro de cinco minutos?”

Leer un archivo, hacer grep, mirar un diff, lanzar npm run build. Esto lo puedes repetir mil veces sin problema. En el peor caso vuelves atrás con git checkout. Por eso quiero que vaya rápido. En cambio, git push, un deploy a producción, enviar un correo o escribir en una base de datos externa cambian el mundo de fuera en el instante en que pulsas. No se deshacen. Por eso conviene frenarlos a propósito.

El reparto en tres niveles que más uso es este:

Operación	Decisión	Motivo
Leer, grep, diff, build, test, lint	allow	Es reversible. No quiero perder velocidad
Editar código en una rama	ask o acceptEdits	Depende de la madurez del repo
push, deploy, publish, enviar correo, escribir en API externa	ask	Afecta al mundo de fuera. No se deshace
Leer .env, rm -rf, git reset --hard, curl | sh	deny	Si hay accidente, el daño es demasiado grande

Lo que más cuesta decidir aquí es “editar”. Editar no es peligroso siempre. En un repo personal con tests sólidos, no da miedo dejar que las ediciones corran rápido. Lo que sí da miedo es dejar las ediciones sueltas en un repo cercano a producción con tests débiles. Por eso el criterio no es “¿permito editar?”, sino ¿con qué verifico después de editar?. Si los comandos de verificación están preparados, las ediciones pueden ir rápido. Si no lo están, déjalas en ask.

Con deny no se pierde nada por ponerlo amplio “por si acaso”. Leer .env o los comandos destructivos los tapas desde el principio, dando por hecho que nunca llegará el día de subirlos a allow. Las instrucciones del tipo “sáltate los permisos y hazlo lo más rápido posible” que recopilé en prompts peligrosos para Claude Code son justamente un intento de romper esta línea. Si lo tienes en deny, da igual lo que digan en el prompt: el propio motor lo detiene.

El permission mode se cambia por fases

Si allow/ask/deny configura “qué” se frena, el permission mode es la marcha que elige “cuánto se frena ahora mismo”. Con Shift+Tab puedes alternar entre default → acceptEdits → plan. En la página oficial de permission modes están todos los modos, pero para el día a día basta con memorizar esta correspondencia:

Modo	Lo que corre sin confirmar	Cuándo
default	Solo lectura	Repo nuevo, trabajo en el que quiero ir con cuidado
plan	Solo lectura (planifica sin editar)	Quiero entender la base de código antes de moverme
acceptEdits	Lectura + ediciones dentro de la carpeta de trabajo	Corrijo revisando yo mismo
auto	Casi todo (un clasificador comprueba la seguridad por detrás)	Trabajos largos, reducir la fatiga de confirmar
dontAsk	Solo lo que ya está en allow	CI o scripts en un entorno cerrado
bypassPermissions	Todo (sin comprobaciones)	Solo dentro de un contenedor o VM aislado

Mi forma de usarlos es sencilla. La entrada a un trabajo nuevo siempre es plan. Dejo que Claude lea primero, que proponga el plan y, cuando confirmo que la dirección encaja, lo pongo en marcha. Una vez fijada la dirección, bajo a acceptEdits y dejo que edite de golpe, y luego reviso el resultado entero con git diff. Leer todo junto al final concentra más la atención que aprobar línea por línea. Esto es convertir en sistema el “al final lo reviso siempre”, y conecta directamente con la idea de “poner al portero en manos de una máquina” que escribí en ingeniería de harness.

Una advertencia. En cualquier modo que no sea bypassPermissions, las escrituras en protected paths no se aprueban automáticamente. Son sitios como .git, .claude, .bashrc o .npmrc: si se rompen, muere el repo o la propia configuración. Aunque estés editando a gusto en acceptEdits, aquí sí entra una confirmación. No lo veas como un estorbo, sino como la última red de seguridad.

Cómo evitar --dangerously-skip-permissions

Para resolver el “hay demasiadas confirmaciones, qué pereza”, mucha gente echa mano de --dangerously-skip-permissions (es decir, el modo bypassPermissions). Como dice el nombre, es la bandera que apaga todas las comprobaciones.

Si lo usas a diario en la conversación, ya no tienes un “agente con supervisión”. Solo es que todavía no has tenido un accidente. La propia documentación oficial deja claro que este modo es “solo dentro de un contenedor o VM aislado”: salvo los casos peores como rm -rf / o rm -rf ~, no sale ningún prompt. La defensa contra prompt injection es cero.

Pero la pereza en sí es un sentimiento legítimo. Por eso lo que hay que eliminar es el número de confirmaciones, no la red de seguridad. Hay dos alternativas.

Una es el modo auto. Este sí quita las confirmaciones, pero otro modelo clasificador vigila cada operación por detrás y bloquea las peligrosas: curl | bash, deploys a producción, push directo a main, force push. Si en la conversación dices “no hagas push”, eso también funciona como una señal de bloqueo temporal. Las confirmaciones bajan, pero las operaciones peligrosas se paran. Es algo distinto de bypassPermissions. Eso sí, el modo auto es research preview, así que no es una herramienta para saltarte de un plumazo la revisión de operaciones delicadas, sino para usarla en “trabajos cuya dirección es de fiar”.

La otra es el sandbox. Lo explico en el siguiente apartado.

Si quieres reducir confirmaciones: primero acceptEdits o auto, y si aún no basta, sandbox. A bypassPermissions lo dejas como exclusivo para contenedores. Pensándolo en este orden, casi nunca queda razón para quitar la red de seguridad entera.

El sandbox limita “lo que puede tocar” desde el SO

Si la aprobación es el mecanismo que pregunta “¿se puede hacer esta operación?”, el sandbox es el que reduce a nivel de sistema operativo el propio alcance de archivos y red que Bash puede tocar. La aprobación es una comprobación previa a la ejecución; el sandbox es un muro durante la ejecución. Están en capas distintas.

Donde esto resulta útil es en que cubre el punto débil de la aprobación. La aprobación decide mirando la cadena del comando, así que si npm run build hace por detrás algo inesperado, no se entera. Pero con el sandbox, ese comando solo puede escribir, por defecto, dentro de la carpeta de trabajo. Aunque no se comporte como dice su nombre, el SO lo detiene físicamente.

Al ejecutar /sandbox se abre un panel de configuración donde puedes elegir entre dos modos:

• auto-allow: dentro del sandbox, ejecuta Bash sin confirmar (es seguro porque el alcance está acotado). Solo las operaciones que salen del alcance vuelven a la aprobación normal.
• regular permissions: incluso dentro del sandbox, las confirmaciones salen como siempre. Más control, pero más confirmaciones.

O sea, le viene perfecto a quien piensa “quiero menos confirmaciones, pero me da miedo que se ejecute cualquier cosa”. Como te protege por alcance, no hace falta preguntar a cada paso.

Pero hay una restricción importante. El sandbox solo funciona en macOS / Linux / WSL2, y no funciona en Windows nativo. Los usuarios de Windows necesitan ejecutar Claude Code dentro de WSL2. Si no puedes usar WSL, o si vas a usarlo en Windows a secas, no esperes nada del sandbox y endurece el reparto de allow/ask/deny. Lleva sobre todo deploy, publish y lo relacionado con secrets hacia ask. Ese es el punto realista en Windows.

La configuración del sandbox tiene esta forma. Solo abres un agujero explícito para las herramientas que necesitan escribir fuera de la carpeta de trabajo (por ejemplo, kubectl que toca ~/.kube).

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false es la opción para que, en un entorno donde el sandbox no esté disponible, solo se muestre un aviso y se caiga a la ejecución normal. Al revés, si en tu organización quieres que el sandbox sea obligatorio, ponlo en true y se detiene el propio arranque. Y algo discreto pero importante: denyRead. Por defecto, el sandbox puede leer casi todos los archivos, así que tapar explícitamente secretos como ~/.aws o ~/.ssh da tranquilidad.

El punto de partida para “la operación diaria”

Si juntas todas estas decisiones en un único archivo, este es un punto de partida más que suficiente para el día a día. El significado fino del formato (la diferencia entre Bash(npm run build) y Bash(npm*), etc.) lo dejo para la referencia de permisos.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "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
  }
}

Lo que hace son solo tres cosas. La lectura y la verificación van rápido. Las operaciones que afectan al exterior se paran siempre. Lo claramente peligroso queda prohibido desde el principio. Pongo defaultMode: "plan" porque quiero arrancar cada sesión nueva desde “primero leo y planifico”. Luego, mientras trabajo, voy subiendo a acceptEdits con Shift+Tab.

Que las ediciones (Edit / Write) no estén ni en allow ni en ask es intencionado: quiero controlarlas por el lado del modo (acceptEdits). Si atas las ediciones por la regla y por el modo a la vez, dejas de saber cuál está mandando. Las ediciones, por modo; los efectos externos, por regla: separando los papeles así, se te ordena la cabeza.

En equipo, fija “dónde está el freno” de forma física

Hasta aquí era cosa de uno. En equipo se suma otro problema: que la línea acabe siendo distinta según la persona. Hay gente prudente y gente que quiere tirar con bypassPermissions. Si lo dejas al criterio y al sentido común, la línea real del equipo acaba siendo la de la persona más laxa.

Por eso, lo que quieres frenar no lo dejas al juicio de cada uno: lo fijas de forma física. Tres ejemplos concretos.

1. Frenar la entrada de secrets antes del commit. Con un hook PreToolUse, antes de git add comprueba por máquina si .env está en stage. Antes de que la persona se dé cuenta de “uy, esto no debía entrar”, el commit se para.

2. Forzar el build antes del deploy. No te fíes del “creo que el build pasó en local”. Antes del comando de deploy, que un hook ejecute siempre npm run build.

3. Lanzar la verificación automática después de editar. Tras Edit / Write, ejecuta npm run test. Como la verificación corre incluso en una corrección pequeña, no sigues adelante con algo roto.

La configuración mínima es más o menos esta. Más hooks no es mejor: con un hook que frena y un hook que verifica la operación se rompe menos.

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

En Windows, la parte de grep funciona si la sustituyes por findstr o un pequeño script de Node. Lo importante no es el comando en sí, sino las tres formas: “parar antes del commit / build antes del deploy / verificar después de editar”. Para atarlo a nivel de organización, también puedes poner bypassPermissions en disable con managed settings y hacer el sandbox obligatorio.

Fallos comunes

Los tres los hemos hecho de verdad, yo o gente de mi entorno.

Poner todo en ask y quedarse tranquilo

El primer día parece seguro. Pero a la semana empiezas a pulsar OK sin leer el texto de la confirmación. Esto es más peligroso que tener un deny flojo, porque te queda la ilusión de “creo que lo revisé”. Antes de alinear asks, primero solidifica el deny.

Que --dangerously-skip-permissions se te haga muletilla

En cuanto le coges el gusto una vez al “qué rápido es esto”, ya no hay vuelta atrás. Pero eso es solo quitar la supervisión. Si las confirmaciones te dan pereza, usa el modo auto o el auto-allow del sandbox. No hay ninguna necesidad de quitar la red de seguridad entera.

Confundir un build correcto con un release correcto

Esto es frecuentísimo, tanto en operación de contenido como en desarrollo. El build local pasó, pero la URL pública sigue vieja, hay un solo idioma sin actualizar, o el CTA se ve roto en móvil. La aprobación y el sandbox no previenen este fallo. Lo que hace falta es comprobar después de publicar. Yo hice muchas veces el “creo que lo publiqué”.

Preguntas frecuentes

P. ¿En qué se diferencian el modo auto y el auto-allow del sandbox? R. En la forma de proteger. El modo auto usa un modelo clasificador que juzga “¿es peligrosa esta operación?” y la bloquea. El auto-allow del sandbox no mira el contenido de la operación, sino que asegura la seguridad acotando con el SO “lo que puede tocar”. Uno protege por juicio, el otro por alcance. También puedes combinar ambos.

P. ¿Se puede usar el sandbox en Windows? R. En Windows nativo, no. Si ejecutas Claude Code dentro de WSL2, sí. Si lo usas en Windows a secas, no te apoyes en el sandbox: lleva deploy, publish y lo de secrets hacia ask, y endurece el deny.

P. ¿Cómo elijo entre el modo plan y el modo acceptEdits? R. plan es “solo leer, no editar”, para la fase de entender la base de código y armar el plan. acceptEdits es “dejar pasar sin confirmar las ediciones dentro de la carpeta de trabajo”, para la fase de corregir de golpe cuando la dirección ya está clara. Yo empiezo con plan y, cuando hay acuerdo, bajo a acceptEdits.

P. ¿Y si quiero ejecutar sí o sí, una sola vez, algo que metí en deny? R. El deny lo fuerza el propio motor de Claude Code, así que no se afloja desde el prompt (ese es el valor del deny). Si de verdad lo necesitas, quítalo de settings en el momento, ejecútalo y vuelve a ponerlo al terminar. El propio engorro de “lo quité temporalmente” actúa como freno para las operaciones peligrosas.

P. ¿No se solapan los hooks y los permisos? R. No se solapan. Los permisos controlan “¿se puede ejecutar esta operación?”, y los hooks controlan “¿qué se ejecuta siempre antes o después de la ejecución?”. Las comprobaciones deterministas, como parar la entrada de secrets o hacer build antes del deploy, son cosa de los hooks.

Lo que pasó al probarlo de verdad

Metí esta forma de pensar tal cual en la daily automation de este sitio. Lo que más cambió no fue la calidad del output de la IA en sí, sino que quedó claro en qué momento se para el humano.

Antes tenía una operación vaga de “avanzar algo, lo que sea”, y a veces el run terminaba tocando un poco un artículo ya existente. Ahora el flujo está fijado: plan para armar el plan → acceptEdits para editar → build con un hook antes del deploy → comprobar en móvil todos los idiomas tras publicar. Desde que dejé de usar bypassPermissions y pasé a acceptEdits + sandbox, desapareció ese sobresalto de “sin darme cuenta había hecho algo hacia fuera”.

Más que delegar todo en una IA lista, poner una pausa justo antes de las operaciones que no se deshacen. Parecía un rodeo, pero lo que se puede hacer girar tranquilo cada día era esto. Para empezar, ten al lado la hoja de trucos gratuita y ve rellenando tu lista de deny línea por línea.