Model: openai/gpt-5.4 Generated: 2026-04-01 Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead Chapter: 5 — Session and Context Management Token Usage: Approx. 1,500 output tokens for this section
5.4 Session Recovery and Continuation
Persistence keeps the past. Recovery and continuation decide whether that past can become a usable future. This distinction is crucial. A coding agent may have perfectly stored transcripts and still fail catastrophically after interruption if it cannot reconstruct state, resume intent, and continue from the correct branch of work. Long-running agent systems live or die by how well they solve this continuation problem.
The continuation problem
The continuation problem can be stated simply: after a crash, compaction, model error, machine switch, or context reset, how does an agent continue the same job without losing momentum or repeating work?
This is harder than ordinary persistence because the system must restore more than conversation text. It may need to recover:
- active task intent,
- working directory or worktree,
- todo state,
- background subagent lineage,
- plan progress,
- file diffs or snapshots,
- tool-use invariants,
- the last safe restart point.
In other words, continuation requires reconstructing an execution state, not just a transcript.
OpenCode: archive, load, fork, and revert
OpenCode’s recovery model begins with its structured session store. Because sessions are modeled explicitly, OpenCode can archive them, list them, load them, and fork them. In session/index.ts, a session includes time.archived, and queries can include or exclude archived sessions. That gives the platform lifecycle control over dormant conversations.
More interesting is session/revert.ts. This file implements revert logic that can roll the session back to a target message or part, restore file snapshots, compute diffs over the reverted range, and then clean up later messages or parts. This is not merely “undo the last reply.” It is session-level time travel backed by snapshots and patch tracking.
This makes OpenCode resilient in a very particular way. It can recover not only from interruption but also from bad turns. If an agent takes the wrong path, the runtime can rewind the session’s semantic and file-system state together. That is a powerful continuation primitive because resuming the wrong state is sometimes worse than not resuming at all.
OpenCode also supports branching behavior through session forking. A forked session can preserve history up to a point and then continue independently. That is another answer to the continuation problem: sometimes the safest resume is not overwrite-in-place but branch-and-continue.
Claude Code: /resume, worktrees, and teleportation
Claude Code’s continuation features are centered around transcript replay and environment restoration. The CLI logic in src/cli/print.ts shows explicit handling for --continue, --resume, and --teleport. The code restores messages, reuses or switches the session ID, reloads session metadata, and restores worktree state when applicable.
The worktree support is especially important. types/logs.ts defines PersistedWorktreeSession, storing fields such as originalCwd, worktreePath, worktreeName, branch information, and the session ID. That means a resumed conversation can return not only to the right transcript but also to the right isolated Git working environment. For coding agents, this is a major practical feature because environment drift is one of the most common causes of broken continuity.
Claude Code also supports “teleport” workflows, visible in both CLI handling and bootstrap state. Teleportation is essentially continuation across machines or execution contexts. Instead of treating a session as tied to one local process, Claude Code can hydrate or resume it elsewhere. This is a strong example of log-based persistence paying off: append-only transcript artifacts are relatively portable.
In addition, Claude Code stores subagent metadata, content replacement records, task summaries, and worktree state sidecars. This means resume is not merely loading old chat text; it is a reconstruction pipeline.
OMO: recovery hooks and multi-agent continuity
OMO raises the bar because it must recover not only a main thread but also an orchestration graph.
Session-recovery hook
The session-recovery hook in hooks/session-recovery/hook.ts detects recoverable assistant errors such as missing tool results, thinking block order problems, and thinking-disabled violations. It can abort the session, inspect recent messages, repair structural issues, notify the UI, and optionally auto-resume from the last user message. This is a more surgical form of recovery than ordinary resume. It repairs the transcript so continuation becomes possible again.
Boulder-state tracking
OMO’s boulder state persists active plan identity, start time, associated session IDs, and plan name. This is critical for Sisyphus-style long autonomous runs. If the process dies, the system does not only know “which conversation existed”; it knows “which plan was active, which sessions participated, and where the run was in the broader workflow.”
session_id continuation for subagents
OMO also treats background agent continuity as a first-class concern. The compaction context injector explicitly tells the summarizer to preserve delegated agent session_id values and to resume existing agent sessions rather than spawning fresh ones. This is a major design insight. In multi-agent systems, naively restarting a subagent after compaction wastes tokens, loses learned context, and can duplicate research or edits.
The small claude-code-session-state module tracks main versus subagent sessions and session-to-agent mapping, while run-continuation markers in features/run-continuation-state/storage.ts persist whether continuation is active and why. These mechanisms externalize orchestration state so it survives beyond one model call.
Recovery philosophies compared
OpenCode’s recovery is strongest in stateful rollback and branching. Claude Code’s recovery is strongest in portable replay and environment restoration. OMO’s recovery is strongest in workflow continuity across orchestration layers.
That difference mirrors the core identities of the systems.
- OpenCode thinks in terms of sessions as structured objects that can be reverted and forked.
- Claude Code thinks in terms of sessions as replayable transcripts that can be resumed, moved, and rehydrated.
- OMO thinks in terms of sessions as nodes in a larger multi-agent process that must survive interruption without losing delegated work.
Why continuation is harder after compaction
Compaction sharpens the continuation problem because it deliberately destroys detail. After a compact, the agent is no longer resuming from full history but from a compressed representation of history. That means the quality of the summary, the preservation of todo state, and the retention of agent lineage all become decisive.
This is why OMO’s preservation hooks matter, why Claude Code persists extra metadata like worktree state and content replacements, and why OpenCode’s revert and snapshot mechanisms remain valuable. A continuation architecture must assume that not all future resumes happen from pristine full transcripts.
Design lesson
The best continuation design for future coding agents should combine four capabilities:
- durable transcript replay for basic resume,
- environment restoration for cwd, branch, and worktree continuity,
- stateful rollback and branching for recovering from bad turns,
- workflow lineage preservation for subagents, plans, and todos.
In short, session recovery should be treated as distributed systems engineering, not as a UX convenience feature. The stronger the agent’s autonomy, the more important continuation becomes. A truly capable coding agent is not the one that can merely start well. It is the one that can stop, recover, and keep going.