OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml

This is a working reference for the OpenAI Codex commands surface as it stands in 2026, written for the person who has to govern it as well as use it. Each table pairs the command with what a security-minded reader actually wants to know: what it changes, and whether it can quietly widen what the agent is allowed to do.

If you want the reasoning rather than the reference, the companion pieces are Codex's sandbox and approval model, the full-access trust boundary, and what shipped in 2026 and why it matters. The Claude Code equivalent of this page is the Claude Code commands cheat sheet.

The two settings that define the trust boundary

Before the command lists: Codex's entire security posture reduces to a sandbox mode and an approval policy. Learn this table and the rest is lookup.

The row that matters operationally is the third. workspace-write with never is a common CI and automation choice, and it is defensible - but it means the sandbox is the only thing standing between the agent and your host, with no human in the loop. The fourth row is not a configuration; it is a decision to have no controls.

Sandbox modes

The default network block in workspace-write is the most important default Codex ships. Flipping sandbox_workspace_write.network_access = true is what turns a contained agent into something that can reach outbound - which is the difference between a bug and an exfiltration path when a prompt injection lands. If a task genuinely needs network, that is a reason to scope the task, not to set the flag globally.

Approval policies

Primary CLI commands

codex mcp-server deserves a note. It runs Codex itself as an MCP server, which means another agent can drive Codex as a tool. That is a legitimate composition pattern and it is also a trust-boundary question: the calling agent inherits whatever sandbox and approval settings the Codex side is running with.

Global flags

--config is quietly the widest flag here. Because it overrides any configuration value inline, -c sandbox_mode=danger-full-access is equivalent to the bypass flag without looking like it. If you are writing detections, match on the resolved configuration rather than on flag names alone.

Running headless with codex exec

codex exec is where defaults matter most, because there is nobody at the keyboard to catch an escalation. Two shapes worth knowing:

# Read-only review: the safe floor for CI
codex exec --sandbox read-only "Review the diff and summarize risks"

# Workspace-write for a task that must edit files.
# Network stays blocked unless you explicitly enable it.
codex exec --sandbox workspace-write "Fix the failing unit tests"

For a scheduled or CI job, read-only should be the default and anything wider should be a deliberate, reviewed exception. The rollout patterns are in rolling out Codex with fleet governance and the hardening steps in the Codex sandbox and approvals guide.

Slash commands

/permissions is the one to watch: it adjusts approval requirements from inside a running session, which means the posture a session started with is not necessarily the posture it ends with. /feedback sends logs to maintainers, so it is worth knowing what your sessions contain before anyone routinely uses it.

Keyboard shortcuts and composer syntax

config.toml keys

Codex reads user settings from $CODEX_HOME/config.toml, which defaults to ~/.codex/config.toml. A project-local .codex/config.toml in the repo root overrides global settings for that project - which is worth sitting with, because it means a repository can carry configuration that changes the agent's posture on any machine that clones it.

A safe starting baseline, for a machine where you want the agent useful but contained:

# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode   = "workspace-write"

[sandbox_workspace_write]
network_access        = false   # keep this false; scope the task instead
exclude_slash_tmp     = true
exclude_tmpdir_env_var = true

Enterprise controls: requirements.toml

Codex exposes an admin layer separate from user config. Setting top-level allow_managed_hooks_only = true in requirements.toml makes Codex ignore user, project, and session hook configurations while still honoring managed hooks from the requirements and managed config layers.

The important detail is a gotcha: this setting is only supported in requirements.toml. Putting it in config.toml does not enable managed-hooks-only mode, and it fails silently rather than erroring. If you believe you have locked down hooks and you placed the key in the wrong file, you have no control at all - a good example of why deployed policy is worth verifying on the endpoint rather than in the template you shipped.

What to alert on

• --dangerously-bypass-approvals-and-sandbox, which disables both controls in one flag.
• sandbox_mode = "danger-full-access" anywhere, in any config layer, including a repo-local .codex/config.toml.
• sandbox_workspace_write.network_access = true, which converts a contained agent into an outbound path.
• -c / --config overrides that set sandbox or approval keys inline, since they bypass the obvious flag names.
• approval_policy = "never" in codex exec, where no human is present to catch an escalation.
• A project-local .codex/config.toml arriving with a cloned repository, which is untrusted input that configures the agent.
• allow_managed_hooks_only placed in config.toml, where it silently does nothing.

Where Anomity fits

Every value on this page lives in a file on one machine. Anomity's lightweight, unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - so "which sandbox mode, which approval policy, which MCP servers, which network setting" becomes a query rather than a survey (fleet inventory).

Where an agent exposes a hook, Anomity returns allow, deny, or log on each tool call before it runs, turning an in-session approval into enforced org-wide policy (runtime governance). The Sensor sends metadata only over HTTPS, never source or prompts, with secrets redacted on the endpoint. Every decision lands in a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira (audit and outcomes). Anomity is SOC 2 Type II and complements your EDR, XDR, DLP, network, and GRC controls.

You can't govern what you can't see.

Bookmark this page as the command reference; the differences between where Codex runs are in CLI vs cloud vs IDE, and the cross-tool comparison is in Claude Code vs Codex vs Cursor permission models. If you want these settings inventoried across every endpoint instead of checked by hand, book a 30-minute demo.