Let Codex run your tests without asking, safely

Codex asking before every npm test gets old fast, and the tempting fix is the flag with "dangerously" in its name. You don't need it. Codex CLI runs commands inside a sandbox, and once you know what each sandbox mode allows, you can let it work without prompts while it still can't touch anything outside your project or reach the internet.

We tested each mode on Codex CLI 0.164 in a small git repo with one Node test. Here's what happened, and the settings we'd use.

The two settings that matter#

Codex has two separate dials:

• Sandbox (-s or sandbox_mode): what a command can do once it runs. read-only, workspace-write or danger-full-access.
• Approvals (-a or approval_policy): when Codex stops to ask you. on-request lets the model decide when it needs your yes; never never asks, and a failed command goes straight back to the model.

Most prompts come from a command that needs more than the sandbox allows. Pick the right sandbox, and the questions mostly stop on their own.

What workspace-write allows#

We asked Codex in workspace-write mode to run four commands and report each result:

So workspace-write is the mode for normal work: it can read anything, write inside the project, run your tests and build, and it has no network. One surprise: it can also write to /tmp. Our first test folder was under /tmp, so writing "outside the project" worked there; from a folder in the home directory it was refused. Keep that in mind if you test this yourself.

read-only is stricter: touch ro.txt failed with Operation not permitted, so Codex can read and explain, but not change anything.

Turning the network on#

Installing packages or calling an API needs the network, which workspace-write blocks. Turn it on for one run:

codex -s workspace-write -c sandbox_workspace_write.network_access=true

With that, the same curl returned 200, and writes outside the project were still blocked. That's a far smaller step than danger-full-access, which lifts every limit.

Put it in config, not in your fingers#

Typing flags every time is how people end up reaching for the dangerous one. Codex reads settings from ~/.codex/config.toml, and from .codex/config.toml inside the project. In our test the project file won: our user config said danger-full-access, the project file said read-only, and Codex ran read-only.

A project file for a typical repo:

# .codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Commit it, and everyone's Codex works the same way in that repo. Set network_access = true if your tests or installs need it.

Profiles for the odd job#

Sometimes you want a stricter or looser setup for one session, such as read-only for a code review. In Codex 0.164, -p <name> layers a file named <name>.config.toml from your Codex folder on top of your normal config:

# ~/.codex/review.config.toml
sandbox_mode = "read-only"

codex -p review

We checked it: with that profile, touch prof.txt failed with Operation not permitted. Older posts show [profiles.review] tables inside config.toml; in 0.164 the help text describes the separate-file form, so use that.

Where did --full-auto go?#

Many guides tell you to run codex --full-auto. In Codex CLI 0.164 that fails with error: unexpected argument '--full-auto' found. Ask for the closest setup directly:

codex -s workspace-write -a on-request

or put those two lines in config.toml as above. There's also --approve-for-me in 0.164, which sends approval requests to an automatic review inside the workspace-write sandbox instead of to you.

When the dangerous flag is fine#

--dangerously-bypass-approvals-and-sandbox runs every command with no sandbox and no questions. Codex's own help says it is for environments that are already sandboxed: a container, a throwaway VM, a CI runner. On your own computer, with your SSH keys and browser profile one folder away, workspace-write with the network turned on does everything a coding job needs.

A setup we'd use#

• .codex/config.toml in the repo with workspace-write and on-request, committed.
• network_access = true only if tests or installs need it.
• A review profile with read-only for "look but don't touch" sessions.
• No danger-full-access outside a container.
• Ask Codex to run touch ../x once in a new repo to check the sandbox is what you think it is.

Where Joxo fits#

When Codex does need you, Joxo sends the question to your phone and desktop, so a prompt doesn't sit for an hour while you're away. You can also run Codex next to a teammate's Claude Code on the same project and see both. Setup is one line pasted into your agent. To make Codex check its own work before it stops, see make Codex run your tests before it says done.

Frequently asked questions#

How do I stop Codex asking for permission every time?#

Use the workspace-write sandbox with on-request approvals, in .codex/config.toml or with -s workspace-write -a on-request. Codex can then run tests and edit files in the project without asking, and asks only when a command needs more.

Can Codex access the internet in workspace-write mode?#

Not by default: in our test curl couldn't resolve a host. Set sandbox_workspace_write.network_access = true in config, or pass it with -c for one run.

Why does codex --full-auto not work?#

Codex CLI 0.164 no longer has the flag and stops with "unexpected argument". Use -s workspace-write -a on-request, the closest match to what it did.