Codex CLI Undo: Review and Revert the Right Changes

Codex CLI does not have a single undo command that reverses everything a session did. What it has are two separate tools: the ability to rewind a conversation within the session, and the ability to recover file changes through Git. Understanding which tool reaches which kind of change prevents you from looking for a button that does not exist.

A third layer matters for teams: the record of why a change was made and who approved it. A tool like fenbs keeps that context alongside the task, so a reversal is traceable without digging through terminal history.

What chat rewind does and does not do

Codex CLI lets you rewind the conversation to an earlier point in a session. This removes the later messages from the model's context, so subsequent answers come from the earlier state of the chat. It does not undo file changes that the agent already made.

Think of it this way: the conversation and the filesystem are separate. Rewind affects the conversation. The files on your disk reflect every write the agent made, regardless of where the conversation is now. If the agent wrote a file ten steps ago and you rewind to step five, the file is still changed.

Rewind is most useful when the agent has misunderstood the goal and you want to correct the conversation without restarting the whole session. It is not a reliable way to undo code changes.

Recover file changes with Git

If Codex CLI was run in a Git repository, which is the recommended way to work, every file change the agent made can be reviewed and undone through standard Git commands.

Check what the agent changed:

git diff          # changes not yet staged
git diff --staged # changes already staged

Discard all uncommitted changes in a file:

git checkout -- path/to/file

Discard all uncommitted changes in the repository:

git checkout -- .

If the agent committed changes and you want to undo a specific commit without losing the history:

git revert <commit-hash>

Use git log to find the commit hash. git revert creates a new commit that undoes the previous one, which keeps the history readable. See the codex cli best practices guide for tips on committing frequently so reversals are easier.

Take a snapshot before a risky session

If you are about to run a session with broad scope, take a Git snapshot first:

git stash
# or
git commit -m "checkpoint before codex session"

A stash saves your current state and can be restored with git stash pop. A checkpoint commit gives you a named point to revert to with git revert or git reset. Either approach gives you a clean return path if the session goes wrong.

Record the reason for a reversal

When you undo a change, record why. The Git history shows what changed, not why it was reversed. Without a note, the next session may make the same change again, believing it was never tried.

Useful things to record: what the change was trying to do, why it was reversed, and what the correct approach should look like. That note lives with the task, not in a commit message, because a commit message is a line of text while a task note can hold the context needed to understand the decision.

If the reversal taught something useful, record it as a Lesson: what was tried, why it did not work, and what to do differently. The codex cli commands guide lists the commands for reviewing the session output if you need to reconstruct what happened.

On a team, a reversal that only one person knows about is a gap. If you undo a change that another session may try to make again, record it somewhere every session reads before it starts. A short decision note, such as "do not modify the auth module directly; route changes through the service layer", prevents the same wrong approach from recurring in future work.

Reversals in automated and full-auto sessions

In a full-auto session, the agent makes changes without pausing for approval. Reversals after the fact are harder because there is no series of approval decisions to look back at. The Git history is the primary record of what changed.

For sessions where you intend to review before committing, run in plan mode or suggest mode. The agent shows you what it will do; you approve or decline each step. This makes reversals rare because you stop a bad direction before it changes any files. See codex cli plan mode for how that workflow looks.

How to do this with fenbs

1. Create a free account and add the task you are working on with its goal and plan.
2. Before a risky session, take a Git snapshot and note it on the task: "checkpoint at <commit hash> before this run".
3. If you revert changes after a session, update the task with what was reversed and why.
4. Record what should have happened differently as a Lesson in fenbs, linked to the task. Future sessions read lessons before similar work.
5. Connect Codex CLI from Integrations so the next session starts by reading the updated task plan, not the original one that led to the reversal.