safeshell

El problema

No es un problema de saber qué hace un comando — es un problema de contexto. Un rm -rf ~/proyecto es inofensivo en desarrollo y catastrófico si estás en el servidor de producción al que entras por SSH. El mismo comando, el mismo hábito muscular, consecuencias radicalmente distintas según dónde estás. Las herramientas de seguridad existentes o añaden fricción en todos los casos o requieren que recuerdes activar el modo "cuidado". safeshell lo infiere del contexto.

Los datos

Sin dataset: herramienta de sistemas. La entrada es el estado del proceso en el momento de ejecutar — directorio actual, variables de entorno, estado de git, tipo de sesión (local vs SSH, env de desarrollo vs producción).

Enfoque

• Hook de pre-ejecución en bash, zsh y fish: intercepta el comando antes de que llegue a la shell, sin modificar el PATH ni wrappers de binarios
• Análisis de contexto en tiempo real: ¿hay cambios sin commitear? ¿estás en SSH? ¿NODE_ENV es "production"? ¿el directorio está bajo git?
• Tres niveles de respuesta configurables por regla: avisar (log visible, el comando sigue), confirmar (espera sí/no explícito), bloquear (el comando no se ejecuta)
• Configuración declarativa en un fichero de reglas — sin tocar código, sin recompilar
• Cero telemetría: sin llamadas de red, sin logs externos, sin nothing — el binario no abre ningún socket

Herramientas

rust

Resultado

En uso diario desde hace meses. Las tres reglas que más veces me han salvado: confirmar rm -rf cuando la variable HOME está en el path, bloquear git push --force en cualquier rama que no sea una rama personal, confirmar git reset --hard cuando hay unstaged changes. Sin ninguna de ellas habría borrado cosas.