Cómo Destructive Command Guard protege Codex: intercepta comandos peligrosos de Git y Shell

Una vez que el agente de programación de IA puede ejecutar el shell, uno de los mayores riesgos no es escribir el código incorrecto, sino ejecutar comandos de eliminación, sobrescritura o limpieza de Git en el directorio incorrecto. Destructive Command Guard, denominado dcg, se utilizará como herramienta para llamar comandos de inspección previos al Hook para interceptar operaciones de alto riesgo antes de su ejecución.

Dirección del proyecto: Dicklesworthstone/destructive_command_guard

Respuesta rápida

dcg es compatible con Codex CLI, Claude Code, Gemini CLI, Copilot CLI, Cursor y otras herramientas. Es adecuado como línea de defensa adicional, pero no es un entorno limitado completo: el Agente aún puede escribir operaciones peligrosas en el script y parte de la ruta de ejecución también puede pasar por alto el Hook.

Instalación rápida para Linux, macOS y WSL:

1

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

Primero se deben revisar los scripts de instalación remota. El instalador descarga el binario de plataforma correspondiente, verifica el hash y fusiona la configuración de Agent Hook compatible en lugar de sobrescribir directamente el JSON válido existente.

Cómo funciona en Codex

Para Codex CLI que admite Hooks, el instalador fusionará el Hook PreToolUse en ~/.codex/hooks.json. Una vez completada la instalación, abra la interfaz /hooks de Codex una vez para confirmar la confianza.

Cuando el Agente esté listo para ejecutar un comando, dcg:

Analice el JSON llamado por la herramienta;
Extraer y normalizar los comandos de Shell;
Elimine rápidamente los comandos obviamente seguros;
Utilice reglas para identificar riesgos como eliminación, sobrescritura y reinicio forzado;
Devolver Permitir, Denegar o requerir confirmación manual.

Agregar escaneo previo a la confirmación al repositorio

Además de los Hooks en tiempo real, también se pueden escanear los scripts y los flujos de trabajo que se enviarán:

1
2
3


dcg scan install-pre-commit
dcg scan --staged
dcg scan --paths scripts/ .github/workflows/

Cuando el equipo importa, se recomienda adoptar primero la estrategia conservadora de “fallar con alta gravedad”, observar falsos positivos y luego expandirse a Makefiles, Dockerfiles y más scripts de Shell.

Cómo verificar después de la instalación

No pruebes con un comando de eliminación real. Puede hacer que el Agente interprete un comando simulado obviamente peligroso y observe si el Hook da un mensaje de bloqueo antes de ejecutarlo. Luego revisa:

Si dcg está ubicado en PATH;
Si la configuración del Hook del Agente es JSON válida;
/hooks Si mostrar y confiar en este Hook;
Si el Hook original todavía existe;
Si no hay un retraso notable en los comandos normales de sólo lectura.

Diferencias en métodos y plataformas de instalación.

Los instaladores de Shell están disponibles para Linux, macOS y WSL. Windows nativo debe usar install.ps1 proporcionado por el repositorio y no imponer comandos Bash en PowerShell.

Recomendaciones antes de la instalación:

Abra el script para verificar la dirección de descarga;
Haga una copia de seguridad de la configuración del Hook del Agente;
Registre el PATH existente;
Confirme la versión de instalación y el mecanismo de verificación;
Ejecútelo primero en una cuenta o entorno de prueba;
Verifique las diferencias de configuración después de la instalación.

El modo fácil intenta detectar y configurar automáticamente los agentes compatibles. Es más adecuado para un entorno de equipo usar --no-configure para instalar primero solo el binario y luego revisar manualmente la combinación de Hook de cada herramienta.

Verificación completa del Codex Hook

La nueva CLI del Codex utiliza el gancho PreToolUse en ~/.codex/hooks.json. Una vez completada la configuración:

Confirmar que JSON se puede analizar normalmente;
Verificar que los Hooks originales no hayan sido eliminados;
Abrir /hooks en el Codex;
Confía explícitamente en dcg Hook;
Probar el proceso de bloqueo con solicitudes simuladas no destructivas;
Ver si los comandos normales aún pasan.

