Master Claude Code Sessions, Checkpoints, Rewind, Forking, and Context

Quick answer

A Claude Code session is a saved conversation tied to a working directory. Resume when you want to append to the same history; fork when you want the same background but an independent direction. Use checkpoints to rewind local file edits, Git for durable project history, /context to inspect context pressure, and /compact or a new session when old detail is crowding out the current goal. Anthropic's how Claude Code works explains the current session and context model.

Resume and fork solve different problems

claude --continue reopens the most recent applicable conversation. claude --resume lets you select one. Resuming retains the session identity and appends new events. Forking with the supported session-fork controls copies prior history into a new identity, preserving the original branch of thought.

Use resume for “continue yesterday’s implementation.” Use fork for “compare two architectural approaches from the same investigation” or “keep the accepted plan untouched while testing an alternative.” Do not open the same session in two terminals and expect coordinated concurrent editing; use separate sessions and worktrees.

Know what context contains

The active context can include the conversation, files read, command output, project instructions, auto memory, skill content, tool definitions, and system guidance. It is a working set, not infinite storage. Claude Code removes older tool output and summarizes history as it approaches capacity.

Run /context before blaming the model for drift. Typical pressure sources are enormous logs, generated files, broad MCP inventories, repeatedly pasted source, and long debugging trails. Prefer filtered commands:

# Better than returning an entire log
grep -n "ERROR\|WARN" app.log | tail -80

# Better than reading a generated tree
git diff --name-only main...HEAD

Put rules that must survive compaction in CLAUDE.md, not in an early conversational paragraph. Use /compact with a focus such as “preserve the root cause, accepted design, changed files, and remaining verification.” Start fresh if the summary itself contains more obsolete than useful information.

Use checkpoints correctly

Claude snapshots files before edits. Rewind can restore those local file states and optionally conversation state. Checkpoints do not reverse:

• database mutations;
• Git pushes or hosted pull requests;
• messages and tickets;
• package publication;
• cloud resource changes;
• commands that changed external state.

Before any non-reversible action, pause for explicit review. A safe instruction is: “Prepare the deployment and show the exact command, but do not run it.”

Recovery playbooks

Wrong implementation direction: interrupt immediately, rewind to the last good checkpoint, state the violated constraint, and resume from evidence.

Context drift: ask for a compact handoff containing goal, facts, decisions, files, test state, and next action; then start a fresh session with that handoff.

Dirty working tree: do not reset blindly. Compare git status, checkpoint state, and user-owned changes. Restore only files clearly created by the failed attempt.

Two promising solutions: fork before implementation, place each branch in a separate Git worktree, and compare against the same test and benchmark.

Lab: controlled failure and recovery

Create a disposable repo. Ask Claude to make a small passing change, then deliberately request an incorrect second edit. Rewind only the second edit, verify the first remains, fork the session, and implement a second solution in another worktree. Finish by documenting which state belongs to Claude, Git, and the filesystem.

FAQ

Does clearing a conversation delete project memory?

Conversation state, persistent instructions, and auto memory are different layers. Review the current command behavior before deleting stored data.

Can checkpoints recover an overwritten secret?

They may restore file content, but exposure may already have occurred. Revoke and rotate the secret; do not treat restore as incident resolution.

Is compaction a failure?

No. It is normal context management. The risk is relying on old conversational detail instead of durable instructions and explicit artifacts.