If you've used a coding agent for more than a day, you know the rhythm.
It writes a command. It stops. It asks you to approve. You click yes.
It writes another command. It stops. It asks again.
By lunchtime you've clicked yes forty times, and you've quietly stopped reading what you're approving. At
that point the safety feature isn't protecting anything. It's just slowing you down.
There's a way to get the safety without the clicking, and it isn't a setting. It's where you run the agent.
What the approval prompt is really for
The prompt exists for one reason: the agent is about to run real code on your real computer.
Your SSH keys are on that computer. Your cloud credentials are on that computer. Six months of
uncommitted work is on that computer.
So the real question the prompt is asking you is: "Do you trust this command enough to let it run
**here?"
On your laptop, that's a great question.
Inside a container you can delete with one click, it's a question with no stakes.
Codex already ships the answer
Codex gives you three settings for exactly this. Straight from codex --help:
-
--ask-for-approval never— stop asking me -
--approve-for-me— have a second AI review it instead of me -
--dangerously-bypass-approvals-and-sandbox— turn off both the asking and the sandbox
That last one sounds like a bad idea, and the help text agrees with you. It says, in capitals:
EXTREMELY DANGEROUS.
But read the rest of the sentence:
EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.
Read that twice, because it's the whole point.
The person who wrote that flag isn't warning you away from it. They're telling you when to use it:
when the environment is already contained. Your laptop is not contained. A container is.
Same flag, completely different meaning, depending on which box it runs in.
Why "just turn them off" never felt safe
Because on your laptop, you're right not to. And if you've tried to make the prompts behave, you've
probably run into one of these:
- You allow a folder, and it still isn't trusted, even with the bypass flag on (#14345).
- "Allow for this session" is forgotten the moment you restart (#4212).
- You turn on Full Access, and it still asks anyway (#29235, #28988).
- Ordinary commands ask for approval in sandbox mode, so the sandbox does nothing but nag (#3140).
- Your MCP tools ask on every single call (#16911).
These aren't rare edge cases. The best-known thread on the topic has 77 comments and the title
"Unusable on Windows due to permission ask for every shell command"
(#2860).
The pattern is always the same: the prompts are annoying when they work, and broken when you try to
turn them off. That's not a bug in Codex. That's what happens when you put a security gate on a machine
that isn't designed to be a security boundary.
The middle option, if "off" feels too far
If you're not ready to go fully unattended, there's --approve-for-me. Instead of asking you, Codex asks
another model to review the command and lets the boring ones through automatically. Only the genuinely
weird stuff reaches you. (Internally this is the "guardian" reviewer, and it's a stable feature —
guardian_approval shows up in codex features list.)
It's a fair trade, but be honest about what it costs: every decision is another model call. You're
spending tokens so that you don't have to look. That's often worth it. It's just not free.
A container changes what all of this costs
Here's the same three settings, inside a disposable container:
| Setting | On your laptop | In a container |
|---|---|---|
| Ask me every time | safe, but exhausting | pointless — you'd be approving things that can't hurt you |
| Review with AI | a reasonable middle ground | fine, but you're paying for protection you mostly don't need |
| Never ask | reckless | the documented, intended use |
Once the box is disposable, "never ask" stops being a dare and starts being the sensible default. You
get no prompts, no waiting, and none of those loops where you say no, the agent re-plans, you say yes
anyway — and pay for all of it in tokens
(#14593 has 630 comments about exactly that kind of waste).
So the order of decisions matters:
First choose how much damage one bad command can do. Then choose how much freedom to give the agent.
Do it the other way around and your only two options are "too noisy" and "too risky."
What TaskHandoff does
TaskHandoff is an open-source (Apache-2.0) control plane for running AI/Codex workspaces across your
own machines. Every session runs inside a managed Linux Docker container that you create, start, stop
and throw away from one console.
That container is the "externally sandboxed environment" from the help text.
- Sessions run in a managed container, not on your desktop.
- Workspaces are things you own and control: create, snapshot, restore, delete, rebuild.
- Templates save a working toolchain once, so you don't rebuild it per project.
- Multiple machines, one console — run the heavy work on a Linux box and drive it from your laptop.
- Live session view over WebSocket.
You don't have to talk yourself into turning the prompts off. You just have to run the command somewhere
that was meant to be thrown away.
Quick start
curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh
Comes as a desktop app and a server (systemd on Debian/Ubuntu), with an English and Chinese UI.
One honest caveat
Full access means the container is now the thing keeping you safe — so it has to really be disposable.
Don't mount the only copy of your credentials into it, and don't use it as a password vault.
And if your task genuinely needs your host machine, or Windows-only tools, keep the prompts on. These
three settings aren't a religion. They're just tools, and now you know which one matches which box.
Top comments (1)
tr.ee/dev-to