Si no se muestra /hooks, no asuma que la protección está vigente. Verifique la versión del Codex, la compatibilidad con funciones y la ruta de configuración real.

¿Qué comandos se interceptan fácilmente?

dcg se centra en operaciones de Git y Shell que pueden causar daños irreparables, como eliminaciones recursivas, limpiezas forzadas, sobrescritura del historial y comandos peligrosos dirigidos a directorios amplios. Las reglas actuales se actualizarán y la versión actual debería prevalecer.

Si un comando es peligroso depende no sólo del nombre del comando, sino también de los parámetros y objetivos:

1
2
3
4


rm file.tmp                 范围明确，可能允许
rm -rf /broad/path          范围宽且不可恢复，应阻止
git status                  只读
git reset --hard            会丢弃修改，应阻止或确认

No divida un comando en pasos más sutiles para evitar falsos positivos. Las reglas deben revisarse, utilizar objetivos claros o dejarse en manos de la ejecución humana.

Cómo se utiliza el patrón de escaneo en las bases de código

El Hook en tiempo real protege el comando que el Agente se está preparando actualmente para ejecutar y dcg scan verifica la posible ejecución de fragmentos de Shell en el repositorio, incluidos scripts, flujos de trabajo de CI, Dockerfiles y Makefiles.

Sugerencias de importación por primera vez:

1

dcg scan --staged --fail-on error

Solo permita que los problemas críticos de alta confianza bloqueen los envíos. Después de observar durante un período de tiempo, amplíe el alcance a:

1

dcg scan --paths scripts/ .github/workflows/

No establezca todas las advertencias como fallas de CI el primer día; de lo contrario, los falsos positivos harán que el equipo apague la herramienta directamente.

Responsabilidades del Hook y CI previos al compromiso

Compromiso previo local

La retroalimentación es rápida, adecuada para descubrir nuevos comandos peligrosos antes de enviarlos, pero los usuarios pueden usar --no-verify para omitirlos o es posible que no tengan Hook instalado.

Escaneo CI

La ejecución uniforme por parte del repositorio es más adecuada para formar reglas obligatorias. La versión dcg debe corregirse en CI, se debe verificar la descarga y solo se debe escanear esta diferencia o ruta para evitar que los resultados cambien con el flujo ascendente.

Uso previo de la herramienta del agente

Bloquear antes de la ejecución del comando, protegiendo el espacio de trabajo actual. No reemplaza la inspección continua que realiza CI del contenido del repositorio.

Las tres soluciones tienen diferentes momentos y se pueden utilizar al mismo tiempo.

Cómo administrar la lista de permitidos

Algunos proyectos requieren limpiar el directorio de compilación o restablecer el entorno de prueba. En lugar de cerrar todo el dcg, cree excepciones mínimas para comandos verificables y con un alcance bien definido:

Permitir sólo directorios temporales específicos dentro del proyecto;
No utilice variables de entorno para unir rutas de raíz amplias;
Primero analiza y genera la ruta absoluta;
No hay excepciones permanentes a los catálogos de producción;
Excepciones en el control de versiones y revisión de código;
Eliminar periódicamente las reglas que ya no sean necesarias.

El objetivo de las excepciones de seguridad es reducir los falsos positivos, no permitir que el Agente obtenga una omisión general.

Cómo realizar pruebas sin destruir datos

No realice git reset --hard ni eliminación recursiva en el repositorio real. Puede utilizar un repositorio de prueba temporal y parámetros de comando ficticios para observar el resultado del análisis de dcg. Las pruebas incluyen al menos:

Se permiten comandos ordinarios de solo lectura;
Se bloquean las órdenes evidentemente peligrosas;
Los comandos de limpieza con un alcance de destino claro se procesan como se esperaba;
Illegal Hook JSON no se publicará silenciosamente;
Ingrese la confirmación manual cuando se agote el tiempo o no se pueda juzgar;
El Hook original todavía funciona normalmente.

¿Por qué Hook no es un sandbox completo?

Un Hook solo puede inspeccionar las llamadas a herramientas que ve. Aún se pueden omitir las siguientes rutas:

