Codex CLI Commands Explained: Sessions, Forks &

There's a gap between "I have access to a tool" and "I know what this tool is actually doing." Codex CLI has been out long enough that a lot of developers are using it—but using it the way you use a microwave, pressing buttons until something warm comes out. The Software Engineer Meets AI channel's Part 2 walkthrough of Codex CLI commands is aimed squarely at closing that gap. And it's worth paying attention to, because a few of these commands involve concepts that aren't as obvious as they first appear.

Let's get into it.

The statefulness illusion (and why /new matters)

Here's something the video surfaces early that deserves more attention than it usually gets:

"It's not a known fact that the model we are using with Codex CLI are stateless—and every time you send a new prompt, you send the whole history and the responses from the model."

This is one of those things that seems like a footnote until you really sit with it. When you're having what feels like a continuous "conversation" with Codex, the model isn't actually remembering anything. Every time you send a message, your entire conversation history is being bundled up and sent along with it. The continuity is an illusion constructed by the client—not something that lives inside the model.

That context—the background the model is being handed on every call—grows with every exchange. The /new command exists to wipe the slate clean. No history, no accumulated context, fresh start. That sounds simple, but understanding why you'd want it (not just how to use it) changes how you think about session hygiene.

/rename before you /resume

The /resume command lets you return to a previous session and pick up from where you left off. Useful on its face. But there's an immediate practical problem: sessions get auto-named in ways that won't mean anything to you three days later. This is where /rename earns its keep.

The workflow the video demonstrates is clean and sensible: start a session, do some meaningful work to establish context, then /rename it to something human-readable (the demo uses "context of all dev needs") before you walk away. Then when you come back and run /resume, you're looking at a list of sessions that actually make sense, rather than a graveyard of timestamps.

It's the equivalent of naming your browser tabs instead of having 47 that say "New Tab." Mundane, but the difference between a workflow that scales and one that collapses under its own weight.

/fork: the most underrated command in the set

This one is worth slowing down for. /fork lets you branch the current conversation into a new session, preserving the original context while giving you a clean divergence point for a new line of work.

The use case presented: you've built up a really useful context in a session—the model understands your codebase, your conventions, what you're trying to do. Now you want to tackle a new feature. You could just keep prompting in the same session, but that pollutes the context with two separate streams of work. /fork lets you spin off a parallel session that inherits the good context without contaminating it.

"With the fork command, I can fork and diverge the current conversation I have and have two new sessions. That way I can keep working on a new feature in a new session. Meanwhile, I have the option to keep working with this context in the near future."

If you've worked in version control, this maps neatly onto branching. The main session is your main branch. The fork is your feature branch. The original stays clean.

What the video doesn't fully unpack is the question of when to fork vs. when to just /new. The rough heuristic seems to be: if you want to preserve the existing context for potential future use while exploring something new, fork. If you're genuinely done with the current context and want a clean break, new. Those are different situations with different right answers.

/compact: the context budget problem

Here's where the statefulness picture gets more financially interesting. Because every prompt sends the full conversation history, longer sessions consume more tokens. More tokens mean faster subscription limit consumption. The /compact command summarizes the conversation history, stripping it down to the essential information so the context stays useful without staying large.

Codex CLI even surfaces this as an in-app tip: "Use compact when conversation gets long to summarize history and free up context."

There's a real design tension here. Summarizing is lossy—some nuance in the earlier conversation will get flattened. The model's summary of what happened isn't the same as what actually happened. Whether that matters depends on how precise the earlier context needs to be for your current task. For most "I've been working on this codebase for a while" situations, the summary is probably fine. For conversations where exact earlier exchanges matter, you're trading fidelity for budget.

This is worth knowing before you hit /compact reflexively every time a session gets long.

/init and the AGENTS.md controversy

/init generates an AGENTS.md file—a markdown document where you can give the model standing instructions for how to behave across sessions. Think of it as a persistent system prompt you control.

The presenter drops something interesting here almost in passing:

"A few months ago an academic paper was released and claimed that using agents.md does not lead to better results. They claim that if you use the model to create this agents.md like we do with the init command, you'll get too big an agents.md with redundant information."

This is the kind of thing that gets glossed over in tutorial content, so credit for mentioning it. The claim, if accurate, would be significant: the "let the model write your instructions" workflow that /init facilitates might actually produce bloated, ineffective instruction files. The paper's argument is essentially that auto-generated AGENTS.md files tend toward noise rather than signal.

The counterargument—which the video doesn't make, but is worth considering—is that the quality of auto-generated AGENTS.md depends heavily on how well you prompt the init process. Garbage in, garbage out. A manually curated AGENTS.md might still outperform both.

The research in question hasn't been universally replicated or endorsed, and it's worth tracking the ongoing discourse before taking it as settled. But it's a genuine open question about a workflow many Codex users are building around.

/plan, /goal, /agent: the mode-switchers

The video covers /plan briefly—it switches Codex into a planning mode where it maps out an approach before executing, rather than jumping straight into code. You can toggle it with Shift+Tab. The utility is situational: useful when you want to review the model's reasoning before it starts making changes, less useful when you already know what you want and just want it done.

/goal and /agent are positioned as the commands you need to truly master Codex CLI—but the video explicitly defers them to dedicated episodes rather than treating them here. That's not evasion; it's appropriate scoping. These are deeper concepts that benefit from focused treatment.

So what's the actual mental model?

Stripping it down: Codex CLI is a stateless system that simulates stateful sessions through context management. The commands covered here—/new, /resume, /rename, /fork, /compact—are essentially a toolkit for managing that context deliberately rather than letting it accumulate by default.

The interesting underlying question is how much of this should be manual at all. Right now, developers are expected to think about context budgets, decide when to fork, remember to rename before they forget what a session was about. That's cognitive overhead. As these tools mature, it's reasonable to ask whether smarter automatic context management could handle more of this—or whether giving users explicit control is itself the point.

For now, though, the commands are the controls you have. Understanding what each one actually does—not just the syntax but the mechanism—is what separates a developer who uses Codex from one who wields it.

By Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag