One of the most convenient aspects of AI-assisted development is being able to assign a task and check the result later. I describe a feature, Codex changes the code and runs tests, and Codex Remote lets me continue from my phone without sitting at my PC.
But as I started working on multiple projects, an unexpected inconvenience appeared.
Tasks I had delegated repeatedly stopped while Codex waited for my approval.
Automation stopped at the approval button
At first, I checked each approval request to modify files or run commands. Since an AI coding tool operates on a user's computer, it makes sense to limit its permissions.
The difficulty arose when the same kinds of tasks repeated. During code edits and tests, an approval prompt would appear, and the next step could not run until I responded. This was especially frustrating when I submitted a task remotely, expecting to review the finished work later, only to find it had stopped midway.
Most of the requests so far were tasks I would have approved. That led to a question:
Could I reduce repetitive waits for approval while keeping the safety restrictions?
A sandbox and an approval policy are different things
When I first set up the ONSEMO development environment, I did not want to give an AI tool unrestricted access to all of Windows. I kept the project files in WSL2 Ubuntu and limited the scope in which Codex could work.
Two concepts matter here:
| Concept | What it controls | Example |
|---|---|---|
| Sandbox | Where code may read, write, run processes, and access networks | workspace-write |
| Approval policy | How requests for additional permission are reviewed | on-request, auto_review |
Reducing approval prompts does not necessarily require disabling the sandbox. Conversely, automated review does not grant access to a restricted location.
WSL2 is also not a complete security boundary from Windows. Operating-system access, Codex's sandbox, and approval procedures need to be considered separately.
Trying Auto-review
The typical Codex user configuration file is ~/.codex/config.toml. After checking support in the version I was using, I applied these settings:
approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"Crucially, I did not change the policy to approval_policy = "never". Approval requests could still be raised, but eligible requests would be assessed by an automated reviewer.
This is not blanket approval. Auto-review does not change sandbox boundaries or guarantee that every request can be handled safely. The actual scope of executable actions and the operating rules that require human judgment still matter.
I backed up the existing configuration and did not arbitrarily reset values needed for networking, SSH, or remote access. After applying it, I checked the effective settings again.
What changed in everyday use
After making the change, development tasks stopped less frequently for approvals. It became easier to delegate work remotely and return to review the results.
I did not record a numerical before-and-after count of approval prompts. This is a qualitative observation from actual use, not a measured reduction. And not every task ran automatically.
In particular, Gradle tests and Debug APK builds in my Android project still triggered approval prompts. Would relaxing the Auto-review rules solve that problem?
The answer turned out to be more interesting.
Some work still deserves separate approval
I try not to treat routine file edits and local tests as equivalent to accessing credentials, signing a Release build, or deploying to production.
- Ordinary project checks and tests should run inside the existing sandbox whenever possible.
- Credentials, personal files, writing outside the workspace, and destructive Git actions deserve separate review.
- Production deployment follows a verified Git commit and push through Cloudflare's Git integration, rather than direct local deployment.
Auto-review is not a universal security product that replaces these principles. It helps reduce unnecessary waiting after the intended permission boundaries have been set.
Applying the setting across projects
~/.codex/config.toml is generally shared by Codex CLI processes running under the same user account. This can help apply consistent defaults when working across several repositories in the same WSL2 Ubuntu environment.
The setting will not automatically propagate to a different PC or remote execution environment. Command-line options or per-project configuration may also override shared defaults, so it is worth checking what settings are actually active.
The goal was not to eliminate every approval notification
This first change noticeably reduced repetitive approval interruptions, but some development verification tasks still stopped.
My initial idea was to expand the scope of automatic approval. Looking closer at the cause, however, led somewhere else.
Before granting more permissions, first try to complete the task within the permissions already available.
The next article examines why Android tests requested additional approvals and how I created a reusable verification process without choosing "Always approve."
Related readingAutomating Codex Android Checks Without Always ApproveA real Android Gradle troubleshooting case: move caches inside the workspace, scope tests to Debug, and use a project verification script instead of broad approval rules.
References
Based on actual use and written with AI assistance. Approval policies and supported features can vary by Codex version and execution environment.