Codex CLI commands, slash commands and shortcuts

The Codex CLI is more than codex "prompt": it saves every session so codex resume and codex fork continue or branch one, it has dozens of slash commands in the terminal UI (TUI), and it runs codex review and codex exec from scripts. Every command and flag below was checked against Codex CLI 0.157.1 as of this page’s 2026-10-03 revision; the slash-command table was re-read against 0.162.1 on 2026-10-12.

This page is for developers who already run Codex in a terminal and keep paying the same tax: re-explaining context in a fresh session, losing a good thread when an experiment goes wrong, and reading the whole diff because nothing else tells them whether the change is right. Most of that tax disappears once you use the session commands, a handful of slash commands and a review gate. If you have not installed Codex yet, start with your first Codex task.

What you’ll walk away with from the Codex CLI

• A session routine: named sessions you resume by name, forks for experiments, and a queue for follow-ups.
• The slash commands that matter day to day, and when each one pays off.
• The TUI keys for steering a running turn, queuing the next one and writing long prompts in your editor.
• Four copy-paste prompts, and a review-and-test gate that checks the result so you do not read every line.
• The traps in 0.157.1 that silently change behaviour, with the fix for each.

How do you continue a Codex session instead of re-explaining it?

Codex writes every interactive session to disk. codex resume reopens one with its whole transcript, so the agent keeps the decisions, constraints and files from last time.

# Terminal: open the picker (sessions started in this directory)
codex resume

# Continue the most recent session
codex resume --last

# Search sessions from every directory, not only this one
codex resume --all

# Continue and send the next instruction in one step
codex resume --last "The plan is approved. Implement step 1 and run the tests."

The picker filters by working directory by default. When a session you know exists is missing, you started it somewhere else: add --all. Sessions started with codex exec are also hidden from the picker and from --last unless you pass --include-non-interactive.

Name sessions so you can find them next week

A UUID is useless a week later. Inside the TUI, run /rename and give the thread a name such as payments-retry. From then on, codex resume, codex exec resume, codex exec fork, codex archive and codex queue accept the name wherever they accept a session ID (codex fork takes the UUID or --last):

codex resume payments-retry "CI is green again. Continue with the refund path."

Two more commands keep the list short: codex archive <name> hides a finished session and codex unarchive <name> brings it back, while codex delete <name> removes it for good. Inside the TUI, /archive and /delete do the same for the current session.

Queue a follow-up for an existing session

codex queue adds a message to an existing session’s queue without opening that session in your terminal. --thread takes the session UUID or its exact name:

codex queue --thread payments-retry --message "When the tests pass, update CHANGELOG.md."

How do you try an alternative without losing the original thread?

codex fork copies a session’s transcript into a new thread and leaves the original untouched. In 0.157.1 it accepts a prompt, so you can branch and instruct in one command. Inside the TUI, /fork forks the current chat.

Copy-paste prompt: fork and compare two designs

First, in the terminal, ask for options and stop before any code:

Propose two ways to add response caching to the GET /products endpoint: (1) Redis with a 5-minute TTL and explicit invalidation on product writes, (2) an in-process LRU cache per worker. For each, list the files you would change, the invalidation rule, and the test that would prove stale data is never served. Do not edit any files yet.

Then branch the thread once per option. Each fork starts from the same analysis:

codex fork --last --worktree "Implement option 1 (Redis). Add the stale-data test first, make it fail, then make it pass. Stop and report the test output."
codex fork --last --worktree "Implement option 2 (LRU). Add the stale-data test first, make it fail, then make it pass. Stop and report the test output."

--worktree starts each fork in a new managed Git worktree; without it, both forks edit the same files. The worktree workflow is covered in Codex worktrees. Compare the forks on their test output and /diff, not on how confident the final message sounds.

Which Codex slash commands are worth learning?

