Inicio / Seguridad y datos

Automatizacion responsable: reversible primero, fallo señalado, correctivo solicitado

Una acción irreversible espera un punto de control humano antes de ejecutarse, pero ese control solo es automático en el modo de permiso Manual, el más prudente de los seis modos documentados: en las ofertas de pago una sesión arranca sin embargo en modo automático por defecto, y varios de esos modos aprueban de antemano los comandos de archivos dentro de la carpeta de trabajo, incluida la eliminación, lo que traslada la responsabilidad del punto de control a quien diseña la automatización.

Un modo de permiso elegido antes de lanzar una automatización determina si una eliminación de archivo espera tu aprobación o se ejecuta sola. La documentación oficial de Claude Code describe dos comportamientos distintos para el modo Accept Edits: aprueba de antemano las modificaciones de archivos, así como un conjunto fijo de comandos de sistema como mkdir, touch, rm, mv, cp y sed, siempre que permanezcan dentro de la carpeta de trabajo. El modo que se salta por completo los avisos de permiso va más lejos por construcción: omite esas peticiones de confirmación, incluidas las que se refieren a la eliminación.

El control humano no es automático en todas partes

La documentación oficial enumera seis modos de permiso, Manual (el modo por defecto fuera de una suscripción de pago), Accept Edits, Plan, Auto, Don't Ask y Bypass Permissions. Solo el modo Manual exige sistemáticamente una confirmación antes de que un comando destructivo se ejecute dentro de la carpeta de trabajo; Plan y Don't Ask siguen siendo al menos igual de restrictivos. Pero en una suscripción Pro, Max o Team, una sesión arranca por defecto en modo Auto, no en modo Manual, un modo que ejecuta la mayoría de las acciones con simples verificaciones de seguridad en segundo plano en lugar de una confirmación en cada comando. Una automatización lanzada en modo Auto, Accept Edits o Bypass Permissions ya no plantea entonces la pregunta de confirmación para la mayoría de los comandos de archivos: ejecuta la eliminación en el momento en que se alcanza el comando, no en el momento en que alguien la relee. Sigue existiendo, pese a todo, una excepción documentada, en todos los modos incluido Bypass Permissions: una eliminación con rm o rmdir que apunte a una ruta crítica nunca se aprueba de antemano. El punto de control humano debe entonces construirse en el propio guion de la automatización, antes del comando destructivo, en lugar de suponerlo presente por defecto en la herramienta, o en el simple ajuste del modo de permiso.

Punto de control antes de la ejecución:
1. Describir la acción prevista (qué archivos, qué carpeta)
2. Marcar una pausa explícita que espera una validación
3. Ejecutar solo después de esa validación

Un fallo silencioso nunca se anuncia a sí mismo

Una automatización planificada que lleva semanas funcionando bien puede detenerse sin avisar de nada en cuanto la herramienta que invoca cambia de ubicación en el disco, por ejemplo tras una actualización que desplaza un ejecutable. Nada en el resto del sistema nota esa detención si otro efecto secundario, una línea de registro escrita por una razón sin relación, sigue dando la impresión de que todo funciona. Este riesgo no es propio de una herramienta en particular: es el precio de toda ruta fija hacia un binario. Una lista de candidatos probada en cada ejecución, con una alerta sonora si ninguno responde, cuesta unas pocas líneas y evita ese silencio.

Un correctivo bloqueado se pide, no se anota

Escribir un bloqueo en una nota personal o en un archivo de seguimiento no equivale a comunicarlo. Mientras nadie más haya leído esa nota, la decisión queda pendiente sin que nadie lo sepa. Lo que convierte un correctivo bloqueado en una decisión tomada el mismo día es una petición directa, dirigida a la persona que puede resolverlo, con el comando exacto que ejecutar y el coste concreto de la espera, no una frase general del tipo habría que revisar esto algún día.

Estos tres reflejos se juntan en un mismo gesto: antes de dejar que una automatización toque algo irreversible, comprueba su punto de control y su plan de contingencia por si la herramienta que invoca desaparece. La lección sobre las reglas de restricción que no siempre lo son muestra por qué una regla de seguridad que parece aplicarse puede no bloquear nada en absoluto, la misma prudencia se aplica aquí al modo de permiso elegido.