文脈を失わずにClaude Code、Codex、OpenCodeのセッションを分岐（フォーク）する方法
メッセージから、またはセッションの最新地点から分岐し、元の文脈を引き継ぐ方法。プロバイダーがネイティブに分岐できないときはリプレイを使います。
- CLI
- 0.2.17
- プレビュー ref
- a2c45c8
分岐（フォーク）は、迷っているときに役立ちます。
「コードの書き方が分からない」という意味ではなく、こういうことです。
- このアプローチを続けたいか確信がない。
- エージェントの今の計画が安全か確信がない。
- すでにうまくいっているセッションを壊さずに、別の方向を試したい。
目的は、うまくいっている流れを犠牲にせず、セッションを役立つものにしている文脈も失わずに、別のアプローチを試すことです。
分岐がないと、たいてい同じことを不格好にやることになります。新しいセッションに文脈をコピーする、要約を書く、あるいはその場で続けて散らからないよう祈る、といった具合です。
Happierは、コーディングエージェントをクロスデバイスで実行・オーケストレーションするオープンソースアプリで、「分岐」の操作を1つにまとめ、対応する方式を選びます（可能ならプロバイダーのネイティブ機能、無理ならリプレイ）。
要点
- どこから分岐するか決めます。
- 特定のメッセージから分岐して、より前の地点から枝分かれする
- セッションメニューから分岐して、最新の地点から枝分かれする
- セッションとワークスペースを持つマシンにHappierをセットアップし、スマートフォンを接続します。
- セッションを分岐します。
- その地点でプロバイダーがネイティブに分岐できない場合、Happierはリプレイ（非表示のリプレイシード）に切り替え、子セッションにも文脈が引き継がれるようにします。
問題
長く続くコーディングセッションには、大きな勢いがたまっていきます。
それは良いことです。リスクのあることをしたくなるまでは。
- コードの一部を書き直す
- APIの表面を変える
- 別の形のリファクタリングを試す
それをその場でやると、「うまくいっていた」流れに戻るのが難しくなります。
分岐は人間側の問題を解決します。「これを試したいけれど、すでにうまくいっているものは失いたくない」という問題です。
よくあるやり方とトレードオフ
- 最後のプロンプトを新しいセッションにコピー＆ペーストする： 使えますが、細かな文脈が失われます。
- 「現状はこうです」という長い要約を書く： 使えますが、時間がかかります。
- 同じセッションでそのまま続けて祈る： 速いですが、後でつけを払います。
- Happierのセッション分岐： 元の文脈を持った本物の分岐ができ、プロバイダーのネイティブな分岐が使えないときの代替手段もあります。
Happierが初めての方へ（概要と入手方法）
Happierは、Claude Code、Codex、OpenCodeなどのAIコーディングエージェントのためのオープンソースのコンパニオンアプリ（モバイル、Web、デスクトップ）です。
ここでの流れは、実際のセッションと実行環境はそれを持つマシンに置いたまま、スマートフォンからHappierで安全に分岐し、文脈を保つというものです。
セットアップ：
- スマートフォンからHappierを使う方法
- GitHub: https://github.com/happier-dev/happier
- インストールとダウンロード: https://github.com/happier-dev/happier#how-it-works
- Discord（コミュニティとサポート）: https://discord.gg/W6Pb8KuHfg
うまくいくワークフロー（手順）
1) どんな分岐にしたいか決める
Happierは2種類の「分岐の意図」に対応しています。
- 特定のメッセージから分岐（より前の地点から）
- 最新の会話を分岐（セッションの最新地点から）
どこで話がそれたか正確に分かっているなら、そのメッセージから分岐します。
「今この時点から」並行する流れが欲しいだけなら、セッションメニューから分岐します。
2) メッセージから分岐する（より前の地点から）
トランスクリプトで確定済みのメッセージにカーソルを合わせるかタップし、Fork を選びます。
便利な点：ユーザーのメッセージで分岐すると、Happierがそのメッセージを子セッションの入力欄にあらかじめ入れてくれるので、編集してより整理された内容で送り直せます。
3) セッションの最新地点から分岐する
セッションの操作（ヘッダーのメニューやコマンドパレット）の セッションを分岐（Fork session）で、確定済みの最新の会話状態から分岐します。
「ここから新しい枝を始めたい」ときの操作です。
4) Happierが内部で何をするか知っておく（ネイティブ分岐かリプレイか）
ドキュメントには明確な選択順序が書かれています。
- 特定のメッセージから分岐するときは、プロバイダーのネイティブなメッセージ地点での分岐（OpenCodeサーバー）。
- セッションの最新地点から分岐するときは、プロバイダーのネイティブな最新地点での分岐（Codexのapp-serverと、
session/forkを公開しているACPバックエンド）。 - ネイティブな分岐が使えないときは、Happierのリプレイ分岐。
実際のポイントは、UIでは1つの「分岐」操作を使うだけで、Happierが対応している方式を選んでくれることです。
5) リプレイを理解する（トランスクリプトを汚さずに文脈を保つ仕組み）
リプレイは安全網です。
リプレイが使われると、Happierは：
- 分岐地点までのトランスクリプトからリプレイシードを作り
- 子セッションで最初に送るユーザーメッセージに一度だけ適用し
- シードを非表示に保ちます（モデルにだけ送られ、トランスクリプトには表示されません）
この「非表示のシード」が大事です。子セッションのトランスクリプトをすっきり保ちながら、モデルには同じ作業を続けているかのように振る舞えるだけの文脈を与えます。
6) 分岐したセッションで見えるもの
子セッションでは：
- 元のメッセージが読み取り専用の文脈としてインラインに表示されます
- 上にスクロールすると、親のより古い部分が自動で読み込まれます
- 子セッション自身のメッセージは通常どおり操作できます
トランスクリプト全体を複製しなくても、流れを見失わずにすみます。
知っておきたいプロバイダーごとの注意点
Codexの動作（分岐とロールバック）
Codexのapp-serverが対応しているのは：
- セッション単位の分岐操作による、ネイティブな最新地点からの分岐
- 特定の地点へのロールバック（確定済みのユーザーメッセージより前に戻す）
ただし、ネイティブなメッセージ地点からの分岐には対応していません。その場合はリプレイが代替手段になります。
OpenCodeの動作
OpenCodeのサーバーはネイティブにメッセージ地点での分岐に対応しています（この機能がきれいに動く形です）。
OpenCodeにはACP経由の代替経路もあり、そこではネイティブな分岐は「ベストエフォート」になることがあります。使えない場合はリプレイが使われます。
なぜうまくいくのか（そして何が壊れるのか）
分岐がうまくいくのは：
- 本筋を壊さずに別のアプローチを試したいとき
- 大きな要約を書かずに、子セッションに文脈を引き継ぎたいとき
主に「壊れる」のは、リプレイが無効（またはシードの予算が小さすぎる）で、しかもプロバイダーが試みている形でネイティブに分岐できない場合です。
その場合、分岐のUIが（分岐の種類によっては）使えなくなるか、子セッションが少ない文脈で始まります。
よくある間違い
- 再開したいだけなのに分岐を使う → 分岐は枝分かれのため、再開は続けるためのものです。
- 分岐が遅すぎる → 計画がそれたメッセージが正確に分かっているなら、そこで分岐します。
- 分岐元のメッセージが読み取り専用だと忘れる → コピーはできますが、元の部分から操作や承認は実行されません。