Codex Command Cheat Sheet: From Basic Usage to a Reliable Workflow

This article is for people who have installed Codex CLI but still use it mainly as “ChatGPT inside a terminal”. Codex becomes much more useful when you stop treating it as one long chat and start using its commands to separate one-off questions, persistent sessions, automation, code review, context management, and permission control.

Many people start with Codex by opening a terminal, typing a request, and waiting for an answer. That works, but it quickly creates two problems:

1. You are not sure when Codex should edit code directly and when it should only analyze.
2. You have to explain the project background, permission boundary, and task goal again and again.

A better way is to understand Codex commands in a few groups:

• startup and login
• interactive sessions
• non-interactive execution
• review and applying changes
• session resume and fork
• permissions, sandboxing, and configuration
• MCP, plugins, and extensions

Below is a practical command guide ordered by how often you are likely to use them.

1. Install and log in: make sure Codex can run first

You can install Codex CLI with npm or Homebrew:

npm install -g @openai/codex
# or
brew install --cask codex

Then run:

codex

On first use, Codex usually asks you to log in. You can sign in with your ChatGPT account or use an API key:

codex login

If you want to use an API key, pass it through stdin:

printenv OPENAI_API_KEY | codex login --with-api-key

Check login status:

codex login status

Log out:

codex logout

These commands answer the basic question: can Codex run correctly? Once authentication is ready, the rest of the workflow becomes useful.

2. codex: the main interactive entry point

The simplest entry point is:

codex

It opens an interactive session. You can describe a task inside it, for example:

Review this project startup flow and point out the three most fragile areas.

You can also pass the first prompt directly:

codex "Read this repository and summarize its module structure"

Use -C to specify the working directory:

codex -C /path/to/project "Analyze this project's test structure"

Common options include:

codex -m gpt-5.5 "Refactor this function"

codex --search "Check the latest docs and see whether this SDK usage is outdated"

codex -s workspace-write "Implement this feature, but only modify files in the current workspace"

My rule of thumb:

• Use codex when you want to work interactively.
• Use codex exec when you want a task to run once and finish.
• If the task scope is unclear, ask Codex to analyze and plan before giving it write access.

3. Slash commands inside an interactive session

After entering codex, type / to see available slash commands. These commands are more like a session control panel than normal chat messages.

/model: switch model

/model

Use it to inspect or change the model for the current session.

If a task requires stronger reasoning, switch to a stronger model. If you only need a small copy edit or light analysis, a faster model may be enough.

/fast: toggle fast mode

/fast on
/fast off
/fast status

This is useful for small edits, quick questions, and simple code navigation. For complex refactors, cross-module analysis, or production debugging, do not blindly optimize for speed.

/plan: ask for a plan before editing

/plan

Or:

/plan Design a migration plan for this service while keeping the old API compatible

This is one of the most useful commands. Very often you do not want Codex to act immediately; you want it to explain the risk, steps, and impact first.

Use /plan for:

• core module refactoring
• database schema changes
• API behavior changes
• large frontend changes
• deployment workflow changes

A good habit: ask for a plan first, confirm the direction, then let Codex implement.

/review: ask Codex to review code

/review

Use it before committing. Codex will focus on possible bugs, edge cases, and regression risks.

If you want Codex not only to write code but also to catch problems, use this command often.

/diff: inspect what changed

/diff

When Codex modifies many files, do not commit immediately. Use /diff to see the changed scope and make sure it did not touch unrelated files.

Pay extra attention when it changes:

• configuration files
• test snapshots
• lock files
• frontend, backend, and scripts at the same time

/status: inspect session state

/status

Use this to check the current model, permissions, workspace, and configuration. It is helpful when you wonder why Codex cannot write files, why web search is unavailable, or why the current directory is wrong.

/permissions: adjust permissions

/permissions

Codex’s capability depends not only on the model, but also on the permissions you give it.

Permission controls answer questions like:

• Can it write to the current workspace?
• Can it run commands?
• Does it need confirmation every time?
• Are there additional readable directories?

For important repositories, keep permissions conservative: read first, plan next, then allow writing.

/sandbox-add-read-dir: add a read-only context directory

/sandbox-add-read-dir /path/to/another/repo

Sometimes a task needs to reference another repository, but you do not want Codex to modify it. Add that path as read-only context.

Typical use cases:

• a new project needs to reference an old implementation
• backend work needs frontend type definitions
• a new service needs to match an old service API
• documentation work needs another reference directory

/mcp: inspect MCP tools

/mcp

If you configured MCP servers for databases, browsers, internal tools, GitHub, Linear, or other systems, this command shows the tools currently available to Codex.

MCP lets Codex reach beyond the codebase, which also means permission boundaries matter more. Decide in advance what it can read, write, and execute.

/init: generate project rules

/init

This is commonly used to initialize project rules such as AGENTS.md. That file can record conventions like:

• code style
• test commands
• branch rules
• directory explanations
• paths that should not be changed
• pre-release checks

If you use Codex on a long-running project, AGENTS.md is very important. It reduces the amount of project context you have to repeat in every session.

/compact: compress context

/compact

Long sessions accumulate a lot of context. /compact summarizes earlier conversation into a shorter form while preserving the main task state.

Use it when:

• a task has been running for a long time
• you have looked up many references
• the first half is done and you are moving into implementation
• Codex starts forgetting earlier constraints

/clear, /new, /quit

/clear
/new
/quit

These commands clean up or end sessions:

• /clear: clear the current context
• /new: start a new session
• /quit or /exit: leave Codex

Do not keep unrelated work in one long session. One session should usually have one clear goal.

4. codex exec: use Codex as a scriptable tool

