[EN] Create a Checkpoint Once the Plan is Ready: Session Forking in Claude Code

Table of contents

The Agentic Loop: Why Context is Expensive

Unlike a standard chatbot, Claude Code operates in an Agentic Loop. When you assign it a task, it doesn’t just “guess”; instead, it:

1. Gathers Context: Indexes files, analyzes content, maps dependencies, etc.
2. Acts: Writes code or executes commands in the terminal.
3. Verifies: Runs your test suite to validate the solution, uses skills, consults your documentation…

This loop builds context for that conversation. Rebuilding that state from scratch every time you want to try a different approach or solution is a horrible waste of tokens and, above all, time.

The Moment of the Fork: From Audit to Action

After an intense research phase, the last thing you want is to lose the accumulated progress. You’ve analyzed a problem, corrected the AI, asked it to clarify some issues… This is where we differentiate two ways of working with context:

• —resume: The equivalent of continuing to write in the same thread. Useful for linear tasks where the goal is unique and clear.
• /fork: The equivalent of creating a branch from a specific “commit” of your audit.
• If you don’t use /rename, you can use claude —list to see your sessions and then claude —fork-session s4df92k1 to fork that specific session.

Imagine you’ve spent 20 minutes with Claude tracing a complex concurrency error. The IA has already mapped the locks, read the logs, and perfectly understands the race condition. At this point, you have what we call a “Clean Audit”. I advise you to run a /rename and give that session a descriptive name, like audit_result.

Instead of starting to apply patches that could “dirty” that understanding or confuse the model with failed attempts, you do a fork. If the first solution strategy (for example, adding a semaphore) complicates the code too much or introduces side effects, you simply discard that session. Your “Clean Audit” is still there, intact and with all context loaded, ready for you to try a second approach from the exact point where you finished the investigation, without having to re-explain anything to the AI.

🏗️ Real Case: The “Decision Fork” as a Tech Lead

The Situation

You have to migrate a feature from a Node.js microservice to Kotlin.

Base Session

1. Ask it to analyze the legacy microservice code.
2. Let it know the business rules and guidelines it must follow.
3. Provide the knowledge it needs about the target microservice (libraries, guidelines, architecture).
4. Ask it to ask you anything it’s not clear about, and answer.

With all this, the context is ready to start the next steps. Normally, I would export all the above to a Markdown file to avoid losing it. Now, at this point, I do a /rename, give it a clear name, fork the session, and there I begin the next phase.

The Forking Strategy

As a Lead, at this point you may have several needs:

• Creating documentation: You start creating documentation and fixing it. If you later want to make a plan, the context generated by the documentation is irrelevant; go back to the original session, create another fork.
• Creating a plan: You’ve created it and it doesn’t convince you, or you missed something to analyze, or the plan is fundamentally wrong. You discard that session, go back to the original, clarify or add what’s necessary, and make another fork.
• Starting the migration: You start migrating, and the chosen model isn’t doing it well enough, or you’ve started by migrating one endpoint to test and after seeing the result you prefer to do it again but with TDD. The same: back to the original session, another fork, and refine your prompt to migrate.

The Result

You have avoided dirtying the context you had polished, and you can also use it to launch several tasks in parallel starting from the same clean context.

Safety Infrastructure: CLAUDE.md and Checkpoints

For this workflow to be production-grade, Claude Code uses two safeguards:

1. CLAUDE.md: Think of this as your repository’s “System Prompt”. It stores linting rules, test commands, and architectural patterns. No matter how many forks you create, the AI stays aligned with your team’s standards.
2. Checkpoints: Claude takes snapshots of your files automatically before editing them. If a fork goes wrong, a simple undo instantly reverts the file system; having more failed forks doesn’t mean leaving garbage in the project.

Conclusion

We are moving from “prompting” to Context Engineering. For a Tech Lead, the ability to branch reasoning means prototyping complex changes or parallelizing tasks with the same clean context in minutes instead of hours, keeping the main session clean and focused. This has saved me from a couple of headaches and dozens of .md files piling up.