Type / in the composer to see the full list for your version; there is no /help (checked in 0.157.1 and 0.162.1, slash_command.rs). These are the ones that change how a session goes. Descriptions are paraphrased from slash_command.rs at 0.157.1, and every row below was re-read against the 0.162.1 source on 2026-10-12.

Command	What it does	When to reach for it
/review	Reviews your current changes and reports issues	Before every commit; accepts custom instructions inline
/diff	Shows the Git diff, including untracked files	Before you accept a turn’s work
/status	Shows the session configuration and token usage	When the agent behaves as if it had a different model or permission
/model	Chooses the model and reasoning effort	A hard bug needs more effort; a rename needs less
/permissions	Chooses what Codex is allowed to do	You started read-only and now want it to edit files
/compact	Summarises the conversation to stay under the context limit	Long sessions, before the agent starts forgetting constraints
/new	Starts a new chat in the same TUI	The topic changed; old context would only mislead
/fork, /resume, /rename	Branch, reopen or name threads	See the sections above
/worktree	Starts or continues a conversation in a new managed worktree	You want isolation without leaving the session; see Codex worktrees
/plan	Switches to Plan mode	Agree the approach before any file changes
/goal	Sets or views the goal for a long-running task	Multi-hour tasks that must not drift
/init	Creates an AGENTS.md file	First session in a repository
/side, /btw	Opens a side conversation in an ephemeral fork	A quick question that should not pollute the main thread
/mcp, /skills, /plugins	Lists MCP tools, skills and plugins; /mcp login <name> signs in to an OAuth server (0.161.0)	Checking that an integration actually loaded
/approve	Approves one retry of a recent auto-review denial	Auto-review blocked a command you have checked
/copy, /export	Copies the last response or part of it; exports the conversation as Markdown	Pasting a plan into a ticket or PR

Most commands, including /compact, /new, /init, /review and /plan, are unavailable while a turn is running. Press Esc to interrupt the turn first. /model, /permissions, /diff and /status work mid-turn, and so do /copy and /mcp; /worktree waits for the turn to end (checked in 0.157.1 and 0.162.1, slash_command.rs).

The 0.162.1 list also contains /daybreak (“turn Daybreak on or off”), which is hidden by default. Since 0.161.0 (2026-10-07) it needs --enable cli_daybreak or features.cli_daybreak = true, and daybreak = true alone is not enough; cli_daybreak is under development and off in 0.162.1 (checked 2026-10-12). For the security context, see Codex Security and the agents command center.

Review your own changes before you commit

/review opens a menu of review targets. The same targets exist as flags on codex review, which runs the review without the TUI:

Target	In the TUI	From the shell
Work against a base branch	/review → base branch	codex review --base main
Staged, unstaged and untracked changes	/review → uncommitted changes	codex review --uncommitted
One commit	/review → a commit	codex review --commit <SHA>
Your own instructions	/review Focus on…	codex review "Focus on…"

In 0.157.1 the last row cannot be combined with the others from the shell: codex review rejects a custom prompt together with --uncommitted, --base or --commit (“the argument ‘—uncommitted’ cannot be used with ‘[PROMPT]’”). Pass either a target flag or your own instructions, not both.

To use a different model for reviews than for coding, set review_model in ~/.codex/config.toml:

~/.codex/config.toml

review_model = "gpt-6-sol"

Which model fits which job, with prices, is kept on the model hub.

Copy-paste prompt: a review that looks for real defects

Paste after /review in the TUI, or pass it alone as the argument to codex review (use - to read it from stdin). Do not add --uncommitted: in 0.157.1 a custom prompt and a target flag are mutually exclusive.

Review my uncommitted changes (staged, unstaged and untracked) only for defects that would reach production: wrong behaviour, missing error handling on I/O, race conditions, SQL or shell injection, secrets in code, and tests that assert nothing. Ignore style and naming. For every finding give the file and line, a one-sentence failure scenario, and a severity P0 to P3. If you find nothing at P0 or P1, say so explicitly.

Which TUI keys save time on every turn?

