Codex CLI Commands: Everyday Tasks, Sessions, Reviews and Safety

You do not need to memorize the full reference. Learn the commands that match the next job: start, continue, automate, inspect or review. Keep the rarer administration commands for the day you actually need them.

The short command set

Use this table as a menu. Pick the job first, then use the command that fits it.

Terminal commands and slash commands are different

Top-level commands run in your normal shell. Running codex without a subcommand opens the interactive terminal interface. Commands such as codex resume, codex exec and codex review also begin in the shell.

Slash commands run after the Codex session is open. They change or inspect the current chat. If your shell says that /status is not a command, you entered it in the wrong place. Start codex first, then type the slash command inside the session.

Five terminal jobs for everyday work

codex: start an interactive task

Use the interactive session when you need a conversation with the repository. It suits exploration, a multi-step change or a task where you expect to steer the work. Start from the project directory so the working context is the project you intend to inspect.

codex resume: continue with context

codex resume continues a saved interactive session. It can also return you to the most recent chat. Resume when the objective is still the same and the earlier discussion remains useful. Start fresh when the new task has a different goal, repository or approval boundary.

codex resume --last

The --last flag continues the most recent saved session without opening the session picker.

codex exec: run one bounded task

codex exec runs Codex non-interactively. It can stream normal or machine-readable output. It can also resume or fork earlier execution sessions. Use it for a repeatable check with a clear finish line. Choose an interactive session for an open investigation that needs several decisions.

codex exec --json "Find the test that covers the login redirect. Return the relative path and do not edit files."

The --json flag prints events as JSONL for a script or another machine-readable consumer. The prompt limits the target, the output and the permission. If the task will write files, name the expected change and the test that should pass. A bounded instruction is easier to review than “fix the repository.”

codex review: review a chosen target

codex review can review uncommitted changes, a comparison with a base branch, one commit or custom review instructions. Choose one target. A review request that mixes several unrelated changes makes it harder to judge whether each finding belongs to the work.

codex review --uncommitted

codex review --base <BRANCH>

Use the first form for staged, unstaged and untracked work. Use the second to compare the current work with the base branch you name.

codex fork: try another path

Fork when you want to keep the original session and explore another approach from the same context.

codex fork --last

The --last flag forks the most recent session without opening the picker.

Six slash commands that keep a session useful

/permissions sets what Codex can do without asking. Use it before the first change, not after a surprising command. /status shows the active model, approval policy, writable roots and remaining context. Together, they answer two basic questions: what can this session do, and where can it do it?

/plan switches the current chat into plan mode before implementation. Use it when the change has several dependent steps or when the cost of a wrong approach is high. A tiny rename does not need ceremony. A migration or unfamiliar subsystem usually does.

/diff shows the Git diff, including untracked files. Read it before tests and again before committing. /review asks Codex to review the working tree for problems. It is another check, not the approval decision.

/compact summarizes the visible chat to free context in a long session. Use it when the conversation remains on the same objective but earlier detail is crowding the current work. Start a new chat when the objective itself changes.

A safe daily workflow

Set permissions, confirm status, plan the task, do the work, inspect the diff and run the review. Then run the relevant tests yourself and decide whether the result satisfies the request.

Set permissionsConfirm statusPlan the taskDo the workInspect the diffRun the review

The order matters. Permissions come before action. The diff and tests come before approval. Review can find a missed problem. It cannot decide whether the change matches your business rule or whether a deployment is acceptable.

Choose the narrowest permission level that works

The CLI supports read-only, workspace-write and danger-full-access sandbox policies. Read-only is useful for inspection. Workspace-write fits ordinary project work that should stay inside the repository. Danger-full-access removes an important boundary and should not be the normal answer to a blocked command.

OpenAI advises against bypassing approvals and the sandbox unless the CLI is already inside a dedicated sandboxed environment. Grant one extra directory instead of opening the whole machine. A permission is part of the task design, not a shortcut around it.

The same evidence rule applies to AI visibility work

Command safety is one example of a wider rule: keep the question, evidence and approval connected. Xtrusio asks supported AI engines the buyer questions that matter and records the answers, brand mentions and citations. It can then draft a question-linked content plan from the engines' searches and citations, with a person approving the plan before it is saved.

Xtrusio also states that AI suggestions do not replace client approval. The same idea applies here. An agent can propose, edit and review, but the person responsible for the project decides whether the result is ready.

When to resume, compact or start fresh

Choose by the state of the task. Keep useful context, but do not drag an old objective into new work.

Common command mistakes

Most problems come from using the right command with the wrong boundary. Others happen when a command runs at the wrong point in the workflow.

• Typing a slash command in the shell. Open the interactive session first.
• Granting broad access before the task is clear. Begin with the narrowest boundary that can complete the job.
• Using codex exec for an open-ended investigation. Use the interactive session when you expect to steer.
• Skipping /diff because the answer sounds confident. Inspect the files, then run the relevant tests.
• Treating /review as approval. It is an extra issue-finding pass. The human still accepts or rejects the work.

Official sources

These pages describe the command surface and the product workflow used for this guide.

1. OpenAI Codex CLI command reference
2. OpenAI Codex CLI overview
3. Xtrusio managed AI visibility workflow