Use Codex CLI Full Access Safely by Isolating It Externally¶

For / Key Points

For: SRE and DevOps practitioners considering unattended Codex automation

Key Points: - Keep workspace-write for normal work - Use full access only inside a disposable VM or container - Record Git state and credential boundaries before and after the run

Codex full access removes both confirmation prompts and the operating-system sandbox. The documented flag is --dangerously-bypass-approvals-and-sandbox, not --dangerously-skip-permissions. OpenAI limits its intended use to environments that are already hardened externally.¹

The practical question is: which controls must exist outside Codex before full access becomes an acceptable exception?

Try the safer configuration first¶

Reducing approval prompts does not require removing the sandbox. Start with:

codex \
  --sandbox workspace-write \
  --ask-for-approval on-request

For unattended work, keep approval policy and sandbox mode separate:

codex \
  --sandbox workspace-write \
  --ask-for-approval never

This removes prompts while preserving filesystem boundaries. Network access also remains off by default in workspace-write and can be enabled separately when required.²

Require external isolation before full access¶

The decision is not whether full access is convenient. It is whether an enforceable boundary already exists outside Codex.

Run inside a disposable VM or container
Block routes to production networks
Do not mount a home directory or cloud credentials
Use an account that can write only to the target checkout
Make the entire environment disposable after the run

If any condition is missing, return to workspace-write. Git alone cannot protect untracked files, APIs, credentials, or databases.

Capture a baseline before execution¶

Record the CLI and repository state before starting. Diagnostic reports can contain local paths, so inspect them before sharing.

codex --version
codex doctor --summary
git status --short
git rev-parse HEAD

Also record the branch, allowed operations, credentials in scope, and a concrete stop condition. “Until the task is done” is not an auditable stop condition.

Use full access for one invocation¶

Only after external isolation is in place, pass the documented flag for that invocation:

codex --dangerously-bypass-approvals-and-sandbox

The following explicit combination has the same no-sandbox, no-approval effect.¹

codex \
  --sandbox danger-full-access \
  --ask-for-approval never

Do not persist either setting as a personal default. Managed environments can use requirements.toml to disallow approvalpolicy = "never" or sandboxmode = "danger-full-access".³

Verify the boundary before reviewing the result¶

Do not treat the completion message as proof. Inspect the changed surface first:

git status --short
git diff --stat
git diff --check

Then run tests and obtain human review. If you suspect unexpected writes, outbound transmission, or credential access, destroy the environment and rotate affected credentials before trying again.

Decision table¶

Situation	Recommended configuration	Why
Normal interactive development	`workspace-write` + `on-request`	Boundary crossings remain reviewable
Unattended work with a bounded checkout	`workspace-write` + `never`	Prompts disappear while sandboxing remains
Externally isolated disposable runner	One full-access invocation	The host environment provides the boundary
Developer machine with production credentials	Do not use full access	The blast radius cannot be contained

Summary¶

No Codex option makes full access safe by itself. Safety comes from isolation, least privilege, and disposability outside the agent.