Press ? in an empty composer to show the shortcuts for your build. These are the defaults in 0.157.1; you can remap them with /keymap.

Key	What it does
@	Opens fuzzy file search; the chosen path goes into your message
! at the start of a line	Runs a local shell command; its output lands in the conversation
Enter while the agent works	Sends your message into the running turn to steer it
Tab while the agent works	Queues your message for after the current turn
Esc while the agent works	Interrupts the turn
Esc twice when idle	Edits your previous message
Ctrl+G	Opens $VISUAL or $EDITOR to write a long prompt
Ctrl+R	Searches your prompt history
Ctrl+T	Opens the full transcript
Alt+, / Alt+.	Lowers or raises reasoning effort

Enter versus Tab is the one to internalise. Enter corrects the agent now (“stop, that table is generated; edit the migration instead”). Tab lines up the next job without disturbing the current one (“then add the changelog entry”).

The ! prefix is the fastest way to give the agent evidence instead of your summary of it:

!npm test -- payments 2>&1 | tail -40

Copy-paste prompt: fix from real test output

Run the failing test with ! first, then send:

The test output above is the only source of truth. Find the root cause of the first failure, not the symptom. Change the smallest amount of code that fixes it, rerun the same test command, and show me its output. If the fix touches more than two files, stop and explain why before editing.

How do you give Codex a screenshot from the terminal?

Attach images to the first prompt with -i or --image. Put the prompt before the flag, or use the = form: in 0.157.1 -i keeps taking arguments until the next flag, so a prompt written after it is read as another image path.

codex "The checkout button overlaps the total on a 375px viewport. Fix the CSS and tell me which rule caused it." -i broken-layout.png
codex --image=expected.png,actual.png "The first image is the design, the second is production. List every visual difference, then fix them."

In the TUI you can also paste an image from the clipboard into the composer. codex exec and codex resume accept the same multi-file -i; codex exec resume takes a single -i <FILE> (checked in 0.157.1).

How do you script Codex from the shell?

codex exec runs one task without the TUI and exits, which makes it usable in scripts and Git hooks. The full treatment, including the JSONL event stream and CI, is on Run Codex non-interactively with codex exec. The three invocations you need most:

# Edit files inside the workspace sandbox
codex exec --sandbox workspace-write "Fix the lint errors reported by npm run lint, then rerun it"

# Pipe context in; stdin is appended to the prompt as a <stdin> block
git diff main...HEAD | codex exec "Write a PR description for this diff: summary, risks, test plan"

# Write only the final message to a file
codex exec -o release-notes.md "Draft release notes for the commits since the last tag"

When a script consumes the output, make Codex return JSON that matches a schema instead of prose:

Copy-paste prompt: endpoint inventory as JSON

codex exec --output-schema endpoints.schema.json -o endpoints.json \
  "List every HTTP endpoint mounted in the Express app under src/routes: method, path, and a one-line description. Include only routes that are actually registered with the app, not dead files."

endpoints.schema.json defines the shape the final message must take:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["endpoints"],
  "properties": {
    "endpoints": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["method", "path", "description"],
        "properties": {
          "method": { "type": "string", "enum": ["GET", "POST", "PUT", "PATCH", "DELETE"] },
          "path": { "type": "string" },
          "description": { "type": "string" }
        }
      }
    }
  }
}

How do you know the result is right without reading every line?

The CLI gives you the parts of a gate; you still decide what “done” means. A routine that works for day-to-day changes:

1. State the check in the prompt. Every prompt on this page ends with a command the agent must run and report, such as the test command or npm run lint. A claim of success without that output is not success.

2. Rerun the check yourself. Run the same test and type-check commands in your terminal, or with ! in the TUI. The agent’s transcript is a report, not evidence.

3. Read the shape of the diff, not every line. /diff shows which files changed. A one-line bug fix that touches eight files needs a question before it needs a review.

