Cómo elegir el modo de permisos de Claude Code

Usted pide añadir un banner y el agente propone, de paso, actualizar un módulo antiguo. Conviene ver ese plan antes de que se toque nada y tachar el punto que sobra. Para eso importan tanto un planteamiento claro de la tarea como el modo de trabajo elegido.

El modo de permisos define cómo se autorizan las acciones de Claude Code: qué puede ejecutarse de inmediato, qué requiere preguntarle a usted y qué queda bloqueado. En acciones concretas influyen también la configuración y los permisos ya concedidos. El modo en sí no evalúa la calidad de la solución.

Veremos todos los modos con el ejemplo de una sesión local de Claude Code en la terminal.

Petición y permiso

Aquí es fácil confundir dos cosas que se parecen, pero que funcionan de forma distinta.

La primera es lo que usted escribe al plantear la tarea. Una sección con exclusiones, la frase "primero muéstrame el plan, no cambies nada", una lista de archivos que no se deben tocar. Son límites de alcance: explican la tarea e influyen bastante en lo que el agente propondrá hacer. Pero son texto, y el texto no cambia los permisos técnicos.

La segunda es el modo de permisos, o permission mode. Es un ajuste de la sesión. Se puede perfectamente escribir "no cambies nada" y trabajar en un modo en el que las ediciones se aceptan automáticamente. El agente debería respetar la petición, pero la frase por sí sola no activa ningún bloqueo técnico de las ediciones.

Hay una excepción, y solo parcial. En el modo auto, el clasificador lee la conversación y toma "no hagas push" o "espera a que lo revise" como señal para bloquear esas acciones. Pero no es una regla de la configuración: si al compactar el contexto se pierde el mensaje con la prohibición, se pierde también la prohibición. Para un límite estricto hace falta la configuración, no una frase.

Modos del más seguro al más peligroso

Los modos se recuerdan mejor como una escalera que como una lista. Arriba, el agente no hace casi nada sin usted; abajo, no pregunta en absoluto. Cinco peldaños, más un modo que no encaja en esta escala.

Aquí hay que fijarse en una sola cosa: cuántas acciones pasan sin su respuesta. De arriba abajo ese número crece, y con él crece también el coste de un error. Arriba usted pierde tiempo en confirmaciones; abajo se entera de una edición desafortunada cuando ya está hecha.

En pocas palabras, cada uno:

• plan - el agente explora el proyecto y propone cambios antes de implementarlos; mientras tanto, la edición del código fuente queda bloqueada. Hay una sola excepción: si la sesión se inició con bypassPermissions habilitado, en la terminal la planificación ya no bloquea las ediciones y al agente solo se le pide que no cambie nada. Sirve cuando usted espera una respuesta sobre el código, no cambios en él. Si auto está disponible, los comandos de exploración también los revisa el clasificador, así que aquí puede haber incluso menos preguntas que en default. Está más arriba en la escalera porque no cambia nada en el código fuente. Cuando el plan está listo, Claude Code pregunta cómo continuar: aprobarlo y pasar a auto, aprobarlo confirmando las ediciones a mano o seguir planificando.
• default, que en pantalla suele aparecer como Manual - pregunta antes de ediciones, comandos y accesos a la red. La lectura del proyecto pasa sin preguntas, y lo mismo ocurre con los permisos ya concedidos, así que no tendrá que confirmar cada acción una y otra vez. A veces la pregunta llega incluso con un comando que parece inofensivo. No es un exceso de celo: find con el flag -exec ejecuta cualquier comando, y -delete borra lo que encuentra, por eso estas formas no pasan sin su respuesta.
• acceptEdits, en pantalla "accept edits" - aplica por su cuenta las ediciones de archivos en la carpeta de trabajo y ejecuta sin preguntar algunos comandos de archivos, incluidos rm y mv. Es para ir rápido en archivos conocidos que de todos modos va a releer después.
• auto - lo hace casi todo por su cuenta. La lectura y las ediciones en la carpeta de trabajo pasan directamente, mientras que los comandos y los accesos a la red los revisa un modelo aparte, el clasificador. Algunos los bloquea, y de eso hablaremos más abajo.
• bypassPermissions, también conocido como el flag --dangerously-skip-permissions - no pregunta casi nada. Solo quedan sus reglas explícitas en la configuración (prohibiciones y "preguntar siempre") y un par de salvaguardas del sistema. Lo llaman YOLO, y el nombre no engaña.

El sexto, dontAsk, aparece aparte en el esquema, y hay un motivo. Los peldaños se distinguen por cuánto pasa sin su respuesta, y cuanto más abajo, más se le permite al agente. dontAsk funciona al revés: tampoco pregunta, pero en vez de aceptar, rechaza. Se ejecuta lo que tampoco en el modo normal requiere preguntar (leer archivos de la carpeta de trabajo, comandos seguros de solo lectura), más lo autorizado de antemano. Todo lo que habría requerido una pregunta se rechaza sin una sola pregunta. La sesión simplemente no espera respuesta. Tiene sentido donde no hay nadie que responda, como en escenarios automatizados y entornos cerrados, y en el trabajo normal frente al teclado no lo va a necesitar.

