Coding agents are everywhere now. Claude Code, OpenAI Codex CLI, Gemini CLI, OpenCode, plus a growing pile of IDE integrations. They generate boilerplate, suggest algorithms, and sketch out system components. And yet one feature, available in most of them, gets almost no attention: the /rewind command.

You won’t always see it called /rewind. It might be undo, backtrack, “fork conversation at some point”, or a UI gesture that deletes the last few turns. The job is the same. It prunes conversation history, rolling the agent’s memory back to an earlier state. If you’ve ever run git reset --hard or stepped backward through a debugger, the idea should feel familiar. It’s about taking control when things go wrong, and with agents, things will go wrong.

The “just one more prompt” trap

When an agent drifts off course, the developer instinct kicks in. Add more context. Clarify requirements. Push it back on track with a better message. We’ve spent years giving careful instructions to machines, so this feels right.

With LLMs it usually isn’t.

Each API call is stateless. The “session” you see is a client-side abstraction managed by the CLI or IDE. Every time you send a new prompt, the full conversation (your prompts, agent replies, tool calls, tool outputs) is bundled up and resent to the model. That’s the context.

When an agent makes a mistake, the mistake joins that context. Any correction you send is interpreted in light of the flawed reasoning already sitting in history. A few things go wrong from there:

1. Context contamination. The bad logic is baked in. New prompts get filtered through the old, wrong assumptions. It’s like debugging a function after a global was set to the wrong value five calls ago.
2. Reinforcement of bad paths. The agent often treats your correction as a request to tweak its existing (broken) approach, not abandon it.
3. Token bloat. Long corrective back-and-forths inflate costs and push against context window limits, which then forces older context to be dropped.
4. Dilution. A context stuffed with contradictions, dead-end code and retracted reasoning makes it harder for the model to focus on what you actually want.
5. Compaction going sideways. Once the context gets long enough, the harness compacts it by summarizing earlier turns. If the bad reasoning was in there, it can survive compaction as a “fact” in the summary, losing the surrounding nuance that would have flagged it as wrong. Now the mistake is baked in as background truth and you can’t even see it in the transcript.

You’re building new structures on a crumbling foundation. The fix isn’t more bricks. It’s tearing down the bad section.

/rewind: the developer’s Ctrl+Z for agent sessions

This is what /rewind is for. In Claude Code, either /rewind or pressing Esc twice opens a scrollable list of the prompts from your session. Pick the point you want to act on and choose what to revert:

• Restore code and conversation. Both move back together.
• Restore conversation. Rewind the chat, keep your current code on disk.
• Restore code. Roll back file changes, keep the conversation.
• Summarize from here. Compress everything from this point forward into a summary to free context window space.

That menu is the whole feature. Most of the time you want “restore code and conversation”, which drops everything after your chosen point (prompts, responses, tool calls, tool outputs) and reverts the files to match. Your next prompt is built on the pre-error state. The model sees a context without the flawed reasoning, the wrong code or the circular dialogue, and it gets a real second chance at your requirements.

The “restore conversation” option is useful in a few shapes. The agent’s reasoning went wrong but the code it produced happens to be fine. You want to keep a partial edit while retrying the prompt that led to it. Or, best case, the agent hasn’t touched any files yet (it’s still in planning) and you just need to kill the bad plan and start the planning turn over. “Restore code” is the opposite case: the conversation is worth keeping, but the files on disk need to go back.

“Summarize from here” is a different animal. It doesn’t restore anything. Messages before your selected point stay intact. The selected message and everything after it get replaced with a compact AI-generated summary. No files on disk change. The original messages are kept in the session transcript so Claude can still reference them if needed, but the active context the model sees is shorter. Useful for long sessions that aren’t broken, just bloated. The compaction caveat from earlier still applies though: anything flawed in the summarized range can survive as a “fact” in the summary, so don’t reach for summarize as a fix for a bad turn. Rewind for mistakes, summarize for length.

Roughly, the restore side of that menu looks like this in git terms:

