Como vimos en el capítulo 1, Claude Code pasa por una barrera de permisos en cada llamada a una herramienta. Si te imaginas eso como un único mando, cuando se vuelva molesto lo girarás hacia el extremo más laxo. En realidad son tres cosas con papeles distintos: la frecuencia de las confirmaciones, los permisos por herramienta y el aislamiento a nivel de sistema operativo. Si aprietas uno, puedes aflojar otro, y «seguro o rápido» no es una disyuntiva.

Delegar no es todo o nada

El punto de partida no es el nombre de un modo, sino «en qué punto de este trabajo deja de haber vuelta atrás». Hay tres criterios.

  • ¿Se puede deshacer? Si es una edición que git puede revertir, la pérdida es pequeña. Un borrado definitivo, un push forzado o destrozar la base de datos no se deshacen
  • ¿Hasta dónde llega? ¿Se queda en el directorio de trabajo o alcanza producción, una rama compartida o el entorno de otra persona?
  • ¿Toca secretos? Cuando se dan a la vez poder leerlos y poder mandarlos fuera, tienes una fuga

Lo pesado son las operaciones seguras en los tres ejes (pruebas, formateo, ediciones locales), y lo peligroso son operaciones que aparecen rara vez. Si aflojas de forma uniforme, abres también el lado peligroso. El esqueleto es aflojar por frecuencia y apretar por naturaleza.

Modos de permisos: qué cambia realmente

El mando más grande es el modo de permisos, que fija el marco general de la frecuencia de las confirmaciones. Se cambia con Shift+Tab (la explicación, en los modos de permisos de Claude Code).

Pedir permiso (default)

La lectura es automática y las ediciones y la ejecución de comandos se confirman siempre. Es el modo de partida en un repositorio que tocas por primera vez.

Aceptar ediciones (acceptEdits)

Aprueba automáticamente las ediciones dentro de la carpeta de trabajo. Lo de fuera del alcance, las rutas protegidas y los demás comandos se confirman.

Modo plan (plan)

Investiga, pero no edita el código fuente. Pasa a ejecutar después de que apruebes el plan.

Modo automático (auto)

Otro modelo evaluador revisa cada operación antes de ejecutarla y solo detiene las peligrosas. Sujeto a condiciones de uso.

Saltarse los permisos (bypassPermissions)

No pasa ni por las confirmaciones ni por las comprobaciones de seguridad. Solo para entornos aislados. Únicamente está activo si arrancas con su opción propia.

Existe también dontAsk, exclusivo de la configuración: ejecuta solo la lista de permitidos y los comandos de solo lectura, y rechaza el resto.

Atención también a las rutas protegidas. La escritura en .git, .claude o la configuración del shell no se aprueba automáticamente en los modos normales. El modo por defecto puede fijarse en la configuración, pero el modo automático es el único que se ignora en la configuración del proyecto: es la línea que impide que un repositorio lo active por su cuenta.

El modo automático no es un «default más rápido»

Las confirmaciones desaparecen casi por completo, pero no queda todo suelto: el modelo evaluador detiene las operaciones que exceden el alcance de lo pedido, las que tocan infraestructura desconocida y las inducidas por el contenido que se ha leído. Lo que suele pasar son las operaciones sobre archivos dentro de la carpeta de trabajo y el HTTP de solo lectura. Lo que se detiene es el envío de material confidencial al exterior, los despliegues a producción y las operaciones destructivas de git.

Los límites que enuncias en la conversación no se guardan. Un «no hagas push» sirve de fundamento para bloquear, pero como se relee cada vez desde la conversación actual, si la compresión se lo lleva, el límite desaparece con él. Además, el modo automático está en vista previa de investigación y la propia documentación oficial señala que reduce las confirmaciones pero no garantiza la seguridad. No sustituye a la revisión.

Por qué te sigue preguntando en el modo de saltarse los permisos

