Inicio / Seguridad y datos

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

Una automatización en modo Auto, Accept Edits o Bypass Permissions ejecuta la mayoría de las eliminaciones en cuanto se alcanza el comando, sin confirmación: construye el punto de control humano antes del comando destructivo. Un fallo silencioso nunca se anuncia solo, y un correctivo bloqueado se pide, no se anota.

La documentación oficial de Claude Code describe dos modos. 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 control humano no es automático en todas partes

La documentación oficial enumera seis modos de permiso, Manual (el modo de arranque de claude -p), 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 desde finales de septiembre, una sesión interactiva del terminal o de VS Code arranca por defecto en modo Auto en todas las ofertas, 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

Lo que cambió octubre

En la aplicación de escritorio y en VS Code, en modo Bypass, un rm o un rmdir peligroso se rechaza ahora de inmediato con una sugerencia de reescritura, en lugar de abrir un aviso: una sesión sin supervisión no se queda bloqueada. Un rm -r dirigido a un disco montado o a una carpeta de primer nivel (/Volumes, /media, /mnt/c en WSL) recibe el aviso de seguridad, como rm -rf /Applications. Un script lanzado con claude -p arranca en modo Manual, según la página de modos de permiso: prevé --permission-mode o una regla de autorización. El evento OpenTelemetry claude_code.safety_event registra cada llamada a herramienta que una regla, el modo auto, una comprobación, un hook o el sandbox detuvo.

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. 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. 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.

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 vale para el modo de permiso elegido.