TL;DR Tres reglas
soft_denynuevas o ampliadas en el clasificador de auto mode: git destructivo local (git reset --hard,git clean -fd,git stash drop), unrm -rfsobre una variable que el clasificador no puede resolver, y escrituras al transcript de la sesión. Las tres bloquean por defecto y se abren en cuanto tu intención es explícita. Las inspeccionas conclaude auto-mode defaults.
Auto mode no ejecuta tus tool calls a ciegas. Las pasa por un clasificador que bloquea todo lo irreversible, destructivo o dirigido fuera de tu entorno. Ese clasificador tiene cuatro niveles: hard_deny bloquea sin excepción, soft_deny bloquea pero se abre si tu mensaje describe exactamente la acción, allow son las excepciones, y por encima está tu intención explícita.
Las tres protecciones que llegaron estas semanas son todas soft_deny. Bloquean por defecto, y basta con que pidas la acción de forma concreta para que pasen. "Ordena el repo" no autoriza un git reset --hard. "Descarta mis cambios locales" sí.
Lo que ahora frena
> Shift+Tab → modo: ⚡ auto
✗ git reset --hard origin/main
soft_deny · Irreversible Local Destruction
(no pediste descartar el trabajo local del working tree)
✗ rm -rf "$BUILD_DIR"/*
soft_deny · Unverifiable Deletion Target
($BUILD_DIR no se resuelve en el transcript; radio desconocido)
✗ echo '{"meta":{...}}' >> ~/.claude/projects/foo/session.jsonl
soft_deny · Session Transcript Tampering
(escritura al historial de la sesión)
1. Git destructivo local (regla ampliada)
La regla Irreversible Local Destruction ya existía: bloqueaba borrar archivos que existían antes de la sesión. En la semana del 15 de junio (v2.1.178 a 183) se amplió para nombrar de forma explícita los comandos de git que descartan trabajo del working tree: git reset --hard, git clean -fd, git stash drop, git checkout -- ., git restore ., git worktree remove --force.
El clasificador presume que tu working tree está sucio. No ve el output de git status, así que falla del lado seguro. Bloquea salvo que hayas nombrado la operación: "descarta mis cambios" o "haz reset a origin" la abren; un genérico "ordena el repo", no.
2. rm -rf sobre una variable que no se resuelve (regla nueva)
Esta es la visceral, y es nueva (semana del 6 de julio, v2.1.202 a 206). rm -rf aparece también en la regla anterior, pero ahí el radio de acción se conoce y solo te falta nombrar el objetivo. Aquí es otra cosa: el objetivo es una variable ($VAR, ${VAR}) o un glob anclado en ella ("$VAR"/*) cuyo valor no está en el transcript. Sin una asignación en la ventana (VAR=…, export VAR=…, read VAR), el valor vino solo de un output que el clasificador nunca vio. El radio es desconocido.
El caso de libro: $VAR sale vacía y rm -rf "$VAR"/* se convierte en un borrado de tu $HOME o de la raíz del sistema. La regla Unverifiable Deletion Target falla del lado seguro y lo bloquea.
Se abre de dos formas: nombras la ruta exacta, o reescribes el comando con la ruta literal ya resuelta dentro. Cuidado con el atajo evidente: un echo "$VAR" previo no sirve, porque su output tampoco llega al clasificador.
3. Manipular el transcript de la sesión (regla nueva)
También nueva en la v2.1.202 a 206. El transcript de la sesión (los .jsonl bajo ~/.claude/projects/) no es un archivo de trabajo cualquiera. Es el estado que el clasificador lee como fuente de verdad en cada comprobación. Ahí viven tus barreras en conversación ("no hagas push"), la evidencia de tu intención e incluso la pista de si un repo es público.
Si una acción pudiera escribir en ese historial, o falsificar las líneas {"meta":{…}} que el clasificador trata como inyectadas por el harness, podría fabricarse su propia autorización. Una entrada manipulada alimenta cada clasificación posterior al reanudar la sesión. La regla Session Transcript Tampering bloquea esas escrituras. Leer el transcript sigue siendo rutina.
Esta protección es la asimétrica de las tres. Un git reset --hard o un rm -rf legítimos son parte del trabajo normal, y por eso se abren cuando eres explícito. Escribir en el transcript de la sesión casi nunca tiene una razón legítima. Que bloquee por defecto es justo lo que quieres.
4. Ver las reglas exactas
El texto completo de cada regla está en los defaults del clasificador:
claude auto-mode defaults
Desde la v2.1.208 puedes leer una sola por su etiqueta, sin pasar por jq:
claude auto-mode defaults --label 'Session Transcript Tampering'
El match es por prefijo de la etiqueta y no distingue mayúsculas. En versiones anteriores, claude auto-mode defaults a secas te imprime las cuatro listas completas.
Referencia
Regla (soft_deny) |
Qué frena | Se abre cuando | Estado |
|---|---|---|---|
Irreversible Local Destruction |
git reset --hard, git clean -fd, git stash drop, rm -rf sobre archivos previos a la sesión |
nombras el objetivo o pides descartarlo | Ampliada (v2.1.178) |
Unverifiable Deletion Target |
rm -rf "$VAR"/* con $VAR sin resolver en el transcript |
nombras la ruta o la escribes literal en el comando | Nueva (v2.1.202) |
Session Transcript Tampering |
escrituras a los .jsonl de la sesión o forjar líneas {"meta"} |
prácticamente nunca (solo como falso positivo) | Nueva (v2.1.202) |
Cuando una de estas te bloquee, el motivo aparece junto a la acción en el transcript, en el aviso de denegación y en /permissions, pestaña "Recently denied". Ahí decides si el arreglo es reescribir el comando o reintentarlo con una intención explícita.
Requisitos
Auto mode activo. La ampliación de git destructivo llegó en la v2.1.178; el rm -rf sin resolver y la protección del transcript, en la v2.1.202. El flag --label necesita la v2.1.208 o superior.
Si aún no usas auto mode, empieza por Olvídate de los permisos en Claude Code sin caer en modo YOLO. Para ubicarlo entre los seis modos, Controla cuánta autonomía le das a Claude Code con los 6 modos de permisos.
Docs oficiales: Configure auto mode | Permission modes