How to fork a Claude Code, Codex, or OpenCode session without losing context

Forking is the thing I reach for when I’m not sure.

Not “not sure how to code” — more like:

I’m not sure I want to keep this approach.
I’m not sure the agent’s current plan is safe.
I want to try a different direction without wrecking the session that’s already working.

I want to try a different approach without burning the working thread — and I don’t want to lose the context that makes the session useful.

Most of the time I end up doing some clumsy version of this (copying context into a new session, writing a summary, or just continuing in-place and hoping it doesn’t get messy).

Happier is one of the options I use because it gives you a single “fork” gesture, and then picks the best supported strategy (provider-native when possible, replay when not).

TL;DR

Decide where you want to branch:
- fork from a specific message to branch earlier, or
- fork from the session menu to branch from the latest tip
Set up Happier on the machine that owns your session/workspace and connect your phone.
Fork the session.
If your provider can’t fork natively in that spot, Happier will fall back to replay (a hidden replay seed) so the child session still has context.

The problem

Long-running coding sessions accumulate a lot of momentum.

That’s good… until you realize you want to do something risky:

rewrite a chunk of code
change an API surface
try a different refactor shape

If you do that in-place, it’s hard to get back to the “known good” thread.

Forking solves the human problem: “I want to try this, but I don’t want to lose what already works.”

What I tried first (and where I bounced off)

Copy/paste the last prompt into a new session: works, but you lose subtle context.
Write a long ‘here’s the current state’ summary: works, but it’s time-consuming.
Just keep going in the same session and hope: fastest, but you pay for it later.
Happier session forking: gives you a real branch with ancestor context and a fallback path when native provider fork isn’t available.

If you’re new to Happier (what it is, and where to get it)

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) for AI coding agents like Claude Code, Codex, and OpenCode.

The workflow here is: keep the actual session/runtime on the owning machine, and use Happier from your phone to branch safely and keep context.

Get set up:

How to run Happier from your phone
GitHub: https://github.com/happier-dev/happier
Install/download: https://github.com/happier-dev/happier#how-it-works
Discord (community + support): https://discord.gg/W6Pb8KuHfg

A workflow that works (step-by-step)

1) Decide what kind of fork you want

Happier supports two “fork intentions”:

Fork from a specific message (branch earlier)
Fork the latest conversation (branch from the session tip)

If you know exactly where things went sideways, fork from the message.

If you just want a parallel thread from “right now”, fork from the session menu.

2) Fork from a message (branch earlier)

In the transcript, hover/tap a committed message and choose Fork.

A detail I like here: if you fork on a user message, Happier pre-fills that message into the child composer so you can edit it and resend a cleaner version.

3) Fork from the session tip (branch from the latest)

Use the session action (header menu / command palette) to fork from the latest committed conversation state.

This is the “I want a new branch starting now” move.

4) Know what Happier will do under the hood (native fork vs replay)

The docs describe a clear selection order:

Provider-native fork-at-message (OpenCode server) when you fork a specific message.
Provider-native fork-at-latest (Codex app-server, plus ACP backends that expose session/fork) when you fork from the session tip.
Happier replay fork when native fork isn’t available.

So the practical takeaway is: you can use one “fork” gesture in the UI, and Happier picks the best supported mechanism.

5) Understand replay (the thing that keeps context without polluting the transcript)

Replay is the safety net.

When replay is used, Happier:

builds a replay seed from the transcript up to your fork point
applies it once to the first user message you send in the child session
keeps the seed hidden (it’s sent only to the model and never shown in the transcript)

That “hidden seed” detail matters. It keeps the child transcript clean while still giving the model enough context to behave like it’s continuing the same work.

6) What you’ll see in the forked session

In the child session:

ancestor messages render inline as read-only context
scrolling up loads older parent segments automatically
the child’s own messages remain normal and interactive

So you can keep your bearings without duplicating the entire transcript.

Provider notes worth knowing

Codex behavior (fork and rollback)

Codex app-server supports:

native fork-from-latest via the session-level fork action
rollback-to-point behavior (rollback before a committed user message)

But it does not support native fork-from-message. In that case, replay is the fallback.

OpenCode behavior

OpenCode server-native supports fork-at-message (the nicest version of this).

There’s also an ACP fallback path for OpenCode where native fork may be “best effort”; when it’s not available, replay is used.

Why this works (and what breaks)

Forking works when:

you want to try a different approach without destroying the main thread
you want the child to inherit context without you writing a big summary

The main thing that “breaks” is when replay is disabled (or seed budgets are too low) and your provider can’t fork natively in the way you’re attempting.

In that case, the fork UI will either be unavailable (for some fork types) or the child will start with less context.

Common mistakes

Using fork when you just wanted to resume → forking is for branching; resuming is for continuing.
Forking too late → if you know the exact message where the plan diverged, fork there.
Forgetting forked ancestor messages are read-only → you can copy them, but actions/approvals won’t run from ancestor segments.