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.

prompt and AGENTS.md can only affect model intent and cannot replace runtime security controls. When dealing with untrusted repositories, file, network, and approvals should be tightened at the same time.

read-only is suitable for investigation, code explanation and solution review; workspace-write is suitable for implementation in most repositories; danger-full-access allows wider system access and is only suitable for environments that have external isolation provided by containers or virtual machines.

Don't 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.

On-request is usually used for local interactive development, and untrusted can be used to review unfamiliar repositories. never is more suitable for tasks whose boundaries are already fixed by the CI sandbox and cannot wait for human input.

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 shouldn't 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.