Codex CLI Cheat Sheet: Commands and Session Workflows
A task-oriented command reference for the Codex CLI, covering session setup, approval modes, output options, and keeping a clear handoff when the terminal closes.
Updated 4 min read
This reference covers the Codex CLI commands you use most in a working session: starting the tool, controlling approval levels, scoping which files it reads, and ending cleanly. It is organized by task so you can scan for the command you need rather than reading the whole thing.
Commands tell the tool what to do in the current session. What the tool should always know — project rules, active tasks, decisions that outlive a terminal window — belongs in an outside record. fenbs keeps that record and connects to the CLI over MCP, so every session starts with the same agreed context.
Start a session
The basic invocation passes the task as a quoted string. Run it from the directory you want the tool to read:
codex "refactor the auth module to use async/await"
You can also open an interactive session without a task, then type requests in the prompt:
codex
Control the approval level
The --approval-mode flag sets how much the CLI does without asking:
| Mode | What it does | When to use it |
|---|---|---|
suggest | Proposes each file change and waits for your confirmation before writing it. | Default. Use for production code and unfamiliar projects. |
auto-edit | Applies file edits automatically. Pauses before running shell commands. | Use when you trust the task scope and want faster iteration. |
full-auto | Applies edits and runs shell commands without prompting. | Use only in an isolated sandbox or CI environment. |
codex --approval-mode auto-edit "add unit tests for the parser"
Scope what the CLI reads
By default, Codex CLI reads files in the current directory. You can point it to a specific directory or give it additional context with a system prompt file:
codex --system-prompt-file ./context.md "fix the failing tests"
Use a system prompt file for context that does not change between sessions: coding conventions, test requirements, or a description of what the project does. For context that changes as the work evolves — current tasks, recent decisions, Where we left off — a connected fenbs project is a better fit than a static file.
Use quiet and JSON output modes
Two output flags are useful when you script around the CLI or want a less verbose terminal:
codex --quiet "generate a changelog entry for v2.1.0"
codex --json "list the exported functions in src/api.ts"
The --json flag streams each event as a JSON object on its own line. This makes it straightforward to pipe into jq, write to a log, or trigger downstream steps. The codex cli json output guide explains the event types and how to parse them.
Common session workflow
A reliable session follows this pattern:
- Read the project context from fenbs (rules, active tasks, Where we left off) before starting the first task.
- Give the CLI one clear task at a time. Compound tasks ("refactor X and add tests and update docs") are harder to review and easier to get wrong.
- Review every diff before approving. The
suggestmode keeps you in the loop. - After completing a task, ask the CLI to record a brief progress note: what was done, what was checked, and what comes next.
- Before closing the terminal, ask the CLI to save Where we left off so the next session starts from a known point.
Give every session the same starting point
fenbs keeps project rules, active tasks, Decisions, and Where we left off outside the terminal. Connect Codex CLI over MCP from Integrations and ask it to read the project context at the start of each session. Create a free account, add your project, and write the rules that should survive every terminal restart.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Session continuation across terminals
Codex CLI does not carry state between invocations. Each new shell that runs codex starts fresh. There are three ways to continue a session's work:
- Use a terminal multiplexer (tmux, GNU Screen) to keep the shell running while you disconnect.
- Pass a system prompt file that describes the current task and relevant context.
- Ask a connected fenbs project for the project context at the start of the new session.
The MCP approach is the most durable: the context lives outside any one machine, so it survives a reboot, a new laptop, or a colleague picking up the work. See codex cli best practices for a fuller discussion of session handoffs.
Useful flags at a glance
| Flag | What it does |
|---|---|
--approval-mode <mode> | Set the approval level: suggest, auto-edit, or full-auto. |
--quiet | Reduce terminal output to the essentials. |
--json | Stream events as JSON objects, one per line. |
--system-prompt-file <path> | Load additional context from a Markdown or plain-text file. |
--model <name> | Choose a specific OpenAI model for the session. |
--help | List all available flags and options. |
How to do this with fenbs
- Create a free account and add your project with a short description and current tasks.
- Connect Codex CLI to fenbs over MCP from Integrations. Sign in with a browser.
- At the start of each session: ask Codex CLI to read the project context from fenbs before it starts work.
- During the session: give it one task at a time, review each diff, and ask it to record progress on completed tasks.
- Before closing the terminal: ask it to save Where we left off, including the next step and anything waiting on a person.
The --help flag prints all available flags and their descriptions in the terminal — use it when you are unsure about a flag or want to check what changed in a newer version. The agent harness topic hub collects related guides, including codex cli on windows for Windows setup and codex subagents for running multiple agents in parallel.