hermes approvals test: pregunta al sistema de aprobaciones antes de ejecutar ese comando

Estás a punto de añadir un comando de limpieza a un script que el agente ejecutará sin supervisión, y hay una pregunta que no puedes responder mirando el código: ¿dejará Hermes que pase? Adivinar significa o un prompt de aprobación a mitad de ejecución sin nadie que lo conteste, o un comando que se ejecutó en silencio cuando esperabas que estuviera bloqueado. v0.21.0 incluye la herramienta obvia para esto: hermes approvals test hace una prueba en seco de cualquier comando contra los guardas de aprobación reales — la blocklist de línea dura, tus reglas approvals.deny, la detección de patrones peligrosos, la allowlist, incluso el bypass yolo/off — e imprime el veredicto sin ejecutar nada, sin preguntar a nadie ni persistir nada.
El veredicto en tres códigos de salida
hermes approvals test -- rm -rf /tmp/x
El -- importa: detiene el análisis de flags para que los propios flags del comando (como -rf) no los consuma hermes approvals mismo. La salida te dice el veredicto, qué regla coincidió y el rastro del comando normalizado — la misma normalización que aplica la puerta real. Los scripts reciben la respuesta como código de salida:
- 0 — permitir
- 2 — pedir aprobación (mostraría un prompt)
- 3 — denegar (blocklist de línea dura o tu propia regla de denegación)
De modo que puedes conectarlo a una comprobación previa al vuelo: un script de deploy que se niega a continuar si un paso quedaría bloqueado, un trabajo cron que falla ruidosamente antes de ejecutar un comando que la puerta detendría de todos modos, o una pasada de auditoría que grepea tus scripts en busca de cualquier cosa que mostraría un prompt en un contexto sin supervisión.
Qué evalúa realmente
La prueba en seco ejecuta la misma cadena de decisión que un comando real, incluyendo:
- la blocklist de línea dura (comandos denegados incondicionalmente),
- tus globs fnmatch de
approvals.deny(consulta nuestra guía de configuración de aprobaciones inteligentes para el schema), - la detección de patrones peligrosos (borrados recursivos, sudo, escrituras en disco, edición de credenciales, …),
- la allowlist de comandos (comandos que ya has bendecido),
- y el bypass yolo/off si ejecutas con esos modos (modos yolo explicados).
Dos flags afinan la comprobación: --env-type le dice contra qué backend de terminal evaluar (por defecto local; los backends de contenedor aislados como docker se saltan los guardas, así que un comando que está bien en un contenedor puede pedir aprobación en local — conviene saberlo antes de escribir el script), y --json da salida legible por máquina.
El comando extra: hermes approvals suggest
hermes approvals test responde «¿qué pasaría?»; su hermano hermes approvals suggest responde «¿qué debería permitir?». Extrae tus decisiones de aprobación pasadas de la base de datos de sesiones, clasifica los patrones recurrentes y propone entradas de command_allowlist — no se escribe nada salvo que las apliques:
hermes approvals suggest # revisa las propuestas numeradas
hermes approvals suggest --apply 1,3,7 # fusiona las elegidas en config.yaml
Opciones: --days (cuánto hacia atrás escanear, 90 por defecto), --min-count (aprobaciones mínimas para un patrón, 2 por defecto), --limit, --db (base de datos de sesiones alternativa), --json. Las clases destructivas (borrado recursivo, sudo, escrituras en disco, edición de credenciales, …) nunca se proponen — la herramienta no va a sugerir permitir lo que existe para vigilar. Esto encaja perfectamente con las aprobaciones sin supervisión para contextos de cron.
Cuándo recurrirás a esto
Tres momentos destacan. Antes de escribir automatización: comprueba cada paso arriesgado una vez, y o lo bendices deliberadamente o gestionas la ruta del prompt. Auditoría: hermes approvals test -- <cmd> sobre un comando sospechoso te dice exactamente qué regla lo atrapa — sin ejecuciones de prueba. Aprender el sistema: el rastro normalizado te muestra cómo ve Hermes realmente tu comando, que es la forma más rápida de entender por qué un one-liner de shell que creías inocente activa la puerta. v0.21.0 también endureció toda la superficie de aprobaciones (los comandos destructivos de Windows ahora la activan, los archivos de instrucciones protegidos siempre requieren aprobación) — las notas de la versión cubren el panorama completo en /releases/v0-21-0/.