Has puesto --dangerously-skip-permissions, que en teoría se salta las confirmaciones, y aun así Claude te pregunta «¿puedo ejecutar esto?». No está roto. Los permisos tienen dos capas independientes y el modo de saltarse los permisos solo elimina una (por qué te pide permiso incluso en el modo bypass).

Capa 1: la interfaz de permisos de herramientas (se puede eliminar)

«¿Puedo editar este archivo?»: el diálogo interactivo que aparece justo antes de llamar a una herramienta. Lo emite el programa llamado Claude Code.

Capa 2: el juicio de seguridad del propio Claude (no se puede eliminar)

«Esto supone un cambio en la base de datos de producción, ¿sigo adelante?»: una confirmación que llega como texto de la conversación. Sale de los principios de conducta del modelo, así que ninguna opción la detiene.

Para distinguirlas, fíjate en si es la interfaz o el texto de la respuesta. Las condiciones que activan la capa 2 son casi las mismas que los tres ejes del principio: que sea irreversible, que su alcance sea amplio y que el riesgo de seguridad sea alto. Ante un borrado definitivo, un push forzado o una migración en producción, Claude se detiene aunque le hayas abierto los permisos.

Esto no es un fallo, es diseño. Lo que te entrega el modo de saltarse los permisos es la llave para usar las herramientas, no la llave para desactivar el juicio de Claude. La capa 2 no se puede dejar a cero.

Lo que sí puedes bajar es la frecuencia. Escribe en CLAUDE.md solo aquellas premisas que puedas afirmar como hechos, y formula las peticiones de forma concreta: «borra los .log de /tmp/» provoca menos preguntas que «límpialo». Eso sí: el modo de saltarse los permisos no es la respuesta a «las confirmaciones son un fastidio» (riesgos del modo bypass y cómo usarlo con seguridad).

Reglas en settings.json: no responder dos veces a la misma pregunta

Si el modo es «la frecuencia global», las reglas de permisos son «las excepciones por herramienta y por comando». Se escriben en settings.json como allow (sin confirmación), ask (confirmar siempre) y deny (prohibido), y se pueden compartir (configurar las reglas de permisos: allow, ask y deny).

La evaluación va en el orden deny, ask, allow, y gana la primera coincidencia: el grado de detalle no altera ese orden. Un deny amplio como Bash(aws *) gana a un allow concreto como Bash(aws s3 ls). Los deny no admiten excepciones. Cuando pasa lo de «lo he puesto en allow y me sigue preguntando», casi siempre es que un ask ha coincidido antes. Como el ask fuerza la confirmación incluso en el modo automático, es el sitio donde colocar las operaciones que no se pueden deshacer.

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

La ubicación también tiene su jerarquía. De más fuerte a menos: la configuración administrada (no se puede sobrescribir), la CLI, settings.local.json, settings.json y ~/.claude/settings.json. Ahora bien, un deny de cualquier nivel gana siempre a un allow de cualquier otro nivel. En los especificadores, el espacio seguido de * marca el límite de palabra (Bash(ls *) coincide con ls -la, pero no con lsof).

De qué no te protegen las reglas

Lo único que miran las reglas es «la cadena de texto del comando que se va a ejecutar», así que cualquier vía que se salga de ahí pasa de largo.

  • No impiden el acceso indirecto: un deny de Read(.env) funciona con las herramientas de archivo integradas y con cat, pero no funciona cuando es un script el que abre el archivo
  • Los ejecutores de entorno ocultan el contenido: devbox run * o docker exec ejecutan sus argumentos tal cual, de modo que un allow de Bash(devbox run *) acaba permitiendo incluso devbox run rm -rf .
  • Restringir URL por los argumentos es frágil: se escapa reordenando o expandiendo variables. Es más sólido denegar curl y wget por completo y designar los destinos permitidos con WebFetch(domain:)

Aunque escribas «no leas el .env» en CLAUDE.md, eso no es una regla. CLAUDE.md cambia lo que Claude intenta hacer, pero no cambia lo que tiene permitido hacer. Lo que cambia ese alcance son las reglas, los modos y el hook PreToolUse del capítulo 6 (los deny y los ask se evalúan al margen del resultado del hook).

