El clasificador te cuida el daño. La dirección sigue siendo tuya.

El 14 de agosto de 2026, el modo automático pasó a ser el modo de permisos por default en Claude Code para las sesiones nuevas de Pro, Max y Team. Si nunca elegiste un modo, ya estás ahí. Si tú habías fijado uno, ese se queda: te sale un aviso una sola vez preguntándote si quieres cambiarte, y si no lo aceptas, todo sigue igual. Y si tu organización te administra el default, no se movió nada.

Automático quiere decir que Claude ya no se detiene a pedirte permiso en cada acción. En su lugar, un modelo clasificador aparte revisa cada cosa antes de que corra, y bloquea lo que se sale de lo que pediste, apunta a infraestructura que no reconoce, o huele a que viene de algo hostil que Claude leyó por ahí.

Lo que salió del estudio

Anthropic corrió un estudio controlado con 1,053 testers de pago, comparando revisión humana contra el clasificador sobre los mismos comandos:

Y en sesiones reales, no de laboratorio: el 6.3% de las sesiones aprobadas a mano terminó con una acción dañina que el usuario nunca pidió, contra el 2.4% de las sesiones en automático.

El dato incómodo no es que la máquina revise. Es que tú, dándole Aceptar durante media hora, atrapabas uno de cada siete.

Y entonces, ¿de qué sí hay que cuidarse?

El clasificador revisa una sola pregunta: si esta acción puede hacer un daño que no se deshace. Un force push que machaca lo que ya estaba subido, un secreto saliéndose del repo, un deploy a producción, un borrado de algo que existía antes de la sesión. Eso lo frena, y lo frena mejor que tú.

Lo que no revisa nunca es si Claude está construyendo lo que le pediste. Que arme rapidísimo una función que tú nunca mencionaste no rompe nada. No hay daño que detener. Simplemente va para otro lado — y hacia dónde va eso lo decides tú, antes, o no lo decide nadie.

Un modo de permisos es una sola decisión: qué tanto se detiene Claude a preguntarte. No cambia lo que puede hacer, cambia cuántas veces te interrumpe para hacerlo. Hay seis, y la mayoría de la gente solo conoce dos.

Qué te da Shift+Tab, en qué orden

Shift+Tab cicla tres: Manual, Aceptar ediciones y Plan. Los otros no están ahí por default. Cuando tu cuenta tiene automático disponible, se mete al ciclo, y entra hasta el final. Si además arrancaste la sesión con omisión de permisos habilitada, ese entra antes que el automático — así que con los dos prendidos vas a pasar por omisión de permisos de camino al automático. Vale la pena saberlo antes de picarle de más.

Los dos que empiezan con la pausa son los que te van a detener. Los de la doble flecha son los que van a seguir solos. Es lo único que necesitas distinguir de reojo.

En la web y en el celular no tienes los mismos seis

Esto sorprende a la gente que planea desde la terminal y luego intenta seguir desde el navegador:

Estas listas no son un resumen mío: son las reglas con las que sale de fábrica, y las puedes imprimir tú desde tu propia terminal. Léelas de corrido y fíjate en lo que tienen en común.

Imprímelas tú, no me creas

Las reglas cambian entre versiones. Este comando te saca las que tiene tu instalación, hoy:

Y si ya le agregaste reglas propias, claude auto-mode config te muestra las que de verdad están corriendo, con las tuyas mezcladas.

Cuándo se rinde y vuelve a preguntarte

El automático no insiste para siempre. Si el clasificador bloquea tres acciones seguidas, o veinte en total a lo largo de la sesión, el modo se pausa solo y Claude vuelve a pedirte permiso como antes. En cuanto apruebas una, sigue.

Cuando eso pasa seguido, casi nunca es que el clasificador se puso paranoico: es que no sabe qué es tuyo. No conoce el bucket de tu equipo ni el registro interno de paquetes, así que los trata como si fueran de afuera.

Qué haces cuando te frena algo que sí querías

Todo el mundo sabe que conviene planear antes. Y aun así nadie lo hace el martes a las siete, cuando el cambio se ve chiquito y ya lo tienes en la cabeza. Ahí está el problema: planear vive del lado de la buena intención, y la buena intención pierde contra la prisa siempre.

La solución no es acordarte mejor. Es que el proyecto arranque planeando y tú tengas que salirte a propósito si de verdad no lo necesitas.

La línea

