The Codex CLI Slash Commands, Explained

Slash commands are how you talk to the CLI itself mid-session, distinct from talking to the model — /init, /status, /permissions, /model and /review each change something about the session's configuration or state rather than asking Codex to do a piece of work.

/init — writing your project's AGENTS.md

Running /init has Codex write an AGENTS.md file for the current project — a place for project-specific context and conventions that future sessions can read automatically, rather than you re-explaining the same background every time you start a new session. This is worth running early in a new project specifically because the file it produces becomes more useful the earlier it exists — every session after that point benefits from it, not just the one where you happened to run the command.

/status — what a session actually knows

/status reports on the current session's state, which is the fastest way to answer "wait, what model is this actually running" or "what sandbox mode am I in" without guessing from behavior. Given how much confusion this site's own most-read page is built around — the CLI's actual default model not being the one its name suggests — running /status at the start of any session where the model matters is a cheap habit that removes an entire category of budgeting mistake.

/permissions — adjusting sandbox and approval mid-session

Rather than restarting a session to change sandbox or approval mode, /permissions adjusts it in place. That's useful for a session that started conservatively — read-only, say — and needs to make an actual edit once you've seen what it's proposing, without losing the context already built up in the conversation so far.

/model — switching mid-session

/model changes which model answers for the rest of the session. This is the direct mechanism behind a lot of this site's own guidance about choosing a different model than the CLI's default — rather than restarting with a flag, switching mid-session lets you start broad with the default and drop to a cheaper or more specialized model once you know what the task actually needs, or the reverse, escalating to a larger-context model partway through if a task turns out to need more room than expected.

/review — a dedicated review pass

/review triggers a review-focused pass over recent changes, distinct from asking a normal conversational question about the diff. Where the two differ in practice is worth checking against the CLI's own current documentation, since this is exactly the kind of subcommand behavior that's evolved across releases — but the existence of a dedicated review command is itself a signal that reviewing a diff is treated as a distinct workflow from generating one, not just "ask the same session to check its own work."

Why these are worth learning early, not as-needed

Slash commands are cheap to run and mostly informational or configurational rather than destructive, which makes them low-risk to explore — running /status a few extra times costs nothing. Learning what's available before you need it, rather than discovering /permissions exists mid-task when you're already frustrated by a sandbox restriction, is a small investment that pays off the first time you actually need one of these mid-session.

Checking what's current

Flag names and slash commands are exactly the layer of the CLI that changes fastest across releases — a command that behaved one way several versions ago may have gained options or changed its output format since. Running a bare /help-equivalent inside a session, or checking the CLI's own current documentation, is worth doing periodically rather than trusting a fixed mental model of what each command does indefinitely.

Combining slash commands with flags

Slash commands operate on a running session; flags like --sandbox and --ask-for-approval set the starting configuration a session launches with. The two aren't competing mechanisms — flags decide where a session starts, slash commands adjust it once you're inside one — and knowing both exist is what lets you start conservative and loosen restrictions deliberately as a task's real needs become clear, rather than guessing the right configuration up front and living with a wrong guess for the whole session.

A realistic first-session sequence

A reasonable pattern for a brand-new project: run /init first so every subsequent session in the project benefits from the AGENTS.md it produces, then /status to confirm which model and sandbox mode you actually started with before assuming anything. From there, work normally, reaching for /permissions the moment a task needs more access than the session started with, and /model only when the task's actual shape — not a hunch — suggests a different model would serve it better. /review fits naturally at the end, once there's a real diff worth a dedicated pass over.

What isn't a slash command

It's worth being clear about the boundary: ordinary requests — "fix this bug," "add a test for this function" — are conversation, not slash commands, and they're what a session spends most of its time on. Slash commands are specifically the small, fixed set of session-management actions layered on top of that conversation. Treating every instruction as if it might be a slash command, or forgetting that slash commands exist and re-explaining configuration in plain language instead, are both minor inefficiencies worth avoiding once you know the actual list is short and fixed.

Where to find the authoritative, current list

This page describes the five slash commands documented at the time of writing, but the CLI's own --help output and its current published documentation are the two places to confirm the list hasn't grown since — a static guide like this one is a snapshot, and the CLI's own most fast-moving surface is exactly where a snapshot ages fastest.