El sandbox: qué puede acotar y qué no

Lo que tapa las vías a las que no llegan las reglas es el sandbox: en lugar de «qué se confirma», acota de antemano «hasta dónde se puede tocar». Quien lo impone no es Claude, sino el sistema operativo (el núcleo), así que aunque un comando ya permitido haga más de lo que su nombre sugiere, la frontera no se mueve (guía completa del sandbox de Claude Code).

1. Aislamiento del sistema de archivos

Solo se puede escribir en el directorio de trabajo y en la carpeta temporal (valor inicial). ~/.bashrc y las zonas del sistema no se pueden reescribir.

2. Aislamiento de la red

El estado inicial es denegar por principio, con cero destinos. Al conectar con un dominio nuevo aparece una confirmación, y si lo registras en allowedDomains deja de preguntar.

Estos dos van siempre juntos: con uno solo, los secretos que se han podido leer salen fuera. Hay dos formas de aprobación. El modo de permiso automático ejecuta el Bash de dentro sin confirmación, y el modo de permisos normal mantiene el aislamiento y además pasa por las confirmaciones. Incluso con el permiso automático, el deny tiene siempre prioridad, un rm que apunta a rutas críticas se confirma y un ask definido por contenido también fuerza la confirmación.

Ojo, porque hay dos cosas llamadas «automático». El modo de permiso automático del sandbox deja pasar «porque la frontera del sistema operativo lo encierra»; el modo automático (auto) de los modos de permisos deja pasar «porque el modelo evaluador lo ha examinado».

Conoce primero lo que no protege

El sandbox no es un aislamiento completo. Dejar esto en la ambigüedad y mantener el permiso automático siempre encendido es el estado más peligroso de todos.

  • Solo alcanza a Bash y a sus procesos hijos: las herramientas integradas Read, Edit y Write, los servidores MCP y los hooks van por otra vía (se controlan con las reglas de permisos). Para envolver el proceso entero está @anthropic-ai/sandbox-runtime
  • El valor inicial de lectura es amplio: lo que se acota es sobre todo la escritura, y ~/.ssh o ~/.aws/credentials se pueden leer tal cual. Tápalos con denyRead
  • Abrir demasiado los permisos deja un agujero: el tráfico se juzga por el nombre del host y el contenido cifrado no se inspecciona por defecto. Si permites dominios amplios, queda margen para que algo se escape
  • Depende del entorno: en macOS no hace falta instalar nada más. Linux y WSL2 necesitan bubblewrap y socat, y Windows nativo no está soportado

El sandbox no es un muro pensado para enfrentarse a un atacante, sino un arnés de seguridad que reduce en órdenes de magnitud los accidentes y los desmadres. Anthropic ha publicado que internamente logró reducir con seguridad un 84% las confirmaciones de permisos, pero es un informe sobre cuántas confirmaciones se pudieron reducir, no una garantía de que sea infranqueable.

Los accidentes ocurren, a grandes rasgos, de cuatro formas

Vamos a reordenar los mecanismos desde el lado de los accidentes. Elige la configuración según si sirve contra estas cuatro.

1. Comandos destructivos

Un rm que limpia una ruta imprevista, un git push --force que borra el trabajo de otra persona. Lo que tienen en común es que no se pueden deshacer. Lo que funciona son las reglas deny y ask y el aislamiento de archivos. Lo más fiable es dejar en ask las operaciones que no se pueden deshacer.

2. Fuga de secretos

Solo hay accidente cuando coinciden poder leer y poder enviar. Por eso las contramedidas también son dos: que no los lea (deny de Read(.env), denyRead) y que no los envíe (deny de curl y wget, dominios permitidos estrechos). Con una sola no basta.

3. Llegar a otra rama o a otro entorno