Va en el archivo de configuración del proyecto, en .claude/settings.json, en la raíz del repo:

Con eso, cada sesión que abras en ese repo arranca en modo plan. No te lo tienes que acordar, y si lo commiteas, tampoco se lo tiene que acordar tu equipo.

Y ya no es lento, que era la vieja excusa

La razón por la que la gente abandonaba el modo plan era que se pasaba preguntando permiso para leer cosas. Explorar el repo requería aprobar comando tras comando, y para el tercero ya te habías salido.

Eso cambió. Cuando tienes automático disponible, el modo plan usa ese mismo clasificador durante la planeación — viene prendido de fábrica. Los comandos de exploración se aprueban solos, y los que no pasan se bloquean. Claude lee todo lo que necesita sin interrumpirte, y sigue sin poder editar una sola línea de tu código.

Es la mejor parte del cambio y casi nadie la vio: el mismo revisor que te dejó correr solo es el que hizo que planear dejara de estorbar.

Qué puede y qué no, mientras planea

• Puede leer cualquier archivo del proyecto.
• Puede correr comandos para explorar, si el clasificador los aprueba.
• Puede repartir la investigación a otro agente para que la lectura pesada quede en otra ventana y no te llene la conversación.
• No puede editar, crear ni borrar nada de tu código hasta que apruebes el plan.

Y como esto es un archivo de configuración y no todo el mundo quiere abrirlo a mano, pídeselo a Claude. Es la herramienta que se configura a sí misma:

Deja este proyecto arrancando siempre en modo plan.

Crea o edita .claude/settings.json en la raíz del repo y pon el modo de permisos por default en "plan". Si el archivo ya existe, respeta todo lo que ya esté adentro.

Después dime:
· Qué quedó exactamente en el archivo.
· Si conviene commitearlo para que le aplique a todo el equipo, o dejarlo solo para mí.
· Cómo lo revierto el día que me estorbe.

Una vez que el proyecto arranca planeando, la pregunta cambia. Ya no es «¿me acordé de planear?». Es «¿el plan que me dio sirve para algo?». Eso es lo que sigue.

«Hazme un plan» te devuelve un plan. Casi siempre uno que se ve bien, que suena razonable, y que no te sirve para decidir nada, porque no dice qué está suponiendo, qué se va a quedar fuera ni cómo vas a saber que terminó.

Lo que cambia la respuesta no es pedir más detalle. Es ponerle un contrato de salida: qué formato quieres, qué no quieres, y qué tiene que hacer cuando la respuesta honesta sea «no sé». Todos estos lo traen.

Antes de proponer nada, lee el código que toca esto y dime qué encontraste.

Lo que quiero: <descríbelo aquí en una o dos frases>

Reglas para tu respuesta:
1. Primero lee. No propongas hasta que hayas abierto los archivos que importan y me digas cuáles son.
2. Después dame el plan en pasos numerados. Cada paso dice qué archivo toca y por qué.
3. Al final, una sección "lo que NO voy a hacer" con lo que dejas fuera a propósito.
4. Si algo del código actual ya resuelve parte de esto, dímelo y quítalo del plan.

No me des el plan todavía. Primero hazme las tres preguntas cuya respuesta cambiaría el plan de verdad.

Que sean preguntas que tú no puedes contestar leyendo el código: decisiones mías, no datos que ya están ahí. Nada de "¿uso TypeScript?" si el repo ya es TypeScript.

Para cada pregunta dime también qué asumirías si no te contesto, para que yo decida si con eso basta.

Este repo no lo escribí yo y no lo conozco. Antes de planear, hazme el mapa.

Quiero saber:
· Por dónde entra la aplicación y qué pasa cuando arranca.
· Las tres o cuatro carpetas donde de verdad vive la lógica, y qué hace cada una.
· Cómo se corre y cómo se prueba, con los comandos exactos que ya existen en el repo.
· Las convenciones que el código ya sigue y que yo debería respetar.
· Lo que se ve frágil o a medio terminar.

Cita archivos. Si algo no lo encuentras, dilo en vez de suponerlo. Todavía no me des un plan.

Antes de planear, reparte la investigación.

Manda a leer en paralelo, cada uno a lo suyo, y que ninguno escriba nada:
· <área 1 — por ejemplo: cómo está armada la autenticación hoy>
· <área 2>
· <área 3>

