Codex Sandbox and Approvals: A Cautious Team Guide

Codex can inspect repositories, edit files, and run commands, but cautious teams should decide its boundaries before assigning work. The useful distinction is simple: the sandbox limits what execution can access, while the approval policy determines when Codex asks permission. Configure both, then verify their behavior in your actual environment.

1. Separate containment from consent

Sandboxing and approvals solve different problems. A sandbox can restrict filesystem writes and network access. An approval prompt provides a human checkpoint when a proposed action requires permission under the active policy. Neither guarantees that a command is sensible, a dependency is trustworthy, or a change is correct.

Start with a disposable checkout containing no production credentials. Record the Codex version and inspect its help output, because supported settings and enforcement vary by release, operating system, and managed environment.

2. Begin with read-only investigation

For an unfamiliar repository, start with codex --sandbox read-only --ask-for-approval on-request. Ask for an architecture summary, a failing-test investigation, or a proposed patch without applying it. Read-only mode is a filesystem boundary, not a promise that Codex will only run commands that appear harmless.

Keep the first task narrow: identify the relevant files, explain the suspected defect, and list validation commands. If a necessary operation is blocked, review the requested permission rather than immediately switching to an unrestricted session. Some environments disable approval-based escalation entirely.

3. Allow workspace writes for implementation

When you are ready for edits, use codex --sandbox workspace-write --ask-for-approval on-request. Workspace-write permits changes within configured writable locations while retaining restrictions elsewhere. Check the effective writable roots instead of assuming that every mounted directory, temporary location, or neighboring checkout has the same protection.

Keep secrets, deployment credentials, and unrelated repositories outside those roots. Use a clean branch or separate worktree, and inspect the diff after each meaningful task. Filesystem containment limits reach; it does not prevent Codex from introducing a bad migration or deleting a tracked file inside the permitted workspace.

4. Choose an approval policy deliberately

• untrusted: Codex can run commands classified as trusted without asking, but requests approval for others. This is a useful starting point when reviewers want frequent checkpoints.
• on-request: Codex decides when to request approval. Pair it with a restrictive sandbox and explicit task boundaries rather than treating it as approval for every consequential action.
• never: Codex does not ask for approval. Blocked operations remain blocked rather than receiving an interactive exception, making this policy useful for constrained unattended jobs.

Approval policies are not complete command-risk classifiers. Before approving a request, inspect the command, working directory, requested access, and expected side effects. Pay particular attention to package installation, lifecycle scripts, shell pipelines, and commands that read environment variables.

5. Treat network access as a separate decision

Do not assume workspace-write automatically permits arbitrary network access. Network behavior depends on the effective configuration and execution environment. Test it explicitly, and preinstall dependencies where practical so routine validation does not require broader access.

Also distinguish sandboxed command traffic from requests sent to the model provider. Restricting a shell command's network access does not stop repository content included in model requests from reaching your configured API service. If your team uses CodeRelay Hub for API routing, review that data path separately from local execution permissions.

6. Prove the boundaries before automating

In a disposable environment, test a workspace edit, an attempted write outside the workspace, an outbound request, and a command that requires approval under your selected policy. Confirm both allowed behavior and expected failures. Retest after configuration or runtime changes.

For CI, prefer workspace-write with never, narrowly scoped credentials, and an explicit writable workspace. Avoid danger-full-access unless a separately enforced isolation boundary justifies it. Keep command output and diffs available for review, without logging secrets. Require human review before merging changes or executing deployment steps.

Open a free CodeRelay Hub workspace.