Permission Before Action: Approvals, Execpolicy, and Sandboxes

In openai/codex, a command proposed by the model must pass through more than one gate before it can affect the host. This chapter follows that path from parsed command to policy decision, review, permission resolution, and platform or executor sandbox. The practical distinction is simple but essential: an approval answers whether an action may proceed; a sandbox and permission profile determine what the resulting process can reach.

That separation is what keeps bounded autonomy from becoming a disguised privilege switch. The model can request a shell command, a patch, network access, or input to an existing terminal. Codex turns the request into a concrete action, evaluates it under the current environment and policy, and either rejects it, asks for a decision, or launches an attempt with an explicit execution boundary.

sequenceDiagram participant M as Model participant C as Codex core participant P as Command policy participant R as Review path participant S as Sandbox manager participant X as Executor M->>C: Propose command C->>P: Parse and classify argv P-->>C: Allow, prompt, or forbidden alt Forbidden C-->>M: Rejection or model-visible failure else Allowed or reviewable opt Review required C->>R: Hooks, Guardian, or user R-->>C: Approved, denied, or timeout end opt Approved attempt C->>S: Resolve permissions and network S->>X: Launch constrained process X-->>C: Output or sandbox denial C-->>M: Result for next model step end end

The diagram shows the order, not a promise that every action reaches the executor. Policy can forbid a request immediately. A review can deny or time out. A permitted attempt can still fail because the requested permissions cannot be represented by the selected platform or executor. In each case, the result can remain part of the turn's feedback path.

The command is classified before it is launched

The shell path begins by parsing the tool request and resolving the environment and working directory. Codex does not treat a model-generated command string as a complete execution decision. It derives the command form that policy should evaluate, including shell-specific lowering where relevant, and passes it to the execution-policy manager.

The repository's preview execpolicy language is intentionally narrower than a general shell language. Its central rule is a prefix rule: tokens are matched in order, and alternatives can be specified for a token. A rule can classify a matching command as allow, prompt, or forbidden, and can carry a justification. The policy can also describe which absolute executable paths are valid for a basename rule. This matters for commands such as a path-qualified executable: falling back from an absolute path to a basename is not an unconditional identity substitution when host executable metadata constrains the allowed paths.

The evaluator tries explicit matches first. If multiple rules match, the effective decision is the strictest one: forbidden outranks prompt, which outranks allow. When no explicit rule matches, Codex can use command heuristics to classify the request. The result is still represented as an approval requirement rather than being confused with an explicit policy match. That distinction matters later, because an explicit rule and a heuristic judgment do not carry the same evidence for a reusable policy amendment or a sandbox bypass.

The policy stage produces three meaningful outcomes. A forbidden command is blocked without asking for another decision. A promptable command becomes a request that can enter the review path. An allowed command can skip an ordinary approval under the current conditions, but that does not mean every allowed command is launched without isolation. Whether a policy decision also permits bypassing the sandbox is a separate property of the resolved execution requirement.

The source also supports a proposed prefix amendment in some approval flows. If the user chooses to allow a matching class of commands in the future, Codex can append an allow rule under the conditions supported by the current model and policy path. This is a convenience with a real cost: a rule that is too broad can convert one reviewed action into a class of actions that no longer prompts.