Cuando vuelvan, júntame lo que encontraron en una sola lectura: qué existe ya, qué hay que tocar, y en qué se contradicen entre sí. Con eso, el plan.

Antes de que apruebe este plan: lista los cinco supuestos más grandes que estás haciendo.

Para cada uno:
· El supuesto, en una frase.
· Cómo lo verificarías en este repo, con un comando o un archivo concreto.
· Qué se rompe del plan si resulta falso.

Ordénalos del que más daño hace al que menos. Si alguno lo puedes verificar ahora mismo leyendo, verifícalo y dame el resultado en vez de dejarlo como supuesto.

Este plan está más grande de lo que necesito. Córtalo.

Dame tres versiones:
· La mínima que ya sirve para algo. Qué queda adentro y qué se cae.
· La que te pedí.
· La diferencia entre las dos, en pasos concretos, para saber qué me estoy ahorrando.

Después dime cuál harías tú y por qué. Si la versión mínima de verdad no sirve para nada, dímelo en vez de inventarla.

Antes del plan, escribe el criterio de terminado.

Escríbelo en cosas observables: qué tiene que pasar, en qué pantalla o en qué salida de comando, para que los dos digamos que ya quedó. Nada de "funciona bien" ni "queda limpio".

Máximo cinco puntos. Si se te ocurre algo que no se puede observar, sácalo de la lista y ponlo aparte como "esto queda a mi juicio".

Reescribe el plan para que cada paso termine en algo que yo pueda ver.

Cada paso queda así:
· Qué cambias, y en qué archivo.
· El comando exacto que corro para confirmar que quedó.
· Qué tengo que ver en pantalla si salió bien.

Si un paso no se puede comprobar con un comando, dilo explícito y explícame cómo lo revisaría a mano. No inventes un comando para rellenar el hueco.

Esto es una migración, no una función nueva. Plánealo como migración.

El plan tiene que traer:
· El orden de las operaciones, y por qué ese orden y no otro.
· En qué momento conviven lo viejo y lo nuevo, y hasta cuándo.
· El punto de regreso: en cada paso, cómo lo deshago si sale mal.
· Qué se borra al final, y en qué paso aparte se borra.
· Qué NO se migra en esta vuelta.

Nada de "y luego cambiamos todo lo demás". Si el plan no cabe en pasos que puedo dejar a medias sin romper nada, dímelo antes de escribirlo.

Ahora rompe tu propio plan.

Dime las tres formas más probables de que esto salga mal. Para cada una:
· Qué paso la dispara.
· Cómo me daría cuenta, y en qué momento.
· Qué le cambiarías al plan para que no pase.

No me des riesgos genéricos tipo "podría haber bugs". Quiero los de este plan, sobre este código. Si de verdad crees que aguanta, dilo y defiéndelo señalando el archivo que lo respalda.

Alto. Deja de construir.

Esto ya no es lo que planeamos: <di aquí qué se salió del carril>

Antes de tocar otra línea:
· Dime qué llevas hecho y qué quedó a medias, archivo por archivo.
· Dime en qué punto el plan dejó de servir, y por qué.
· Dame el plan corregido desde donde estamos, no desde cero.

Si algo de lo que llevas hay que deshacerlo, dime qué antes de seguir.

Le dices a Claude «no hagas push hasta que yo revise» y funciona: el clasificador toma los límites que dices en la conversación como señal de bloqueo, y frena las acciones que caen ahí aunque las reglas de fábrica las dejarían pasar. Y el límite se queda puesto hasta que tú lo levantes en otro mensaje. Que Claude crea que ya se cumplió la condición no lo levanta.

El problema es dónde vive. El clasificador lo relee del transcript en cada revisión. Si compactas la conversación y el mensaje donde lo dijiste no sobrevive al resumen, el límite se fue contigo sin que nadie te avise.

Los tres mecanismos, de más flojo a más firme

Y hay un cuarto, que se escribe en español

Las reglas del clasificador no son patrones ni expresiones raras: son frases. Puedes agregarle las tuyas escritas como se las explicarías a alguien que acaba de entrar al equipo — «nunca corras migraciones fuera de nuestra herramienta, ni contra la base de desarrollo», «los cambios bajo infra/produccion pasan por revisión».

Van en tu configuración personal en tres cajones: uno que bloquea sin excepción, uno que bloquea pero que tu intención explícita puede levantar, y uno de excepciones. Y hay un detalle que muerde: si escribes tu lista sin conservar las de fábrica, reemplazas las de fábrica. Se conservan poniendo la palabra $defaults dentro del arreglo.