git commit -m "Initial feature"
# Agent starts well.
git commit -m "Attempted to use deprecated API"
# Agent makes a mistake.
git commit -m "Trying to fix deprecated API with more prompts"
# You try to fix it, but things get worse.
git reset --hard HEAD~2
# This is /rewind. Two bad commits gone, clean slate, try again.

The mental model is the same. When the agent missteps, /rewind is your reset button.

Why statelessness makes /rewind work

Understanding the mechanism makes the value obvious. The LLM is stateless. The memory lives in the harness, which stores the full interaction like this:

[
    {"role": "user", "content": "Initial prompt..."},
    {"role": "assistant", "content": "Agent response 1..."},
    {"role": "tool_code", "content": "print(run_test())"},
    {"role": "tool_output", "content": "Test results..."},
    {"role": "user", "content": "Follow-up prompt..."},
    {"role": "assistant", "content": "Agent response 2 (mistake)..."}
]

/rewind just snips entries off the end of that array. The next prompt sends the pruned array to the model. No server-side session to untangle, just a direct edit of what gets sent on the next call. That simplicity is why the feature works reliably.

There’s a catch though. Agents also edit files. Whether your /rewind also rolls back those file changes depends on the tool (details in the next section). Where it doesn’t, you’re left with a manual step: getting your code back in sync with the rewound conversation.

This is another argument for asking the agent to explain its plan before it touches anything. If you catch the wrong reasoning in a plan, a rewind costs you one turn and zero file changes. If you catch it after the agent has rewritten six files, you’re either relying on the harness to revert them or cleaning up by hand. Plan first, act second, rewind cheap.

How different agents implement it

Terminology and scope differ quite a bit across tools.

Claude Code (/rewind). The most complete of the four. The five-option menu described earlier (restore both, restore conversation, restore code, summarize, never mind) is unique to Claude Code. Selector-based, so you jump to any point in the session instead of stepping back one turn at a time.

Gemini CLI (/rewind). Nearly the same model as Claude Code, minus the summarize option. /rewind or Esc twice opens an interactive list of previous interactions, with a preview showing the prompt and how many files changed at that step. After picking a point, you get up to three actions: rewind conversation and revert code, rewind conversation only, or revert code only. If no files changed after the selected point, the code-related options are hidden. One useful note from their docs: rewind only undoes edits made by the AI’s edit tools. Manual edits and anything done through the shell tool (!) stay put.