codex exec runs in non-interactive mode. It is useful for automation, batch processing, CI assistance, and log analysis.

Basic usage:

codex exec "Summarize this repository structure and list five risk areas"

Pipe command output into it:

npm test 2>&1 \
  | codex exec "Summarize the failing tests and suggest the smallest likely fix"

Analyze logs:

tail -n 200 app.log \
  | codex exec "Identify the likely root cause and suggest the next debugging steps"

Generate release notes:

codex exec "Generate release notes from the last 10 commits" \
  | tee release-notes.md

Write the final message to a file:

codex exec "Extract project metadata" -o project-summary.md

If you want Codex inside scripts or automation, exec is usually better than the interactive TUI.

5. codex review: dedicated code review

Besides /review inside a session, Codex also has a standalone review command:

codex review

Review uncommitted changes:

codex review --uncommitted

Review against a base branch:

codex review --base main

Review a specific commit:

codex review --commit <SHA>

Add custom review instructions:

codex review --uncommitted "Focus on concurrency safety, permission checks, and database migration risk"

This is useful before committing, especially after Codex has written code. Let it look at the change again from a reviewer’s perspective.

6. resume and fork: reuse the context you already built

The most valuable part of a Codex session is not a single answer. It is the context Codex has already learned.

Resume the latest interactive session:

codex resume --last

Resume a specific session:

codex resume <SESSION_ID>

Non-interactive mode can also resume:

codex exec resume --last "Continue fixing the issues you found"

If you want to branch from an existing session without polluting the original context:

codex fork --last

Use resume to continue the same task. Use fork to explore another direction.

7. apply: apply a Codex-generated change

If you use Codex Cloud or a remote task flow, you may receive a task ID. Apply its diff locally with:

codex apply <TASK_ID>

After applying, immediately check three things:

git diff

npm test
# or your project's test command

git status -sb

Do not treat apply as an auto-merge button. It only brings the change into your workspace. You still decide whether to accept it.

8. Sandbox and approvals: control what Codex can do

Codex permissions revolve around two ideas:

• sandbox: what Codex can access and modify
• approval: when Codex must ask you for confirmation

Common sandbox modes:

codex -s read-only
codex -s workspace-write
codex -s danger-full-access

A practical interpretation:

Common approval policies:

codex -a on-request
codex -a never
codex -a untrusted

Daily recommendations:

• Reading and asking questions: read-only
• Normal feature work: workspace-write + on-request
• Automation: use never carefully
• Do not casually use danger-full-access on an important machine

9. Configuration: keep repeated preferences in files

Codex configuration usually lives at:

~/.codex/config.toml

A project can also have:

.codex/config.toml

Use -c to override config for one run:

codex -c model="gpt-5.5" "Analyze this module"

Use profiles when you have multiple working modes:

codex --profile work

A simple example:

model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[features]
web_search = true

Put long-term preferences in config files. Put task-specific choices in command-line flags.

10. MCP and plugins: connect Codex to external tools

Manage MCP servers:

codex mcp list
codex mcp get <name>
codex mcp add <name> <command>
codex mcp remove <name>

If an MCP server requires login:

codex mcp login <name>
codex mcp logout <name>

Plugin entry point:

codex plugin marketplace

MCP and plugins are not required on day one. A better learning order is:

1. Learn codex and slash commands.
2. Learn codex exec for automation.
3. Add MCP and plugins when you need external systems.

Otherwise, the toolchain and permissions become complicated before your basic workflow is stable.

11. A daily workflow that works

If you are new to Codex, try this rhythm.

Step 1: ask it to read the project

codex -C /path/to/project "Read the project structure, explain the main modules and startup flow, and do not modify files"

Step 2: ask for a plan

/plan Design an implementation plan for this feature. List files to change, risks, and tests.

Step 3: confirm, then implement

Implement the plan with the smallest reasonable change and add necessary tests.

Step 4: inspect the diff

/diff

Step 5: review

/review

Or from the terminal:

codex review --uncommitted "Focus on regression risk and edge cases"

Step 6: run tests and pipe failures back

npm test 2>&1 | codex exec "Summarize the failure and suggest the smallest fix"

This workflow is better than simply telling Codex to keep editing until everything passes. It separates planning, implementation, review, and verification.

12. Common mistakes

Mistake 1: giving broad permissions too early

danger-full-access feels convenient, but it is the easiest way to create damage. Unless you are in a container, temporary machine, or otherwise isolated environment, do not make it the default.

Mistake 2: putting every task into one long session

Writing a feature, editing copy, debugging production, and refactoring config in the same session will eventually confuse the context. When the task boundary changes, use /new.

Mistake 3: not reading the diff

AI coding tools often make “extra” changes. They may reformat files, update dependencies, touch snapshots, or edit configuration. Always inspect the diff after implementation.

Mistake 4: no project rules

Long-running projects need AGENTS.md or project-level rules. Otherwise you repeat test commands, directory conventions, commit habits, and forbidden paths every time.

Mistake 5: treating exec as autopilot

codex exec is excellent for automation, but it does not remove responsibility. Any task that writes files, sends requests, deploys, or deletes data needs clear permissions and verification.

Conclusion

Codex is not just another AI chat window. It is more useful when you turn coding work into a controllable workflow:

• use codex for interactive collaboration
• use slash commands to manage model, plan, permissions, and context
• use codex exec for automated analysis and batch tasks
• use codex review before committing
• use resume and fork to reuse or branch existing context
• use sandbox, approval, and config files to control risk

If you only remember one suggestion: do not let Codex edit immediately. First let it read the project, write a plan, and explain risks. Then open the right permissions for implementation. It feels a little slower, but the result is usually much safer.