4. Run an independent review. Save the defect-only prompt above as review-prompt.txt and run codex review - < review-prompt.txt, or paste it after /review in the TUI. A custom prompt replaces the target flags, and with a custom prompt and no target flag the reviewer decides the scope from your wording, so name it explicitly (“Review my uncommitted changes…”). The review runs in a fresh context, not the one that wrote the change. Fix every P0 and P1 before committing; decide on P2 and P3 yourself.

5. Validate machine output mechanically. For --output-schema runs, check the file with jq in the script (for example, jq -e '.endpoints | length > 0' endpoints.json) and fail the step when it does not hold.

You sign off on behaviour: the tests and the review findings. To run the same review on every pull request for the whole team, use the layered setup in Code review with Codex.

How do you point Codex at the right directories?

# Use another directory as the working root without cd
codex -C ~/src/shop-api "Explain how orders are persisted"

# Make a second directory writable next to the workspace
codex -C apps/web --add-dir ../api "Rename the orderId field in the web client and the API together"

# Run exec outside a Git repository
codex exec --skip-git-repo-check "Write a Python script that deduplicates rows in data.csv by email"

codex exec refuses to run outside a Git repository without --skip-git-repo-check. The check exists because Git is your undo button; use the flag only for throwaway directories.

For shell completions, generate the script for your shell and load it, for example eval "$(codex completion zsh)" in ~/.zshrc after compinit. When something about the installation looks wrong, codex doctor checks the installation, config, authentication and runtime health.

For cloud tasks, codex cloud (marked experimental in 0.157.1) submits, lists and applies tasks from the terminal: codex cloud exec --env <ENV_ID> "…", codex cloud list, codex cloud diff <TASK_ID> and codex cloud apply <TASK_ID>. Environment setup and best-of-N are covered in Codex cloud environments.

What breaks when you drive Codex from the CLI?

• codex resume --last opens the wrong session. --last only sees interactive sessions started in the current directory. Add --all for other directories and --include-non-interactive for sessions that codex exec started. Better: /rename the thread and resume it by name.
• Two forks overwrite each other’s files. A fork copies the transcript, not the working tree. Start each fork in its own worktree with --worktree, or run them one after the other.
• codex exec resume rejects --sandbox. In 0.157.1, codex exec resume has no --sandbox flag (checked with codex exec resume --help). Pass the setting as config instead: codex exec resume --last -c sandbox_mode="workspace-write" "…".
• codex exec -a never fails with “unexpected argument”. codex exec has no -a of its own in 0.157.1, and needs none: it already runs with approval never (on-request under --approve-for-me), and a codex -a never exec … prefix does not change that. Drop the flag, check the approval: line in the run header, and limit the run with the sandbox or a permission profile.
• A copied command uses --full-auto or -a on-failure. Neither works in 0.157.1: --full-auto is gone from codex and codex exec, and -a accepts only on-request and never. Use --sandbox workspace-write, or --approve-for-me to route approval requests through automatic review.
• A slash command does nothing. /compact, /new, /review and several others are unavailable while a turn is running. Press Esc, then run the command.
• -i a.png "prompt" treats your prompt as a file. In 0.157.1 -i keeps taking arguments until the next flag, so a prompt after it becomes a file path, even with -i a.png,b.png (checked with codex exec 0.157.1). Put the prompt first, use --image=a.png,b.png, or end the list with --.
• Never reach for --dangerously-bypass-approvals-and-sandbox to get past an approval. It disables the sandbox as well; it is meant only for runs that are already inside an external, disposable sandbox.

For recovery from sandbox denials, context overflow and wrong-direction edits in general, see Codex error recovery.

Where to go next with the Codex CLI

• Set defaults once instead of passing flags: Codex configuration.
• Put Codex in scripts and CI: Run Codex non-interactively with codex exec.
• Run several forks in parallel safely: Codex worktrees and multi-agent workflows.
• Short daily speed-ups for the CLI and the app: Codex efficiency hacks and Codex app mastery.
• The same ideas in Claude Code: slash commands mastery and Claude Code command line.