Codex CLI permissions and sandboxing
Understand sandbox modes, approval policies, network access, protected paths, and safer automation defaults.
Codex CLI security uses two controls that solve different problems. The sandbox limits what generated commands can technically access. The approval policy determines when Codex must pause and ask before attempting an action.
Keeping these concepts separate makes permission choices easier to reason about.
Choose the smallest sandbox
The common modes are:
read-only: inspect and plan without modifying the workspace;workspace-write: read broadly and edit inside approved workspace roots;danger-full-access: run without filesystem isolation.
For normal work in a trusted version-controlled repository, workspace write with on-request approvals is a practical default:
codex --sandbox workspace-write --ask-for-approval on-request
Use read-only for investigation or review when edits are not needed. Reserve full access for a separately hardened environment where losing host isolation is an intentional choice.
Understand protected paths
Workspace write does not make every repository path writable. Codex protects
control directories such as .git, .codex, and .agents recursively. This
prevents ordinary agent commands from silently changing repository metadata or
the configuration that governs the agent itself.
Edits outside the workspace require a different writable root or an approved escalation. Grant an additional directory only when the task genuinely owns it.
Treat network access separately
Command network access is off by default in workspace-write mode. Enable it only for workflows that need package registries, APIs, or remote resources. Where possible, restrict destinations rather than allowing arbitrary outbound traffic.
Web search and command networking are separate capabilities. Search results and downloaded content are untrusted input and may contain prompt injection, unsafe commands, or material with unclear licensing.
Avoid turning off every guardrail
--ask-for-approval never disables prompts but does not itself remove the active
sandbox. This can be appropriate for a read-only or tightly scoped automated job.
By contrast, --yolo removes both approval and sandbox protections. Use it only
inside an external isolation boundary such as an ephemeral container with no
valuable credentials or unrelated files.
Set automation explicitly
codex exec starts read-only by default. When an automated task must edit, pass
--sandbox workspace-write explicitly and make the success criteria reproducible.
Keep secrets out of prompts and logs, use the narrowest required network access,
and fail the job when a required tool or MCP server is unavailable.
Permissions are part of the workflow design, not a convenience switch. Start tight, observe the exact blocker, and expand only the capability needed to remove it.