codex sandbox: start with the exact job

Codex CLI sandbox and approval modes define different parts of the control surface. The sandbox constrains what the process can access; approval policy governs when an attempted action can escalate. Neither proves that an approved command is correct or that repository output meets the task.

This page owns the intent “choose sandbox and approval settings for a repository.” It does not replace the broader Codex CLI topic or adjacent implementation decisions. Keeping that boundary visible prevents two pages from answering the same search job with slightly different wording.

How the codex sandbox control surface works

A request can be safe inside the workspace yet dangerous when it reaches the network, credentials, parent directories, or external services. Conversely, overly restrictive settings can prevent legitimate checks. The configuration should follow the task's impact, the repository's trust level, and the host environment.

For codex sandbox, the closest architectural context is Install Codex CLI and Run a First Task. Read that dependency when the current decision needs a parent workflow or prerequisite. This anchor follows the reader's next question instead of repeating the page keyword mechanically.

FIG. 01 / Conceptual model

codex sandbox: mechanism and verification path

Process model for codex sandbox: Agent request, Sandbox boundary, Approval gate, Action, Audit trace
Conceptual model: Agent request → Sandbox boundary → Approval gate → Action → Audit trace. Equal stages show sequence, not measured time or effort.

Reproducible lab note: a reproducible working sequence

Use this codex sandbox sequence as a reviewable method, not as a claim that one prompt guarantees choose sandbox and approval settings for a repository. Pin the relevant official documentation, keep sensitive values out of the record, and connect every permission expansion to a named requirement in this workflow.

  1. Inventory the files, commands, network destinations, and credentials the task genuinely needs.
  2. Select sandbox settings that exclude unrelated host and external resources.
  3. Define which escalation requests a human may approve and on what evidence.
  4. Exercise denied paths and inspect the audit trail before using the configuration routinely.

After the codex sandbox sequence, the next implementation detail is Codex App vs CLI. That destination owns its narrower search job, while this article stays responsible for choose sandbox and approval settings for a repository.

For codex sandbox, write the expected signal before each action. A successful command can still produce the wrong artifact, and a fluent agent summary can omit scope drift. The check must observe what this search job actually changes: a diff, test, typed contract, rendered interface, structured trace, or explicit denied path.

Keep evidence beside the codex sandbox result

Create a permission matrix for read paths, write paths, commands, network, environment variables, external side effects, and approval owner. Pair it with allowed and denied test cases using a disposable repository and non-sensitive credentials.

Minimum evidence ledger for codex sandbox
QuestionRecord
What was attempted?Bounded task and starting state
What could act?Tools, permissions, sandbox, and credentials by name only
What changed?Artifacts, paths, or external side effects
What proves the result?Independent check, reviewer decision, and remaining uncertainty

The codex sandbox ledger needs a version and date because the documented contract can evolve. Its attached search metric describes demand for this intent, not product quality. This article makes no benchmark, success-rate, or cost claim; any later test must publish a protocol and the evidence required to inspect it.

FIG. 02 / Decision aid

codex sandbox: evidence and control decision

Decision aid for codex sandbox using Read scope, Write scope, Network, External consequence
Decision aid: compare Read scope, Write scope, Network, External consequence. Qualitative placement is illustrative and contains no measured performance data.

Test the failure paths before expanding access

For codex sandbox, the architecture flags these recurring risks: CLI, app, and cloud behavior are conflated; Sandbox and approval settings are omitted; Model or feature churn makes the steps stale. Convert each one into a denied or recovery case tied to choose sandbox and approval settings for a repository. The resulting trace should identify the attempted action, the layer that stopped it, the evidence retained, and the safe next step.

  • Use a disposable fixture for commands that may mutate files or external state.
  • Remove secrets and confidential source from logs before sharing evidence.
  • Confirm that malformed input and missing dependencies fail visibly.
  • Stop when the next action needs new authority or an unverified assumption.

When the codex sandbox reader reaches the related boundary, continue with Codex CLI. That destination owns its decision while this page remains canonical for choose sandbox and approval settings for a repository.

A decision rule for codex sandbox

Start with the narrowest mode that supports the task and expand only for a named action. Require explicit review for external mutation, secret access, or changes outside the repository, and keep verification separate from permission decisions.

Before adopting this codex sandbox workflow, name its owner, the evidence that justifies its permissions, the review that confirms choose sandbox and approval settings for a repository, and the event that triggers revalidation. Those four answers turn this specific capability into an operating choice a team can maintain.