El modo no se cambia pidiéndolo en el chat, sino a mano. En la terminal se hace con Shift+Tab, que va pasando de un modo a otro de forma cíclica, o con el comando /plan para entrar en la planificación. También se puede fijar el modo al arrancar:

claude --permission-mode plan

Este comando se escribe en la terminal desde la carpeta del proyecto, y /plan, dentro de una sesión ya abierta. En el editor el selector tiene otro aspecto y está debajo del campo de entrada, pero la referencia es la misma en todas partes: el indicador del modo actual.

Dos matices sin los cuales es fácil sobrevalorar la escalera. La planificación no es una copia de seguridad: no crea un punto de restauración ni deshace lo ya hecho, solo le muestra el plan antes de que se convierta en ediciones. Y ningún peldaño mueve los límites de la tarea; siguen donde usted los describió.

Cuando auto estorba en lugar de ayudar

Hay una expectativa sobre auto que conviene corregir desde el principio. El modo se llama "automático", y parece que en él pasa absolutamente todo. No es así: el clasificador existe precisamente para detener parte de las acciones.

Entre lo que bloquea por defecto están los despliegues y migraciones en producción, el envío de datos a direcciones externas, el push forzado, el borrado masivo en almacenamiento en la nube, la concesión de permisos, la descarga y ejecución de código de internet y el borrado irreversible de archivos que existían antes de empezar la sesión. La lógica de la lista es sencilla: es aquello que no se puede revertir por sus propios medios.

Lo que pasa después depende de cuántos bloqueos se acumulen. Una acción bloqueada va a la lista de las rechazadas recientemente (/permissions, pestaña Recently denied), y desde ahí se puede volver a lanzar con confirmación manual. Mientras tanto, Claude recibe el rechazo e intenta otro camino. Si el clasificador bloquea tres veces seguidas o veinte veces en una sesión, el modo se pausa y Claude Code vuelve a las preguntas habituales; tras su confirmación, activa auto de nuevo. Los umbrales son fijos y no se pueden configurar.

Esto deja ver dónde empieza a estorbar el modo. Mientras en la tarea haya un solo comando dudoso, auto funciona como está previsto: usted lo autoriza a mano y sigue adelante. Pero cuando la tarea consiste justamente en comandos de ese tipo (monta un entorno de pruebas, ejecuta migraciones sin parar, trabaja con infraestructura ajena), el resultado es extraño. Usted sigue confirmando casi cada paso a mano, solo que dando vueltas de más: el agente choca con un bloqueo, busca un rodeo, y el modo se pausa y se reactiva una y otra vez.

En ese momento es más sencillo subir usted mismo por la escalera. Hasta qué peldaño subir depende de lo que estorbe exactamente:

• default - la opción más directa. Cada edición y cada comando piden permiso, y no aparece ninguna acción rechazada. Es más lento, pero cada paso está a la vista;
• acceptEdits - cuando las ediciones de archivos le parecen bien y lo único dudoso son comandos como el despliegue o las migraciones. Pero tenga en cuenta que este modo deja pasar sin preguntar rm y mv en la carpeta de trabajo, mientras que en auto el clasificador detenía el borrado de archivos existentes.

Esto no es saltarse el bloqueo, y conviene no confundirlo. Usted no desactiva la comprobación, sino que la asume. Además, el borrado de rutas del sistema, como la raíz del disco o la carpeta personal, no pasará sin su confirmación ni siquiera en bypassPermissions. En ese modo y en auto, Claude Code le preguntará, y en la terminal tendrá un par de minutos para responder. Donde no hay forma de preguntar, auto rechaza el comando, y dontAsk lo rechaza siempre. De lo que se trata es de otra cosa: no dar una vuelta de más allí donde de todos modos iba a confirmarlo todo a mano.

El segundo motivo para subir de peldaño no tiene nada que ver con los bloqueos. El clasificador decide si una acción es peligrosa, pero no si el trabajo va en la dirección correcta. Si el agente corrige lo mismo por tercera vez y el resultado sigue sin ser el esperado, en auto simplemente hará un cuarto intento, también sin preguntar. Los desarrolladores de Claude Code aconsejan no insistir en ese momento: vuelva a plan, acuerde de nuevo el enfoque y solo entonces continúe. El mismo principio vale también al arrancar. Una tarea que usted entiende por completo se puede pasar directamente a un modo más permisivo. Si todavía no tiene claro qué debería salir, empiece con plan.

Qué cambia esto en el trabajo

En el trabajo diario, todo se reduce a cuatro hábitos.

1. mirar el indicador al empezar. Muestra el modo; para una acción concreta cuentan también los permisos ya concedidos;
2. contrastar el plan propuesto con los límites de la tarea antes de que se ejecute. Un punto que sobra se corrige con palabras, y es la corrección más barata posible;
3. leer el texto de la opción con la que aprueba el plan: indica en qué modo continuará la sesión al salir de plan;
4. comprobar el resultado cuando esté hecho. Ningún modo garantiza que la tarea esté bien resuelta; de eso se encarga su propia comprobación.

El modo de permisos responde a la pregunta "¿qué se puede hacer sin mí?", no a la pregunta "¿está bien hecho?". La segunda pregunta sigue siendo cosa suya, elija lo que elija.