En qué orden se resuelven

• Lo que bloqueaste sin excepción gana siempre.
• Después, lo que bloqueaste con excepción posible.
• Después, tus reglas de excepción, que levantan las anteriores.
• Y hasta el final, tu intención explícita en el mensaje.

Tú no tienes que decidir cuál de los cuatro mecanismos usar. Dile el límite en tus palabras y que él elija, con la obligación de explicarte por qué eligió ese:

Quiero límites que no se borren cuando compacte la conversación.

Estos son, en mis palabras:
· <por ejemplo: que me pregunte antes de cualquier push>
· <por ejemplo: que nunca corra migraciones contra la base de producción>
· <por ejemplo: que no toque la carpeta infra/>

Para cada uno, dime primero cuál es el mecanismo correcto: una regla que me pregunte, una que bloquee de plano, o una regla en prosa para el clasificador. Explícame la diferencia en una línea y por qué elegiste esa.

Luego escríbelas en el archivo de configuración que corresponda, sin borrar lo que ya tengo, y dime cuáles se le van a aplicar al equipo si commiteo el archivo.

Un plan que solo existe en el chat se muere con la sesión. Cierras la terminal y lo único que queda es el código, sin el razonamiento que lo eligió. Y si mañana quieres seguir en otra máquina, o repartirlo, tienes que reconstruirlo de memoria.

Escribirlo en un archivo lo cambia todo, y no por orden: porque ese archivo es lo único que otra sesión puede ejecutar sin ti. Este es el patrón que Anthropic recomienda de forma explícita, y se llama planear aquí y ejecutar allá.

El único paso nuevo de todo esto es el segundo, y es un prompt. Cuando el plan te convenza, antes de aprobarlo:

El plan ya quedó. Ahora déjalo por escrito para que otra sesión lo pueda ejecutar sin mí.

Escríbelo en docs/plan.md con:
· Qué se va a construir, en una frase.
· Los pasos numerados, tal como los aprobamos.
· El criterio de terminado.
· Lo que queda fuera a propósito.
· Los archivos que hay que leer antes de empezar.

Escríbelo para alguien que no vio esta conversación: nada de "como dijimos arriba". Al final, haz commit y push de ese archivo.

Una línea por tarea, y corren juntas

Cada vez que mandas una tarea a la nube se abre su propia sesión, independiente de las demás. Tres líneas seguidas son tres sesiones corriendo al mismo tiempo, y ninguna espera a la otra.

Para verlas todas desde tu terminal, /tasks. Y desde ahí mismo, con la tecla t, te teletransportas a la que quieras revisar.

Lo que teleport revisa antes de dejarte entrar

• Que tu directorio esté limpio. Si traes cambios sin commitear, te ofrece guardarlos primero.
• Que estés parado en el mismo repositorio, no en un fork.
• Que la rama de la sesión de la nube ya esté empujada. Él la trae y se cambia a ella.
• Que sea la misma cuenta con la que se creó la sesión.

Es la consecuencia que nadie te anuncia. En cuanto Claude puede trabajar largo sin interrumpirte, dejas de esperarlo: abres otra terminal y te pones en otra cosa. Y en un rato tienes tres sesiones sobre el mismo repo, cada una convencida de que el proyecto está como lo dejó ella.

Para eso salió el tubo nuevo: tus sesiones se pueden mandar mensajes entre sí, en la misma máquina.

Tú no llamas nada. Lo pides en español.

No hay comando para mandar un mensaje. Le dices a Claude qué quieres que sepa la otra sesión, y él busca a quién alcanza, elige a cuál y le escribe. También lo hace por su cuenta cuando ve que acaba de romper algo sobre lo que otra sesión está trabajando.

Qué es exactamente un mensaje

Texto plano. Nada más. Nunca el historial de la conversación, nunca archivos. Lo que llega del otro lado es el nombre de quien lo mandó y el texto, y ya.

Así que si lo que quieres es mover una conversación entera a otra terminal, esto no es. Para eso se retoma la sesión. Y si lo que quieres es que un agente que estrenas mañana sepa lo que se resolvió hoy, un mensaje tampoco alcanza: eso vive en disco, y es de otra guía.

Por dónde viaja, y qué se puede en cada caso

