Recientemente, al trastear con LLM CLI (del tipo Codex / Claude Code / Gemini CLI), descubrí que la “ejecución automática” no debería tener solo dos marchas: o preguntar en cada paso, o soltarse a lo loco. Tomando Codex como ejemplo, divide la automatización en dos modos más prácticos:
1) Automatización controlada: --full-auto (automático pero con límites)
La clave es “dar libertad dentro del proyecto y frenar al cruzar la línea”:
- Dentro del workspace puede modificar archivos y ejecutar comandos automáticamente, reduciendo confirmaciones frecuentes
- Si involucra archivos fuera del workspace (como
~/.zshrc,/etc/hosts) o acceso a la red, se detendrá para pedirte confirmación
Adecuado para la máquina principal de desarrollo del día a día: alta eficiencia y, a la vez, control en los puntos de riesgo clave.
2) Automatización al límite: --dangerously-bypass-approvals-and-sandbox (--yolo)
La clave es “omitir aprobaciones + desactivar el sandbox”:
- No pregunta, no bloquea, casi todo queda abierto
- El riesgo no está solo en romper el código (eso se puede revertir), sino más bien en acciones que Git no controla: configuración del sistema, instalación de software, descargar dependencias por red, etc.
Solo se recomienda usarlo por poco tiempo en Docker/máquina virtual/entornos desechables; destruirlo al terminar; no activarlo en la máquina principal ni en entornos de producción.
Complemento: querer menos ventanas emergentes no equivale a desactivar el sandbox
Si solo te molestan las confirmaciones demasiado frecuentes, puedes conservar el sandbox del workspace y ajustar únicamente la estrategia de aprobaciones (por ejemplo, preguntar menos dentro del proyecto y seguir bloqueando al cruzar límites).
Conclusión en una frase
Para el día a día usa “automatización controlada”; para experimentar, “YOLO”. Si puedes activar el sandbox, no lo desactives; si puedes mantener aprobaciones, no las quites.
Original: https://www.einverne.info/post/806.html