OpenAI Codex CLI. The most limited of the four. No /rewind command at all. You press Esc twice with the composer empty, keep tapping Esc to walk further back through the transcript, then hit Enter to fork from that point. That’s it: no scrollable list, no file-change previews, no per-checkpoint actions, no summarize mode. And file edits already applied to disk stay applied. You’re on your own with git diff, git restore or git reset to line the files back up with the rewound conversation. Users have been asking for the fuller feature set for a while (issues #11626, #11742 and #12558 in the Codex repo all request variants of it, with #12558 explicitly pointing at Claude Code’s menu as the target). Open, no PR yet.

OpenCode (/undo, /redo). Linear undo and redo instead of a selector. /undo (or Ctrl+X U) steps back one turn, and /redo (or Ctrl+X R) rolls forward. Conversation and file changes move together, with no option to separate them the way Claude Code lets you. The project has to be in a Git repo, but it doesn’t undo your commits. OpenCode keeps its own per-turn snapshot layer built on Git plumbing, so you don’t need to commit manually between prompts for /undo to work. Worth knowing though: there are reported bugs (stale snapshots reverting files to older states, undo rolling back the message but not the files, rollbacks occasionally reaching further back than the last turn). So even with the snapshot system, an undo here can still take more than you expected.

The short version: all agents manage conversation context, but whether “rewind” also covers your working tree varies. That difference decides how much cleanup you’re doing by hand.

When to reach for it

A couple of cases where /rewind isn’t just nice to have.

Example 1: the schema that got too clever (MySQL)

You’re adding user preferences and prompt the agent:

We need to store user preferences. Each user can have multiple preferences, identified by a key, with a string value. Some preferences are global presets, others are user-specific overrides. Design a schema for MySQL.

The agent goes full textbook and produces a three-table design:

CREATE TABLE preference_keys (
    id INT AUTO_INCREMENT PRIMARY KEY,
    key_name VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE global_preferences (
    id INT AUTO_INCREMENT PRIMARY KEY,
    preference_key_id INT NOT NULL,
    value TEXT NOT NULL,
    CONSTRAINT fk_global_preference_key FOREIGN KEY (preference_key_id) REFERENCES preference_keys(id)
);

CREATE TABLE user_preferences (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    preference_key_id INT NOT NULL,
    value TEXT NOT NULL,
    CONSTRAINT fk_user_preference_key FOREIGN KEY (preference_key_id) REFERENCES preference_keys(id),
    CONSTRAINT fk_user_id FOREIGN KEY (user_id) REFERENCES users(id)
);

It’s overkill. For simple key/value with overrides, one table with a nullable user_id handles it with fewer joins.

The “more prompting” path: “This is too complex, simplify, merge tables.” The agent will often patch its own design rather than abandon it, giving you a halfway-merged schema that still carries the original assumptions.

The /rewind path: go back one turn and send a tighter prompt.

Design a single user_preferences table for MySQL. Columns: user_id (nullable for globals), key_name, value. Include a unique index on (user_id, key_name) and an index suitable for looking up globals where user_id IS NULL.

Now you get:

CREATE TABLE user_preferences (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NULL,
    key_name VARCHAR(255) NOT NULL,
    value TEXT NOT NULL,
    UNIQUE INDEX idx_user_key (user_id, key_name),
    INDEX idx_key_name (key_name)
);

A much better starting point, without the baggage from the first attempt.

Example 2: the refactor that broke login (Python/Flask)

You ask the agent to refactor auth.py, splitting one big function that handles registration, login and profile into smaller pieces with clear separation of concerns. Endpoints should behave identically.

The agent splits things up, but in the process it swaps to a slightly different password hashing call, or changes how session['user_id'] gets set, or introduces a circular import between the new modules. Tests fail. Login breaks for existing users because the hash format changed.

The “more prompting” path: “Revert the password hashing change, keep session handling identical.” The agent patches the hashing, but session handling stays subtly off, and a week later you find another regression. You’re fixing symptoms because the agent’s mental model of the original file is already wrong.

The /rewind path: go back past the refactor and restart with constraints that close off the bad branches up front.

Refactor auth.py by extracting internal helpers. Do not change external behavior of /register, /login, /profile. Keep werkzeug.security.generate_password_hash and check_password_hash exactly as currently used. Do not modify session['user_id'] or g.user patterns. New code is internal helpers only.

With a clean context and explicit guardrails, the second attempt usually holds.

Why it stays underrated

Old habits. When we write code, we iterate by adding. Our tools don’t have a “global undo the last N project operations” button. That’s what Git is for.

An agent’s context isn’t a log. It’s the model’s current understanding of the problem and the direction it’s going. When that understanding is wrong, pouring more prompts in is like fixing a broken algorithm by adding if statements on top.

The other reason is inconsistency across tools. If /rewind only clears chat but leaves broken code on disk, the feature feels half-done, and people stop reaching for it. A rewind that touches both the conversation and the working tree is the version that earns a place in your muscle memory.

What changes in your workflow

A few things get better once /rewind is a habit:

• Faster iteration. Instead of a long back-and-forth trying to talk the agent out of a bad idea, one rewind plus a sharper prompt resets you in seconds.
• Lower cost. Fewer wasted tokens per task.
• Better output. The agent always runs on a clean context, not one polluted by its own mistakes.
• Less frustration. You stop feeling like you’re arguing with something that won’t listen.
• Earlier recovery. You learn to spot drift in the first turn or two, before it cascades.

Closing thought

The coding agent is a useful tool, and like any tool it rewards knowing where the controls are. /rewind is one of the important ones. Treat it as your git reset --hard for conversation context. Stop correcting bad logic by adding more logic on top. Throw out the bad turns, write the prompt you should have written the first time, and move on.