When I’ve been tinkering with LLM CLIs lately (Codex / Claude Code / Gemini CLI and the like), I realized that “auto-execution” shouldn’t be just two settings: either ask on every step, or go completely hands-off. Taking Codex as an example, it breaks automation down into two more practical modes:
1) Controlled automation: --full-auto (automatic, but with boundaries)
The core idea is “open up within the project, brake when crossing the line”:
- Within the workspace, it can automatically edit files and run commands, reducing frequent confirmations
- When it involves files outside the workspace (such as
~/.zshrc,/etc/hosts) or network access, it will stop and ask you to confirm
Suitable for a daily primary development machine: high efficiency, while key risk points stay controllable.
2) Extreme automation: --dangerously-bypass-approvals-and-sandbox (--yolo)
The core idea is “skip approvals + disable the sandbox”:
- No questions, no blocking, almost everything allowed
- The risk isn’t just breaking code (that can be rolled back), but system configuration changes, installing software, pulling dependencies over the network, and other actions that Git can’t manage
Only recommended for short-term use in Docker/VMs/disposable environments—destroy it after use; don’t enable it on your primary machine or in production.
Add-on: wanting fewer pop-ups doesn’t mean you should disable the sandbox
If you’re just annoyed by confirmations being too frequent, you can keep the workspace sandbox and only adjust the approval policy (for example: ask less within the project, still block when going out of bounds).
One-sentence conclusion
Use “controlled automation” day-to-day, “YOLO” only for experiments; if you can enable the sandbox, don’t turn it off—if you can keep approvals, don’t disable them.
Original: https://www.einverne.info/post/806.html