Fix Approval Loops in Headless AI Coding Agents
The bug was not that headless AI coding agents needed approval. The bug was that the approval prompt had nowhere useful to go.
When a command-line coding agent runs inside a dashboard, automation, or browser workflow, a terminal prompt can become a silent brake.
The agent waits. The dashboard looks alive. The job never finishes.
Agent OS, the operations dashboard I use to run agent-built business systems, fixed that by turning approvals into explicit sandbox modes.
The modes are plain: Auto-approve for routine work, Ask/read-only for inspection, and YOLO for isolated runs where speed beats interruption.
That sounds like a small product setting. It is not. It is the line between a useful coding worker and an expensive spinner.
Why do headless AI coding agents get stuck on approvals?
Headless AI coding agents get stuck when the agent asks for permission through a user interface that the operator cannot see or answer.
A local terminal can pause and show a prompt. A dashboard job, queue worker, cron run, or browser-triggered task often cannot.
The agent may be doing the right thing by asking before editing files, installing packages, or touching network access.
The product problem is that safety has been routed through an interface that does not exist in the workflow.
Codex, OpenAI’s command-line coding agent, documents that approval policy controls when Codex pauses before commands; checked 5 August 2026: Codex config reference.
Codex also documents sandbox levels such as read-only, workspace-write, and danger-full-access for filesystem and network access.
Those controls are sensible. The failure appears when a product embeds the agent but does not decide what should happen to the prompt.
In Agent OS, I was not trying to make the agent reckless. I was trying to stop invisible prompts from pretending to be progress.
What did Agent OS actually change?
Agent OS changed approvals from an implied terminal event into a visible operating mode chosen before the agent starts.
The operator no longer has to guess whether a run will pause. The mode tells the system how much freedom the coding agent has.
Before the change, the agent workflow treated permission prompts as something the underlying tool would handle.
That works in a terminal. It breaks when the agent is launched from a dashboard card, job queue, or automated build flow.
After the change, the dashboard can set the run posture directly. A review run can be read-only. A normal edit can allow workspace writes.
A high-speed isolated run can remove prompts, but only when the operator accepts the larger blast radius.
The product lesson is simple: approval behaviour belongs in the workflow contract, not buried inside the tool invocation.
For me, that was the point. I am not a developer by trade. I need agents that operate the business better, not agents that need babysitting.
Which sandbox modes solve Codex approval loops?
The practical modes are Auto-approve, Ask/read-only, and YOLO. Each mode trades speed, safety, and control differently.
Auto-approve is the normal workhorse. Ask/read-only is for inspection and planning. YOLO is for contained execution where prompts must not block.
| Agent OS mode | Best use | Main risk | Operator rule |
|---|---|---|---|
| Auto-approve | Routine repo edits | Bad change lands in workspace | Use tests and review |
| Ask/read-only | Audits and planning | Slow hand-off | Use before risky work |
| YOLO | Disposable sandboxes | Broad file access | Isolate first |
The table says the tradeoff plainly: Auto-approve optimises flow, Ask/read-only optimises control, and YOLO optimises speed inside a bounded environment.
OpenAI’s non-interactive Codex docs say codex exec runs in a read-only sandbox by default and advises least permissions for automation; checked 5 August 2026: Codex non-interactive mode.
The same OpenAI page says danger-full-access should be used only in a controlled environment such as an isolated runner or container.
That maps closely to the Agent OS decision. Do not ask every time. Do not approve everything everywhere. Choose the right lane first.
When should Auto-approve be the default?
Auto-approve should be the default for routine, reversible code work inside a trusted workspace with tests and review.
The goal is not to remove safety. The goal is to stop predictable actions from becoming manual interruptions.
A coding agent needs to read files, edit files, run tests, inspect errors, and try again.
If every safe command becomes a prompt, the agent stops being a worker and becomes a remote-controlled terminal.
In Agent OS, Auto-approve is suited to tasks such as small component fixes, copy changes, test repair, lint cleanup, and branch-level implementation.
The guardrail is scope. Auto-approve should operate inside the workspace, not across the whole machine.
The other guardrail is review. The agent can make the change, but the final business decision still belongs to the operator.
Auto-approve becomes dangerous when it touches secrets, billing, production data, deployment keys, or destructive scripts.
If a task could harm the business faster than a reviewer can notice, Auto-approve is the wrong mode.
When should Ask/read-only be used?
Ask/read-only should be used when the agent needs to inspect, explain, plan, or diagnose before any write action is allowed.
This mode is slower by design. The point is to get a safe answer before granting the agent a keyboard with write access.
I use this posture when I do not yet trust the task description, the repository state, or the likely fix.
A read-only pass can map the codebase, identify files, explain risk, list tests, and propose the smallest safe change.
That gives the operator a useful decision: approve a scoped edit, rewrite the task, or stop before anything changes.
Ask/read-only is also useful when a non-technical operator needs plain English before committing to an engineering action.
The agent can say, “this will touch authentication,” or “this needs a migration,” before the mode changes.
That is not friction. That is the product making risk visible while the cost of stopping is still low.
When is YOLO mode acceptable?
YOLO mode is acceptable only when the environment is disposable, the blast radius is bounded, and the task is worth uninterrupted execution.
YOLO is not a personality setting. YOLO is an infrastructure promise that the agent cannot damage anything important.
In plain terms, YOLO should mean the run is inside a throwaway checkout, container, virtual machine, or isolated runner.
The agent may need broad access to install dependencies, rewrite files, run generators, or perform a noisy refactor.
That can be reasonable when the output is a diff, a branch, a patch, or a report that a human reviews later.
It is not reasonable when the agent has credentials, production access, private customer data, or deployment authority.
OpenAI’s Codex security page is the right place to start for the vendor’s own sandboxing and approvals model; checked 5 August 2026: Codex security docs.
My rule is blunt: if YOLO can break the real business, the sandbox is not a sandbox yet.
How should builders design approval modes for headless AI coding agents?
Builders should design approval modes before they design the prompt UI. The mode should decide what happens when the agent wants more access.
A useful approval system has a default, a safe fallback, and an explicit high-risk escape hatch.
Start with the task class. Is the agent reading, editing, installing, deploying, deleting, or touching external systems?
Then choose the mode based on consequence, not convenience.
| Task type | Recommended mode | Why |
|---|---|---|
| Codebase audit | Ask/read-only | No writes needed |
| Small fix | Auto-approve | Fast and reviewable |
| Dependency install | Auto-approve or YOLO | Needs containment |
| Data migration | Ask/read-only | High consequence |
| Bulk refactor | YOLO in isolation | Many write actions |
In prose, the same comparison is this: read-only fits investigation, Auto-approve fits bounded implementation, and YOLO fits disposable execution.
Do not rely on the agent to infer that policy. The dashboard, runner, or orchestration layer should set it.
The agent prompt can explain the task. The operating mode should control the permissions.
What should happen when an approval would have appeared?
When an approval would have appeared, the system should either auto-deny, auto-approve within policy, or stop with a visible reason.
The worst outcome is a silent wait. A blocked agent should become a clear state, not a mystery.
Agent OS treats the mode as part of the run setup so the dashboard can show a useful status.
If a read-only run needs a write, the right result is not hanging. The right result is a message that says the task needs a different mode.
If an Auto-approve run hits a forbidden path, the run should fail cleanly and explain what exceeded the policy.
If a YOLO run fails, the failure should still be captured in logs and output, because no-prompt does not mean no-audit.
That audit trail matters to me because the agent is building systems I actually use to operate a business.
A finished run must tell me what changed, what failed, what was skipped, and what needs review.
What implementation checklist prevents approval loops?
The checklist is simple: classify the task, choose the mode, bound the workspace, record the run, and make blocked permissions visible.
That checklist turns approval handling into a repeatable engineering decision.
- Define the task class before launching the agent.
- Default investigation work to read-only access.
- Allow workspace writes only for bounded implementation.
- Use YOLO only inside disposable environments.
- Keep secrets out of autonomous runs by default.
- Fail visibly when permissions are insufficient.
- Log commands, diffs, tests, and final status.
- Keep merge, deploy, and payment authority human.
The list is not fancy. That is why it works.
A headless runner needs boring rules more than clever prompts.
The agent can recover from a test failure. The agent cannot recover from an approval prompt nobody can see.
FAQ
Is Auto-approve the same as giving the agent full access?
No. Auto-approve should mean approved actions inside a defined policy, not unrestricted access to the machine.
The useful version allows routine workspace work while still keeping secrets, protected paths, and high-risk actions outside the run.
Should every dashboard include a manual approval queue?
A manual queue is useful, but it should not be the only answer. Some headless runs need to finish without a human sitting there.
The better design is mode selection first, then manual review only where the task consequence earns it.
Can read-only mode still be useful for coding work?
Yes. Read-only mode is useful for diagnosis, planning, codebase mapping, risk review, and test selection.
A good read-only pass often saves time because the operator can approve a smaller, cleaner edit afterwards.
Does YOLO mode mean the agent is unsafe?
YOLO mode is unsafe when it runs against important systems. YOLO mode can be reasonable inside a disposable sandbox with no secrets and reviewable output.
The danger comes from the environment, not the name of the button.
What is the final decision on Codex approval loops?
The final decision is that approval prompts must be handled as a system design problem, not a terminal UI problem.
If the agent runs headless, the approval policy must be chosen before the run starts.
For Agent OS, the fix was not to hide permissions or pretend every action is safe.
The fix was to make the tradeoff visible: Auto-approve for flow, Ask/read-only for control, and YOLO for isolated speed.
If you are building headless AI coding agents, do not ship a workflow that can wait forever on an invisible prompt.
About Kurt Stockhausen
Kurt Stockhausen runs a business and uses AI agents to build the systems that operate it.
He writes build logs from real workflows: what was wired up, what it cost, and what broke.
Kurt is not a developer by trade. The tools are a means to run the business better.
[[VERIFY: Insert the required Stack Operator AI footer block here if the CMS has a standard footer snippet. No footer block was provided in the brief.]]
