Every major AI lab now ships a command-line agent that runs on your machine with access to your files and shell. The deciding factor is which tasks you deliberately keep out of it. The deciding factor is simpler than most teams make it.
The Idea: Scope the Damage, Not the Capability
The better question when evaluating a terminal agent is blast radius: if this thing does exactly the wrong thing, what does it touch and how fast can you undo it? A web chat window has a blast radius of zero - the worst outcome is bad text you paste somewhere. A CLI agent with write access to a git repo has a blast radius of "whatever's uncommitted." The same agent with your production credentials in its environment has a blast radius of your business.
Blast radius is a property of the task, not the model. You can decide it in a planning meeting before anyone writes code. Refactoring tests in a throwaway branch? Low radius, high tolerance for a wrong turn - let the agent run. Editing an infrastructure config that deploys on merge? Same model, same prompt quality, completely different decision.
Real Example: Three Tiers, One Flag
A practical setup most CLI agents support in some form - approval modes plus a sandbox:
# Tier 1 - scratch work: let it run, git is the undo button
agent --mode auto-edit --cwd ~/experiments/parser-rewrite
# Tier 2 - real repo: propose diffs, human approves each write
agent --mode suggest --cwd ~/work/billing-service
# Tier 3 - anything with live credentials: read-only, no shell
agent --mode read-only --no-exec
The rule that makes this work isn't the flag - it's what decides the tier. Three questions, in order:
- Is it reversible in under five minutes? Committed git history, yes. A sent email or a dropped table, no.
- Does the environment hold live secrets? If the agent inherits your shell, it inherits your API keys. Check what's actually exported.
- Would a wrong answer be obvious? Broken tests fail loudly. A subtly wrong SQL filter in a revenue report does not.
Two "no" answers and the task doesn't belong in an autonomous loop yet - regardless of how good the model is.
Key Takeaways
- Judge AI agent tasks by blast radius (what breaks, how fast you recover) rather than by model capability, which changes too often to plan around.
- Reversibility, credential exposure, and error visibility are three checks any PM or engineer can apply before a single line of config is written.
- Approval modes and sandboxing aren't friction to work around - they're how you move fast on the low-radius 80% of work without betting the other 20%.
Which tasks have you already moved into an auto-approve loop - and what was the one that made you move it back out?
Sources referenced: Hacker News discussion on OpenAI CLI