El renglón de arriba es el que importa: entre dos terminales tuyas abiertas en la misma computadora, el mensaje no sale de tu máquina. Fuera de ahí, Claude puede contestar pero no puede empezar la conversación.

Lo que un mensaje no puede hacerte

• No aprueba permisos. Un mensaje de otra sesión nunca cuenta como tu consentimiento, así que no puede contestar por ti un permiso pendiente.
• No cambia configuración. La sesión que lo recibe tiene instrucción de no tocar permisos, CLAUDE.md ni ajustes porque otra sesión se lo pidió.
• No ejecuta comandos. Si el texto trae un /compact, llega como texto y ahí se queda.
• No se salta tus permisos. Si actuar sobre el mensaje necesita un permiso que esa sesión no tiene, te sale el mismo diálogo de siempre.

Y el uso de todos los días es este. No tiene ciencia, y es lo que evita que dos sesiones se pisen:

Avísale a la sesión que está trabajando en <el backend / la migración / la landing> que <lo que acabas de terminar, romper o decidir>.

Mándale nada más lo que necesita para no chocar conmigo: qué cambió, qué archivo o qué rama toca, y qué tiene que hacer distinto de ahora en adelante. Sin historia y sin contexto de más.

La herramienta con la que Claude le escribe a tus otras sesiones es la misma con la que le escribe a sus propios subagentes. Cambia a quién va dirigido, no el mecanismo. Y eso te da algo que casi nadie usa.

Retomar en vez de relanzar

Cada vez que lanzas un subagente se crea uno nuevo, con la ventana en blanco. Vuelve a leer, vuelve a buscar, vuelve a concluir lo que ya había concluido hace veinte minutos.

Retomarlo es otra cosa: conserva su conversación completa, con todas sus llamadas, sus resultados y su razonamiento, y sigue exactamente donde se quedó. Se lo pides en español — «sigue con esa revisión y ahora mira la parte de autorización» — y él lo despierta sin volver a lanzarlo.

Bajo el automático, al subagente lo revisan tres veces

Y por qué esto se conecta con planear

Cuando estás en modo plan y Claude necesita entender tu código, no lo lee en la conversación principal: se lo encarga a un agente aparte, para que toda esa exploración quede en otra ventana y la tuya siga limpia y de solo lectura.

Ese es el patrón que te conviene repetir a mano cuando el plan es grande. Repartes la lectura, cada uno vuelve con lo suyo, y el plan se escribe una sola vez con todo junto. El prompt para eso es el último de la sección 05.

Y este es el que se le olvida a todo el mundo, el día siguiente, cuando vuelve a abrir la misma sesión:

Retoma al subagente que hizo <la revisión de seguridad / el mapa del repo / la investigación de X> y dile que siga con esto:

<lo que falta>

No lo lances de nuevo desde cero: quiero que conserve lo que ya leyó y lo que ya concluyó. Si ese agente no se puede retomar, dímelo y explícame por qué antes de arrancar uno nuevo.

Nada de esto sirve como conocimiento. Sirve como configuración, y son quince minutos una sola vez, en el proyecto en el que ya estás trabajando.

Ábrelo, pega el prompt de abajo y contéstale las preguntas que te haga. Sale de ahí con el modo plan de default, tus límites escritos donde aguantan, y la sesión con nombre.

Vamos a dejar este proyecto listo para que trabajes en automático sin desviarte. Hazlo en este orden, y párate a preguntarme en todo lo que no sea obvio.

1. Pon el modo plan como default del proyecto en .claude/settings.json, sin borrar lo que ya esté ahí.
2. Pregúntame qué acciones quiero que me consulten siempre, aunque el automático esté prendido, y escribe esas reglas.
3. Revisa mi CLAUDE.md y dime si hay algo ahí que debería ser un límite duro en vez de una sugerencia, y cuál.
4. Ponle nombre a esta sesión, uno que diga en qué estoy trabajando.
5. Al final, resúmeme qué quedó configurado, qué se commitea al repo y qué se queda nada más en mi máquina.

Qué queda distinto después

• Abres el proyecto y arranca planeando. Salirte es una decisión tuya, no un olvido.
• Los límites que te importan viven en un archivo, así que un /compact ya no se los lleva.
• Lo que tenga que pasar por tus manos te pregunta, aunque el automático esté prendido.
• Tus sesiones tienen nombre, así que se pueden avisar entre ellas cuando se pisan.

Y esa parte no se automatiza. Es la que se quedó siendo tu trabajo.