Lo que empezó como corregir un archivo en local acaba convirtiéndose en un push a una rama compartida o en un despliegue a producción: es una escalada de la operación. En el modo normal hay confirmaciones intercaladas en cada escalón, pero si lo has abierto todo, los escalones desaparecen. Poner el push y el despliegue en ask es un seguro barato.

4. Instrucciones coladas en los archivos que lee

En los README, las incidencias, las páginas web y los PDF que Claude lee puede haber instrucciones plantadas y dirigidas a Claude (inyección de prompts). Aunque diga «envíalo a esta dirección» escrito en letra blanca, desde el punto de vista de Claude es texto que entra por la misma puerta que tu petición, y separar datos de órdenes no es algo evidente.

Lo que no funciona aquí es el modo de saltarse los permisos (lo plantado llega directamente a la ejecución) y prohibirlo en CLAUDE.md (no cambia lo que tiene permitido hacer). Lo que sí funciona son las fronteras a nivel de sistema operativo (donde no se puede escribir no se escribe, y a donde no se puede conectar no se conecta) y las reglas deny. Lo plantado no se ve, así que no confíes en «darte cuenta»: los materiales que no son de fiar, hazlos leer con los permisos recortados solo para esa sesión.

Se puede delegar / hay que detenerlo

Aplicando los tres ejes, la línea queda así.

Se puede delegar (ponlo en allow)

Pruebas, comprobación de tipos, linter y compilación / ediciones dentro del directorio de trabajo / lecturas y búsquedas / confirmaciones locales

Hay que detenerlo (ask o deny)

Push a ramas compartidas y push forzado / despliegues y migraciones a producción / lectura de archivos con secretos / comandos que implican envíos al exterior / escrituras fuera del directorio de trabajo

  • Decide un modo habitual. Si el trabajo es de edición repetitiva, acceptEdits; si es material sensible, default. Escríbelo en defaultMode
  • Cuando hayas respondido tres veces a la misma confirmación, pásala a allow. Y al revés: fija en ask cualquier operación ante la que hayas pensado aunque sea una vez «esto es peligroso»
  • Trata las prohibiciones dichas en la conversación dando por hecho que van a desaparecer.
  • Cuando aflojes, aprieta siempre en otro sitio. Lo único que no debes crear nunca es un estado sin confirmaciones y sin fronteras

En qué condiciones se puede usar el modo de saltarse los permisos. Dentro de un contenedor, una máquina virtual o un ejecutor de CI que puedas tirar si se rompe, montando únicamente el directorio de trabajo y sin llevarte allí el .env del anfitrión ni las claves SSH. «Las confirmaciones son molestas» no es un motivo válido. Y al terminar el trabajo, lee el diff sin falta.

Todo lo que hemos visto aquí son mecanismos para «reducir» los accidentes, no para «eliminarlos». Tanto el juicio de la capa 2 como la evaluación del modo automático o la frontera del sandbox tienen formas de ser atravesados. Lo que más rinde es mantenerte en un estado del que se pueda volver atrás.

Resumen

  • Los permisos tienen tres capas: modo, reglas y sandbox. Los ejes son si se puede deshacer, hasta dónde llega y si toca secretos, y la pauta es aflojar por frecuencia y apretar por naturaleza
  • Los permisos tienen una estructura de dos capas. Saltárselos solo elimina la interfaz de la capa 1; las confirmaciones en forma de texto son parte del diseño
  • Las reglas se evalúan como deny, ask y allow, gana la primera coincidencia y lo concreto no altera ese orden
  • Las reglas solo miran cadenas de texto. Quien tapa el resto es el sandbox, pero solo alcanza a Bash y sus procesos hijos y su valor inicial de lectura es amplio
  • Los accidentes tienen cuatro formas: comandos destructivos, fuga de secretos, alcanzar otro entorno e instrucciones coladas

Una vez decidido hasta dónde delegas, solo queda hacerlo crecer a la medida de tu entorno. Pasa al capítulo 6, «Ampliarlo».