El agente escribe el script y luego lo ejecuta mediante otros procesos;
El IDE o complemento utiliza una interfaz de terminal que no está conectada;
El programa elimina recursos de la nube a través de API;
Los comandos en el contenedor afectan el directorio del host montado;
Operar en otra máquina después de que las credenciales estén comprometidas;
El usuario utiliza activamente --no-verify.

Por lo tanto, los permisos del sistema operativo, los montajes de contenedores, la IAM en la nube, las copias de seguridad y las aprobaciones aún deben estar presentes.

Actualizar y revertir

Disponible:

1

dcg update

Los equipos no deben actualizar automáticamente las reglas en todas las máquinas de desarrollo sin un plan. Primero verifique los falsos positivos y la compatibilidad de la nueva versión en el repositorio de prueba y luego actualícela en lotes. La reversión requiere conservar el número de versión anterior y la copia de seguridad de la configuración.

Matriz de resolución de problemas

Fenómeno	Posibles causas	Tratamiento
`dcg` no encontrado	RUTA no actualizada	Abra una nueva terminal y verifique el directorio de instalación
Codex no llama a Hook	Error de versión o `hooks.json` ruta	Verifique `/hooks` y configuración
El gancho original desaparece	Excepción de fusión	Restaurar copia de seguridad y fusionar manualmente
Se interceptan comandos ordinarios	Regla falsos positivos	Limitar el alcance del comando y reportar el caso
Los guiones peligrosos no son interceptados	La ruta de ejecución real no es visible	Se agregó escaneo, permisos y sandbox
Los resultados de CI son inestables	Usando versiones flotantes	Versiones y reglas fijas de dcg

Lo que no resuelve

Los ganchos no son límites de permisos del sistema operativo. El funcionario también recuerda que el Agente puede escribir el script primero y luego ejecutarlo, y es posible que algunas de las rutas de ejecución unificadas del Codex no puedan interceptarse por completo. Por lo tanto, todavía se requiere cooperación:

Cuenta de no administrador;
Limitar el directorio de trabajo;
Rama de Git o árbol de trabajo;
Copia de seguridad de datos importantes;
Aprobación manual de operaciones de eliminación y inserción;
Aislamiento de contenedor o máquina virtual.

Preguntas frecuentes

¿El instalador sobrescribirá mis Hooks?

La implementación oficial intentará fusionarse; Si el JSON existente no es válido o tiene una estructura anormal, se conservará el archivo original y se informará un error. Aún se debe realizar una copia de seguridad de la configuración antes de la instalación.

¿Por qué no se bloquean los comandos peligrosos?

Compruebe si el comando toma una ruta de enlace compatible. Si el Agente encapsula la operación en un script, una herramienta interna de la aplicación o una interfaz de ejecución que no está cubierta, es posible que dcg no vea el comando final.

¿Dcg ralentizará significativamente cada comando?

El proyecto está diseñado como un gancho rápido y establece un límite superior absoluto en el tiempo de procesamiento. La latencia real aún debe medirse en su propio terminal y conjunto de reglas; Si se nota una desaceleración, revise los registros y otros ganchos.

¿Se puede instalar solo en CI y no en la máquina de desarrollo?

El contenido del repositorio se puede escanear, pero el agente local no puede interceptar el comando antes de que se ejecute realmente. Todavía se recomienda configurar PreToolUse Hook en entornos de agentes con altos privilegios.

¿Cómo manejar las interceptaciones falsas en situaciones de emergencia?

Confirme el propósito y la capacidad de recuperación del comando antes de ejecutarlo manualmente o crear excepciones temporales mínimas. No permita que el Agente encuentre desvíos automáticamente.

Resumen

dcg puede reducir la probabilidad de que el Agente ejecute accidentalmente comandos peligrosos de Git y Shell, especialmente adecuado para entornos que ya permiten que Codex o Claude Code ejecuten terminales. Pero debería considerarse como un cinturón de seguridad, no como una caja fuerte; la solución verdaderamente confiable sigue siendo la combinación de privilegios mínimos, aislamiento de directorio, copia de seguridad y aprobación manual.