Claude Code ignora las prohibiciones de CLAUDE.md: qué mover a permissions y hooks

Escribió en CLAUDE.md «no borres datos sin que se te pida», y el agente los borró igualmente. No es un fallo raro: en el issue #46779 el autor se queja de que Claude Code borraba una y otra vez datos más allá de la tarea, aunque la prohibición estaba escrita explícitamente. Un análisis en Habr propone una forma clara de pensar en ello: una regla debe vivir donde el coste de incumplirla esté justificado.

Por qué el texto no basta

CLAUDE.md se carga al inicio de cada sesión, y Claude Code lo vuelve a leer tras compactar la conversación. Parecería que la regla está siempre en el contexto. Pero el problema no es la memoria. En el benchmark StateTrack-Bench de EMNLP 2026, los autores atribuyeron el 88,6% de los fallos en conversaciones largas a la deriva de comportamiento: el modelo recuerda la restricción, pero deja de seguirla. Microsoft Research añade un contexto general: en los modelos de primer nivel, la calidad en conversaciones de varios turnos es en promedio un 39% inferior a la de un solo turno.

Anthropic reconoce con franqueza en su documentación que una instrucción del tipo «nunca hagas X» se cumple en la mayoría de los casos, pero bajo presión, en una sesión larga, en una situación ambigua o ante una prompt injection puede incumplirse. Aquí, prompt injection significa una instrucción ajena dentro de un archivo que el agente abrió por la tarea.

Dividir las reglas según el coste del error

Si el error cuesta minutos, basta una línea de texto. Si cuesta dinero, expone claves o inicia trabajo sin confirmación, hace falta código. Hay tres herramientas:

• permissions: las reglas allow, ask y deny determinan qué hace el agente por sí solo, sobre qué pregunta y qué tiene prohibido;
• hooks: comandos de shell que Claude Code ejecuta ante un evento de la sesión, por ejemplo antes de escribir un archivo o al intentar terminar un turno;
• una comprobación por código antes del arranque, por ejemplo un script que no inicia el trabajo sin un archivo con un plan confirmado.

Un ejemplo de la práctica del autor: un comando de una herramienta de navegador gastaba créditos de pago. Se bloqueó con una regla deny en .claude/settings.json, en lugar de una petición en texto. Conviene subir el archivo de configuración a git para que todo el equipo reciba las reglas. Un detalle importante de un comentario del issue #65563: una protección que solo mira los comandos Bash no verá una llamada a través de MCP. En el propio issue se pidió al agente que investigara un bug, y mediante la automatización del navegador pulsó borrar y confirmar sobre un registro real de una base de datos de producción.

Con las claves ocurre algo parecido. Un deny sobre la lectura de .env cierra el archivo, un hook de escritura rechaza un cambio que contenga una clave, pero la salida de un secreto desde el entorno no queda cubierta por estas dos reglas. Una clave expuesta no se puede recuperar, por lo que no se protege solo con texto.

El hook Stop contra el trabajo sin terminar

Para que el agente no termine su turno mientras la comprobación no pase, se asocia al evento Stop un script que ejecuta la verificación del proyecto (por ejemplo, make check) y, si falla, sale con código 2. El código 2 bloquea la finalización, y stderr llega al agente como mensaje de error. El código 1 sin salida no bloquea la acción; Caprock lo comprobó en las versiones 2.1.289 y 2.1.299. Desde la 2.1.295, la opción onFailure: block bloquea la acción incluso cuando falla el propio hook.

Hay un límite: tras ocho bloqueos seguidos sin llamadas a herramientas, Claude Code termina el turno de todos modos. El umbral se eleva con la variable CLAUDE_CODE_STOP_HOOK_BLOCK_CAP, y en tareas largas conviene comprobar si el hook choca con él.

Qué hacer

Considere CLAUDE.md un registro de fallos, no una declaración. Añada una línea tras el segundo fallo idéntico, mantenga el archivo por debajo de 200 líneas, asigne un responsable y revise los cambios como código. Una entrada obsoleta perjudica más que su ausencia.

Una limitación del enfoque: los ejemplos del artículo son ilustrativos, y la sintaxis exacta debe contrastarse con la página Configure permissions de la documentación. La pregunta principal para su proyecto es sencilla: ¿qué tres reglas de su archivo cuestan dinero o secretos? Pase primero esas a deny, hooks y comprobaciones por código.