Codex CLI Sandbox, Approvals and Permission Security

The sandbox defines where commands can read, write and use the network; the approval policy determines whether actions require human confirmation. Setting approval to never does not expand the sandbox, and danger-full-access does not mean every action receives review.

Prompts and AGENTS.md influence model behavior but do not enforce runtime security. For untrusted repositories, restrict file access, network access, and approvals at the runtime layer.

Use read-only for investigation, code explanation, and plan review. Use workspace-write for implementation inside the repository. Use danger-full-access only inside an externally isolated environment such as a disposable container or virtual machine.

Do not just open up the entire system just because a cache directory is needed for one build. Prioritize adding the minimum necessary directory through --add-dir, or adjusting the build cache location.

untrusted runs only trusted read-only commands directly and requests confirmation for others. on-request lets the model request elevated access when necessary. never initiates no approval flow and returns a restricted-action failure directly to the model.

Use on-request for local interactive work and untrusted when reviewing an unfamiliar repository. Use never only when the CI sandbox already fixes the task boundaries and no human response is available.

When tasks need to access adjacent workspaces, use --add-dir to explicitly add them instead of setting the working root directory to a common parent directory. Networking needs should also differentiate between dependent downloads, API calls, and web searches.

Turning on --search provides native web search tools to the model; it is not a universal switch for all network requests. When working with private code, you still need to follow your organization's data egress policy.

Options that bypass approvals and sandboxing allow model-generated commands to run directly on the host. Use them only in automation where containers, virtual machines or disposable runners already provide reliable isolation.

Do not use on personal workstations, production servers, hosts containing cloud credentials, or untrusted repositories. Tutorials should not package it as a "confirmation-free trick" either.

Team baselines should be defined by work scenarios rather than personal preferences. Interactive development, read-only review, CI fixes, and production diagnostics require different combinations and are constrained by project configuration and runtime environment.

Regularly review approved commands, additional directories and network scopes. Broad access granted for temporary troubleshooting should not remain in shared configuration.