Cómo dejé de tener miedo a Claude Code y aprendí a amar los Guard Hooks

Imagina esto: estás cómodamente sentado en tu sillón, sipping coffee, mientras tu agente de IA favorito (ya sea Claude Code, Cursor o GitHub Copilot CLI) informa alegremente sobre completar una tarea de refactorización. De repente, rm -rf o, aún más gracioso, sudo rm -rf / aparece en la terminal. El café se te atraganta y horas de trabajo no remunerado — esos cambios que aún no has hecho commit — se evaporan en el olvido digital.

¿Sensación familiar de impotencia ante las "alucinaciones" de las redes neuronales? En mi práctica, estos momentos ocurrieron un par de veces, y cada vez fue una lección dolorosa. Por eso el proyecto destructive_command_guard (o simplemente dcg) inmediatamente captó mi atención. No es una "plataforma revolucionaria", solo un perro guardián muy rápido y audaz para tu terminal.

Qué es esta bestia

En resumen, dcg es un hook de alto rendimiento escrito en Rust. Intercepta el proceso de comunicación entre tú (o tu agente de IA) y la línea de comandos. Su única tarea es interceptar un comando destructivo antes de que tenga la oportunidad de romper algo.

La herramienta soporta prácticamente todo lo que está de moda actualmente en el mundo del desarrollo con IA: Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor IDE, Grok e incluso opciones más exóticas como Hermes Agent. La utilidad funciona en Linux, macOS y Windows (vía WSL o nativamente vía PowerShell).

Por qué un grep normal no te salvará

Podría parecer, ¿por qué construir todo un proyecto en Rust cuando puedes escribir un simple script en Bash o Python? El autor del proyecto, Jeffrey Emanuel, tomó ese camino: la primera versión estaba en Python. Pero rápidamente quedó claro que las tareas modernas requieren un enfoque más matizado.

El contexto lo es todo

dcg no solo busca la cadena rm -rf. Analiza el contexto. Si un agente escribe "don't use rm -rf /" en la documentación, el hook entenderá que esto es datos y no bloqueará la escritura del archivo. Pero tan pronto como se trate de ejecutar el comando realmente — el bloqueo entra en acción.

Para esto, se utiliza un sistema de verificación de tres niveles:

1. Búsqueda rápida de subcadenas (Quick Reject) mediante instrucciones SIMD. Esto toma microsegundos.
2. Normalización de comandos (se eliminan espacios extra, las rutas absolutas se reemplazan por relativas).
3. Verificación contra patrones complejos usando expresiones regulares.

Protección contra amenazas "ocultas"

Una característica interesante — escaneo de Heredocs y scripts inline. Si un agente decide llamar a rm -rf, un simple filtro de línea de comandos lo dejará pasar. dcg profundiza dentro de tales constructos, los analiza usando AST (Abstract Syntax Trees) y encuentra llamadas a funciones sospechosas.

Qué exactamente bloquea

De fábrica, incluso si no has configurado nada, dcg protege contra las cosas más aterradoras:

• rm -rf, sudo rm -rf /, dd if=/dev/zero.
• git push --force fuera de carpetas temporales.
• Formateo de disco, eliminación de particiones y otras delicias del sistema.

Pero lo mejor son los "packs" (paquetes de seguridad). Hay más de 50 en el repositorio. Puedes activar la protección para tecnologías específicas en tu dcg.toml:

[packs]
enabled = [
    "database.postgresql",    # Заблокирует DROP TABLE
    "kubernetes.kubectl",     # Не даст удалить namespace по ошибке
    "cloud.aws",              # Спасет от случайного terminate-instances
    "containers.docker",      # Ограничит docker system prune
]

Cómo se ve en la práctica

Digamos que tu agente decidió perder el control y restablecer todos los cambios. Verás algo así en la terminal:

════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes

Command: git reset --hard HEAD~5

Tip: Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════════════

El bloqueo viene con consejos útiles. En la mayoría de los casos, el agente, habiendo recibido tal rechazo, se da cuenta del error y sugiere un camino más seguro, por ejemplo, usando git stash.

Tripas técnicas y rendimiento

Lo que me conquistó fue el enfoque en el rendimiento. El autor afirma latencia por debajo del milisegundo. Para los que les gustan los detalles:

• Rust + SIMD: se utilizan instrucciones vectoriales del procesador para búsqueda ultrarrápida de palabras clave.
• Motor Dual de Regex: los patrones simples son manejados por un motor rápido con tiempo de ejecución lineal, mientras que los complejos (donde se necesitan lookaheads/lookbehinds) son procesados por un regex más potente pero más lento.
• Sin asignación: en rutas críticas, el programa intenta no asignar memoria heap, lo cual es crítico cuando el hook se invoca en cada pulsación de tecla o comando del agente.

Por cierto, el proyecto implementa una filosofía de fail-open. Si dcg no tiene tiempo de analizar el comando dentro del presupuesto de tiempo asignado (200ms por defecto), lo deja pasar. Esto se hace para que la herramienta nunca se convierta en un "freno" que obstaculice el trabajo normal. En mi opinión, un compromiso razonable entre seguridad y comodidad.

Cómo integrar en tu flujo de trabajo

La forma más fácil de probarlo es ejecutar el script de instalación del README. Determinará tu SO, descargará el binario correcto y configurará los ajustes en las configs de los agentes de IA.

Para Claude Code, se ve como agregar una sección a claude_desktop_config.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "dcg" }]
      }
    ]
  }
}

Y si trabajas en equipo y quieres asegurarte de que nadie hizo commit de un git push --force destructivo o un pipeline de CI roto, hay un modo de escaneo:

dcg scan --staged

Puedes conectarlo a un pre-commit hook, y verificará todos los archivos que intentas subir a Git.

Algunas palabras sobre las desventajas

No existen herramientas perfectas. ¿Qué puede salir mal?

1. Falsos positivos: A pesar del análisis avanzado, a veces dcg puede bloquear comandos perfectamente legítimos. Para este caso, hay una "salida de emergencia" vía la variable de entorno DCG_BYPASS o el sistema DCG_UNLOCK_CODE.
2. Complejidad de configuración: Si necesitas algo específico, tendrás que profundizar en los configs TOML.
3. Rust Nightly: Si quieres compilar el proyecto desde el código fuente tú mismo, necesitarás la versión nightly de Rust, ya que se usan características de la edición 2024.

Quién necesita esto

Si usas agentes de IA más de una vez por semana y les confías la ejecución de comandos en la terminal — instálalo sin dudarlo. Es un seguro barato. Esto es especialmente relevante para principiantes que podrían no notar inmediatamente que el comando de "limpieza de caché" sugerido por la red neuronal en realidad borra la mitad del sistema.

Para desarrolladores experimentados, es más bien una forma de ahorrar nervios. Todos sabemos lo fácil que es presionar Ctrl+C en piloto automático, y luego recordar frenéticamente cuándo fue el último backup.

dcg es esa herramienta que corre silenciosamente en segundo plano y "no pide comida" hasta que llega un momento crítico. No hace magia, solo analiza bien las cadenas y sabe cómo son los comandos malos. En un mundo donde cada vez delegamos más la escritura y ejecución de código a las máquinas, tales "fusibles digitales" se están convirtiendo en un atributo obligatorio del entorno de trabajo.

Vale la pena probarlo al menos para ver lo rápido que es el software moderno en Rust. ¿Y tú alguna vez le has confiado a tu IA eliminar archivos? ¿Cómo terminó eso?