--- title: "OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml" description: "A complete 2026 OpenAI Codex commands cheat sheet - CLI commands, flags, slash commands, keyboard shortcuts, sandbox modes, approval policies, and config.toml keys - with the security note on each." url: "https://anomity.ai/blog/openai-codex-commands-cheat-sheet/" source: html --- On this page - The two settings that define the trust boundary - Sandbox modes - Approval policies - Primary CLI commands - Global flags - Running headless with codex exec - Slash commands - Keyboard shortcuts and composer syntax - config.toml keys - Enterprise controls: requirements.toml - What to alert on - Where Anomity fits - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml ![Anomity robot illustrating OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml] Guide # OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml Anomity Research Anomity Research · Aug 8, 2026 · 5 min read Share: Copied TL;DR - This OpenAI Codex commands cheat sheet covers the 2026 surface: CLI commands and global flags, slash commands, keyboard shortcuts, and the config.toml keys that decide what Codex may do. - Two settings define the trust boundary: --sandbox ( read-only , workspace-write , danger-full-access ) and --ask-for-approval ( untrusted , on-request , never ). Everything else is detail. - workspace-write blocks network by default. Turning it on means sandbox_workspace_write.network_access = true , which is the single change that converts a contained agent into an exfiltration path. - --dangerously-bypass-approvals-and-sandbox disables both controls at once. It is the flag to alert on, and the Codex analogue of Claude Code's bypass mode. - codex exec runs non-interactively, which is where sandbox and approval defaults matter most - there is no human at the keyboard to catch an escalation. - Admins get a real control point: requirements.toml supports allow_managed_hooks_only = true , which ignores user, project, and session hook configs while keeping managed hooks. 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](https://anomity.ai/blog/openai-codex-sandbox-and-approval-model/), [the full-access trust boundary](https://anomity.ai/blog/openai-codex-full-access-trust-boundary/), and [what shipped in 2026 and why it matters](https://anomity.ai/blog/new-openai-codex-features-2026-security/). The Claude Code equivalent of this page is [the Claude Code commands cheat sheet](https://anomity.ai/blog/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. Combination What Codex can do without asking Where it stops `read-only` + `on-request` Read files, answer questions Any edit or command prompts for approval `workspace-write` + `on-request` Read, edit in workspace, run local commands Edits outside the workspace and network prompt `workspace-write` + `never` Everything inside the sandbox, silently Hard sandbox boundary only; no prompt `danger-full-access` + `never` Anything, including network and host writes Nothing is enforced 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 Mode Filesystem Network Use when `read-only` No writes Blocked Review, understanding code, audits `workspace-write` Writes inside the workspace and `writable_roots` **Blocked by default** Attended refactors, builds, tests `danger-full-access` Unrestricted host writes Unrestricted Effectively never on a managed endpoint 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 Policy Behavior `untrusted` Prompt for anything not on the trusted list `on-request` Codex asks when it needs to escalate past the sandbox `never` No prompts; the sandbox boundary is the only control `{ granular = {...} }` Per-category approval rules ## Primary CLI commands Command Maturity What it does `codex` Stable Launch the interactive terminal UI `codex exec` / `codex e` Stable Run non-interactively (headless) `codex resume` Stable Continue a previous session `codex fork` Stable Fork a previous session into a new chat `codex apply` / `codex a` Stable Apply cloud chat diffs locally `codex review` Stable Run code review non-interactively `codex sandbox` Stable Run commands in a sandboxed environment `codex cloud` Experimental Manage Codex cloud chats from the terminal `codex app` Stable Open the ChatGPT desktop app `codex app-server` Experimental Run Codex as a local app server `codex mcp` Stable Manage MCP servers `codex mcp-server` Stable Run Codex itself as an MCP server `codex plugin` Stable Install and manage plugins `codex login` / `codex logout` Stable Authenticate with ChatGPT or an API key `codex archive` / `codex unarchive` Stable Archive or restore a saved session `codex delete` Stable Permanently delete a session `codex doctor` Stable Generate a diagnostic report `codex completion` Stable Generate shell completions `codex update` Stable Check for and apply CLI updates `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 Flag Values What it does `--sandbox`, `-s` `read-only` \| `workspace-write` \| `danger-full-access` Sandbox policy `--ask-for-approval`, `-a` `untrusted` \| `on-request` \| `never` Approval timing `--dangerously-bypass-approvals-and-sandbox` boolean Disables both controls at once `--add-dir` path Grant write access to additional directories `--cd`, `-C` path Set the working directory `--config`, `-c` key=value Override any configuration value inline `--profile`, `-p` string Layer a named profile over the base config `--model`, `-m` string Override the configured model `--search` boolean Enable live web search `--image`, `-i` path[,path...] Attach image files `--oss` boolean Use a local open-source provider `--remote` `ws://` \| `wss://` \| `unix://` Connect to a remote app-server `--enable` / `--disable` feature Force a feature flag on or off `--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](https://anomity.ai/blog/rolling-out-openai-codex-fleet-governance-guide/) and the hardening steps in [the Codex sandbox and approvals guide](https://anomity.ai/blog/securing-openai-codex-sandbox-and-approvals-guide/). ## Slash commands Command What it does `/permissions` Adjust approval requirements `/sandbox-add-read-dir` Grant read access to a directory (Windows) `/model` Change the model mid-session `/fast` Toggle fast mode `/agent` Switch agent threads `/plugins` Browse installed plugins `/diff` Review git changes `/copy` Copy the latest response (or Ctrl+O) `/init` Generate an `AGENTS.md` scaffold `/clear` Start a fresh chat `/rename` Rename the current session `/archive` Archive the session and exit `/delete` Permanently remove the session `/feedback` Send logs to maintainers `/logout` Sign out `/exit` Close the session `/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 Key What it does `@` Search and insert file paths `!` prefix Run a local shell command `Ctrl+R` Search prompt history `Ctrl+O` Copy the latest output `Up` / `Down` Restore draft history `Tab` while working Queue a follow-up `Enter` while working Inject instructions into the running turn `Esc` twice Edit a previous message and fork `Ctrl+C` Close the session ## 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. Key Values Notes `model` string Model identifier, e.g. `gpt-5.5` `model_reasoning_effort` `minimal` \| `low` \| `medium` \| `high` \| `xhigh` Higher effort means more autonomous work per turn `approval_policy` `untrusted` \| `on-request` \| `never` \| `{ granular = {...} }` When Codex pauses for approval `sandbox_mode` `read-only` \| `workspace-write` \| `danger-full-access` Filesystem and network policy `sandbox_workspace_write.network_access` boolean **The setting to audit.** Off by default `sandbox_workspace_write.writable_roots` array Additional writable directories `sandbox_workspace_write.exclude_slash_tmp` boolean Exclude `/tmp` from writable roots `sandbox_workspace_write.exclude_tmpdir_env_var` boolean Exclude `$TMPDIR` from writable roots `profiles` table Profiles live beside config as `$CODEX_HOME/ .config.toml` `mcp_servers. ` table `command`, `args`, `env`, `enabled`, `enabled_tools`, `disabled_tools`, `startup_timeout_sec`, `tool_timeout_sec`, per-tool `approval_mode` 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](https://anomity.ai/#features)). 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](https://anomity.ai/#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](https://anomity.ai/#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](https://anomity.ai/blog/openai-codex-cli-cloud-ide-security-differences/), and the cross-tool comparison is in [Claude Code vs Codex vs Cursor permission models](https://anomity.ai/blog/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](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What are the OpenAI Codex sandbox modes? Three: read-only, workspace-write, and danger-full-access. read-only permits no writes and blocks network, which suits review and audit work. workspace-write allows writes inside the workspace and any configured writable_roots, and blocks network by default. danger-full-access removes all restrictions on host writes and network. The mode is set with --sandbox or -s on the command line, or with sandbox_mode in config.toml. Does Codex have network access in workspace-write mode? No, not by default. workspace-write blocks outbound network, and enabling it requires setting sandbox_workspace_write.network_access = true in config.toml. This is the most security-relevant default Codex ships: with network blocked, a prompt injection that reaches the agent has no straightforward exfiltration path. If a specific task genuinely needs network, the safer pattern is to scope that task rather than enable the setting globally. What is the difference between approval policies untrusted, on-request, and never? untrusted prompts for anything not on the trusted list. on-request means Codex asks when it needs to escalate past the sandbox boundary, which keeps a human in the loop for edits outside the workspace or network access. never means no prompts at all, leaving the sandbox as the only control. A granular option also exists for per-category rules. The combination of approval policy and sandbox mode, not either alone, is what defines what Codex can do without asking. How do I run Codex non-interactively? Use codex exec (aliased as codex e). For example, codex exec --sandbox read-only "Review the diff and summarize risks" for a safe CI review, or codex exec --sandbox workspace-write "Fix the failing unit tests" when the job must edit files. Headless mode is where sandbox and approval defaults matter most, because there is no human at the keyboard to catch an escalation, so read-only should be the default and anything wider should be a reviewed exception. Where is the Codex config.toml file? Codex reads user settings from $CODEX_HOME/config.toml, which defaults to ~/.codex/config.toml. A project-local .codex/config.toml in the repository root overrides global settings for that project. That project-local override is worth treating as untrusted input: a cloned repository can carry configuration that changes the agent's posture on whatever machine clones it, which is a good reason to inventory the resolved configuration per endpoint rather than trusting a template. Which Codex flags should security teams alert on? --dangerously-bypass-approvals-and-sandbox disables both controls in one flag. Any setting of sandbox_mode to danger-full-access, in any config layer. sandbox_workspace_write.network_access = true, which converts a contained agent into an outbound path. And crucially, -c or --config overrides, because --config can set any configuration value inline, so -c sandbox_mode=danger-full-access is equivalent to the bypass flag without looking like it. Detections should match on resolved configuration, not flag names alone. How do admins lock down Codex hooks? Set top-level allow_managed_hooks_only = true in requirements.toml. Codex then ignores user, project, and session hook configurations while still honoring managed hooks from the requirements and managed config layers. The gotcha is that this setting is only supported in requirements.toml: placing it in config.toml does not enable managed-hooks-only mode and fails silently rather than erroring, so an admin who put the key in the wrong file has no control at all while believing hooks are locked down. ## Related [Guide ### Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026) Anthropic's AI security review action is useful and, in its own words, not hardened against prompt injection. How to deploy it without adding a hole. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/claude-code-security-review-github-action-guide/) [Guide ### NVIDIA OpenShell: A Security Team's Guide to the Agent Sandbox and Its Defaults (2026) How NVIDIA OpenShell sandboxes AI agents, what its policy engine enforces, and the defaults to change before you rely on it: audit mode, Landlock, logs. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-openshell-agent-sandbox-security-guide/) [Guide ### Enterprise-Managed MCP Connectors: What IdP-Governed Authorization Covers, and What It Does Not (2026) Enterprise-managed MCP connectors went GA on 24 August 2026 across ten connectors. What IdP-governed authorization covers, and what it cannot see. Anomity Research · Aug 27, 2026 · 9 min](https://anomity.ai/blog/anthropic-enterprise-managed-mcp-connectors-idp-governance/) ## Structured data ```json { "@context": "https://schema.org", "@type": "Article", "headline": "OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml", "description": "A complete 2026 OpenAI Codex commands cheat sheet - CLI commands, flags, slash commands, keyboard shortcuts, sandbox modes, approval policies, and config.toml keys - with the security note on each.", "datePublished": "2026-08-08", "dateModified": "2026-08-08", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/openai-codex-commands-cheat-sheet/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/posts/openai-codex-commands-cheat-sheet.jpg", "width": 1200, "height": 630 }, "articleSection": "Guide", "url": "https://anomity.ai/blog/openai-codex-commands-cheat-sheet/", "keywords": "OpenAI Codex commands cheat sheet, OpenAI Codex, CLI reference, slash commands, sandbox, approval policy, config.toml" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What are the OpenAI Codex sandbox modes?", "acceptedAnswer": { "@type": "Answer", "text": "Three: read-only, workspace-write, and danger-full-access. read-only permits no writes and blocks network, which suits review and audit work. workspace-write allows writes inside the workspace and any configured writable_roots, and blocks network by default. danger-full-access removes all restrictions on host writes and network. The mode is set with --sandbox or -s on the command line, or with sandbox_mode in config.toml." } }, { "@type": "Question", "name": "Does Codex have network access in workspace-write mode?", "acceptedAnswer": { "@type": "Answer", "text": "No, not by default. workspace-write blocks outbound network, and enabling it requires setting sandbox_workspace_write.network_access = true in config.toml. This is the most security-relevant default Codex ships: with network blocked, a prompt injection that reaches the agent has no straightforward exfiltration path. If a specific task genuinely needs network, the safer pattern is to scope that task rather than enable the setting globally." } }, { "@type": "Question", "name": "What is the difference between approval policies untrusted, on-request, and never?", "acceptedAnswer": { "@type": "Answer", "text": "untrusted prompts for anything not on the trusted list. on-request means Codex asks when it needs to escalate past the sandbox boundary, which keeps a human in the loop for edits outside the workspace or network access. never means no prompts at all, leaving the sandbox as the only control. A granular option also exists for per-category rules. The combination of approval policy and sandbox mode, not either alone, is what defines what Codex can do without asking." } }, { "@type": "Question", "name": "How do I run Codex non-interactively?", "acceptedAnswer": { "@type": "Answer", "text": "Use codex exec (aliased as codex e). For example, codex exec --sandbox read-only \"Review the diff and summarize risks\" for a safe CI review, or codex exec --sandbox workspace-write \"Fix the failing unit tests\" when the job must edit files. Headless mode is where sandbox and approval defaults matter most, because there is no human at the keyboard to catch an escalation, so read-only should be the default and anything wider should be a reviewed exception." } }, { "@type": "Question", "name": "Where is the Codex config.toml file?", "acceptedAnswer": { "@type": "Answer", "text": "Codex reads user settings from $CODEX_HOME/config.toml, which defaults to ~/.codex/config.toml. A project-local .codex/config.toml in the repository root overrides global settings for that project. That project-local override is worth treating as untrusted input: a cloned repository can carry configuration that changes the agent's posture on whatever machine clones it, which is a good reason to inventory the resolved configuration per endpoint rather than trusting a template." } }, { "@type": "Question", "name": "Which Codex flags should security teams alert on?", "acceptedAnswer": { "@type": "Answer", "text": "--dangerously-bypass-approvals-and-sandbox disables both controls in one flag. Any setting of sandbox_mode to danger-full-access, in any config layer. sandbox_workspace_write.network_access = true, which converts a contained agent into an outbound path. And crucially, -c or --config overrides, because --config can set any configuration value inline, so -c sandbox_mode=danger-full-access is equivalent to the bypass flag without looking like it. Detections should match on resolved configuration, not flag names alone." } }, { "@type": "Question", "name": "How do admins lock down Codex hooks?", "acceptedAnswer": { "@type": "Answer", "text": "Set top-level allow_managed_hooks_only = true in requirements.toml. Codex then ignores user, project, and session hook configurations while still honoring managed hooks from the requirements and managed config layers. The gotcha is that this setting is only supported in requirements.toml: placing it in config.toml does not enable managed-hooks-only mode and fails silently rather than erroring, so an admin who put the key in the wrong file has no control at all while believing hooks are locked down." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "OpenAI Codex Commands Cheat Sheet (2026): CLI, Slash Commands, Sandbox, and config.toml", "item": "https://anomity.ai/blog/openai-codex-commands-cheat-sheet/" } ] } ```