05.14Context and memory
Moving AI agent sessions between Claude Code, Codex, Pi and machines
How to carry an AI agent session across harnesses and machines. Open-source converters cover much of it, but none moves every native record losslessly.
On this page
- What must persist
- Seven persistence patterns
- The open-source shortlist
- Native history conversion
- Moving between machines
- Repeated switching and the OpenRig question
- The broader persistent-agent architecture has direct prior art
- Principles to borrow without building a distributed platform
- What to do with these findings
How can an ongoing AI agent session be carried across coding-agent harnesses (Claude Code, Codex, Pi) and between machines without losing its history? AR Labs researched that question in November 2026, because we hand the same work between Claude Code and Codex and keep session history as part of our agents' memory. A harness here means everything around the model that shapes what an agent does: the agent program, its instructions, skills, hooks, tools and checks. The report reviews nine open-source session-transfer projects, a September 2026 paper on runtime-independent persistent agents, and foundational distributed-systems sources, working from project documentation and pinned source code.
The problem is an ongoing job that has to survive repeated Claude Code–Codex handovers, with Pi and laptop–VPS movement as future extensions. Several open-source projects now implement substantial parts of this. Inspect and reuse their conversion and transfer machinery before building equivalents. None of the evidence reviewed establishes unlimited, lossless interchange of every native record, attachment, child session and runtime capability.
The immediate recommendation is to compare agent-handoff for a focused Claude/Codex transfer with session-migrate and txcript as reusable conversion libraries. Happier is the strongest integrated candidate in this review for both machine handoff and harness switching, with different fidelity guarantees for those operations. This is a research recommendation, not an adoption decision.
What must persist
Persistence means the record survives stopping. Portability means another harness or machine can use it. A stable conversation title or dashboard ID proves neither that all native state moved nor that the next model received the whole history.
Four things need distinguishing:
| State | Example | Requirement |
|---|---|---|
| Conversation record | Messages, decisions, tool results, referenced artefacts | Preserve originals and the additions made in each harness. |
| Current working context | Latest instruction, accepted decision, unfinished work | Give the receiving agent a compact, evidence-linked orientation. |
| Workspace | Repository revision, uncommitted changes, local files | Keep it available independently of chat conversion. |
| Agent operating environment | Identity, navigation rules, skills, hooks and tools | Load it through the destination harness's own configuration. History import does not install it. |
These are proposed distinctions for reasoning about the problem, not a new storage schema. They reflect the separate conversation, workspace and runtime boundaries exposed by the implementations below.
Seven persistence patterns
The research identified seven conceptual patterns, each distinguishing where the record lives, what the user can scroll through and what the model receives. They can be combined; the first is an ideal standard, and compaction is an additional layer rather than a competing persistence architecture.
| Pattern | What it explains |
|---|---|
| 1. Shared native standard | Every harness reads and appends the same agreed conversation format. |
| 2. Shared record with adapters | Per-harness adapters connect native sessions to an independent authoritative record. |
| 3. Native session conversion | Create destination history, retain originals and supply current context. |
| 4. Shared conversation UI | A persistent human-facing timeline can coexist with a bounded context handoff to a new executor. |
| 5. Native machine migration | Move saved session state to another host while retaining the same harness. |
| 6. Remote runner access | Change the access device while execution stays on the original host. |
| 7. Compaction and history | Reduce model input through a checkpoint while keeping originals and scrollback. |
The open-source shortlist
"Native conversion" means writing a new conversation in the destination's format. It does not mean preserving every source field or moving a live process. Platform and version qualifications matter as much as feature names.
| Project and licence | Relevant functionality | Consequential boundary |
|---|---|---|
| agent-handoff, Apache-2.0 | Claude/Codex native imports; portable bundles with source material and a neutral transcript | Cross-harness representation is deliberately lossy; workspace transfer and complete child-session/media restoration are outside its guarantee. |
| session-migrate, MIT | Python conversion pipeline including Claude, Codex and Pi; explicit transformation/omission manifests | New independent sessions, not synchronised ownership. Exact tested client versions and unsupported Codex lineage limit compatibility. |
| txcript, Apache-2.0 | Rust library and CLI; common transcript model with Claude/Codex/Pi readers and writers | Native-to-common conversion drops some native information. Raw source retention remains a separate concern. |
| Happier, MIT | Persistent hosted session, cross-agent continuation, native session handoff between machines | Cross-agent continuation carries bounded recent text. Codex machine handoff is experimental. |
| Session Bridge, MIT | Linked Claude/Codex sessions with revision tracking and repeated switching | Native writing/synchronisation is Windows-scoped; files and running processes are separate. |
| Reinstate, Apache-2.0 | Encrypted session storage/restore and structured cross-agent handoff | Cross-agent handoff is a fresh conversation. Current release qualification is Windows-only; Linux/WSL2 remains unverified. |
| Harness Remote, Apache-2.0 | Multi-harness remote control and linked continuation on another machine | Continuation supplies bounded text; it is not a full native-state clone. |
| OpenRig, Apache-2.0 | Durable seat/queue context and runtime switching, including Claude/Codex | Runtime switch explicitly creates a new conversation from a handover; native history is not converted. |
| Enoch, Apache-2.0 | Persistent agent identity/memory/code and explicit host migration | Agent continuity architecture; native Claude/Codex session mappings are excluded from its host export. |
Native history conversion
agent-handoff for the immediate Claude and Codex case
Its bundle combines native source data, a neutral conversation and restoration notes. Entry checksums support integrity checks. The cross-agent path synthesises a destination session; the same-agent path rewrites native data for a new identity and working directory. Portable bundles can be moved using an existing file-transfer mechanism, without adopting a hosted relay. Bundle format.
The implementation makes the fidelity boundary concrete. Its neutral representation contains visible messages and tool evidence, while dropping reasoning traces and native event structure. Its Codex writer generates user/assistant response items and tool records, so this is more than a pasted summary. Those generated records remain a projection of the source. Neutral model, Codex writer.
Implication: a good first candidate for the narrow transfer operation. Preserve each source bundle independently; re-exporting the latest translated conversation cannot recover information an earlier translation omitted. The repository reports compatibility with selected clients, not universal future compatibility. Project compatibility statement.
session-migrate for explicit fidelity accounting
This project's architecture closely matches the engineering question: bounded native readers feed an ordered event model; target writers produce new sessions and report transformations or omissions. Events carry source provenance. Generated artefacts are validated before publication, and installation avoids overwriting existing sessions. Its scope includes Claude, Codex and Pi. Architecture, Event model.
Its compatibility table is particularly useful reading: text can survive while tool-error status, message grouping or source-only records do not. System/developer context is explicitly omitted and counted rather than silently converted into user instructions. The validated Claude/Codex versions are 2.1.209 and 0.144.4; those numbers are evidence boundaries, not recommendations for today's installed clients. Compatibility matrix.
There is a material Codex limit: the inspected reader rejects external history_base lineage. Even same-format migration passes through its portable representation and creates a new identity. It should not be mistaken for a byte-preserving backup or an automatic synchronisation service. Codex reader, Conversion implementation.
Implication: a strong library candidate and a useful example of making loss visible. It still needs an independent original-record archive around it.
txcript for a reusable conversion library
Txcript offers native readers/writers through a common transcript representation, including Pi. Its format documentation distinguishes native roundtripping from conversion through that common model. For Claude, unknown native records can survive the native representation but are dropped in the common conversion; discovery also excludes subagent/tool-result directories. Claude format mapping.
Codex's UI events and model-history records are distinct representations. Mapping them requires avoiding duplicate messages and preserving tool-call/result relationships. This is precisely the adapter work worth reusing instead of writing from scratch. Codex format mapping.
Implication: compare its API and currently supported format subset with session-migrate. Neither library's existence removes the need to retain unsupported source records elsewhere. Their latest release and default branch differ; choose an exact revision when evaluating them.
Moving between machines
Happier combines both operations but gives them different guarantees
Happier's machine handoff retains its session identity and changes the active machine. For supported providers it transfers native session state; workspace copying is a separate option, and destination provider login is still required. Claude and OpenCode are documented as supported; Codex is experimental. Development-only options in the documentation must not be assumed present in older releases. Machine handoff.
Its cross-agent continuation retains the hosted session's visible history and ID, but supplies the new agent with a bounded recent text summary. Images and files do not carry through that context handoff, and direct sessions outside Happier's hosted transcript are ineligible. This is a useful user experience with a narrower information-transfer contract than native conversion. Continue with another agent.
The machine-transfer code is substantial prior art. The coordinator separates preparation, target resumption, confirmation, binding, commit and cleanup, with abort paths. The Codex exporter resolves paginated history ancestors; the importer verifies ancestor prefixes before accepting destination state. These are concrete mechanisms for avoiding incomplete or conflicting copies. Coordinator, Codex export, Codex import.
Implication: assess Happier if an integrated session-control application is desirable. Its cross-agent summary does not, by itself, satisfy a requirement to preserve original detail.
Smaller transfer and continuation tools
Entangle transfers individual Claude, Codex or OpenCode sessions between machines using encrypted sharing. Its README explicitly says a session remains in the same harness; opening Claude history in Codex is outside its current scope. Bulk machine-history export is Claude-only. This is a useful MIT-licensed transport candidate, assessed here from documentation rather than implementation. Entangle.
Reinstate separates encrypted same-agent persistence from structured cross-agent handoff. The latter can derive a checkpoint from local evidence after the source is closed or quota-limited; it does not need another source-model response. Its handoff records fidelity categories and can leave longer evidence in a sidecar. Current v0.6.0 qualification is native Windows x64, with macOS acceptance deferred and Linux/WSL2 optional/unverified. Handoff implementation guide, Platform statement.
Harness Remote creates linked destination conversations. Its inspected context builder keeps at most 16 text entries, clips each to 1,500 characters, then caps the combined context at 12,000 characters. Its cross-machine path rejects image attachments. That is useful bounded continuation, not complete history migration. Context builder, Cross-machine continuation.
Repeated switching and the OpenRig question
Session Bridge is especially relevant to repeated back-and-forth. Its documented synchronisation model links native sessions through immutable revisions, watches completed turns, creates a fresh target when necessary, and retains previous sessions. If both sides advance, it exposes competing heads rather than pretending they can be merged automatically. A transfer journal supports recovery after interrupted writes. These ideas are useful even though its native synchronisation is Windows-scoped. Synchronization design.
OpenRig does implement part of the requirement. Its Claude/Codex runtime switch prepares a successor, supplies a restoration packet, waits for confirmation and commits seat/queue custody before retiring the predecessor. The inspected service explicitly states that native history is not converted: the target starts a new conversation. This makes OpenRig useful prior art for continuity of role and work ownership, while leaving the original-detail requirement to another mechanism. Runtime-switch implementation.
OpenRig's registered remote hosts provide remote command and access facilities. That is not evidence that this runtime-switch operation automatically migrates all native session state between hosts. Hosts and humans.
The broader persistent-agent architecture has direct prior art
The September 2026 paper Runtime-Independent Persistent Agents: Preserving Identity, Memory, and Code Across Models, Harnesses, and Servers is close to the broader model of an agent that persists independently of any one harness. It separates persistent identity, memory and executable code from replaceable models, harnesses, hosts and interaction surfaces. Its Enoch reference implementation is Apache-2.0. The authors report bounded migration studies, including five Codex–Muse–Codex roundtrips and host continuation; they explicitly do not establish arbitrary-task portability or behavioural equivalence. Paper.
Enoch's host-migration design quiesces the source, exports selected persistent state, verifies the destination's code revision and bundle, then changes continuation authority. It excludes native Codex/Claude session mappings. Its local source fence helps prevent accidental dual continuation, but is not global enforcement against an independently acting copy. Host migration.
Implication: this supports treating an agent's installed identity and operating layer separately from a particular chat and from its knowledge estate. Enoch is an architectural reference, not a substitute for importing recognisable Claude/Codex conversation history.
Principles to borrow without building a distributed platform
These are design inferences from the inspected projects and the foundational sources, rather than additional implementation requirements.
- Keep originals separate from views. Native destination history and a compact orientation are derived views. Retain immutable source records so a conversion omission does not become permanent loss. LangGraph's checkpoint/store separation is a useful introduction to state with different scopes. Persistence.
- Track lineage across switches. Give the ongoing job an identity independent of native session IDs. Each completed leg contributes new evidence. Preserve branches when both sides advance; do not silently choose or merge decisions. Session Bridge supplies concrete examples above.
- Treat transfer as a resumable operation. A failed response does not prove that a target was never created. Retain transfer identity and stage so a retry can reconcile the existing result. AWS on idempotent APIs.
- Separate history from permission to act. Recorded tool results are evidence, not instructions to execute tools again. A historical approval is not an imported destination credential or policy. Temporal's replay model helps explain reuse of results without equating a fresh LLM generation with deterministic replay. Temporal replay.
- Add distributed ownership only when needed. A supervised local handover can explicitly stop one runner and start another. Automatic multi-host ownership introduces stale writers and partial failures; timeouts alone do not safely revoke a paused process. Kleppmann on fencing.
For Designing Data-Intensive Applications, the relevant themes are encoding/schema evolution, logs and derived state, partial failures, replication and ownership. The earlier reading pass checked the second edition's contents: begin with Chapter 5, then Chapter 9; use Chapters 6 and 10 when multi-machine coordination becomes implementation scope. Publisher contents. Local-first software remains useful background for user-owned, multi-device data.
MCP can expose shared tools and resources, ACP can standardise client/agent lifecycle calls, and A2A can support delegation. None of their reviewed scope definitions establishes universal native-session interchange. MCP architecture, ACP sessions, A2A specification.
What to do with these findings
Read the Happier handoff and cross-agent pages together first; they make the two axes easy to distinguish. Then read session-migrate's compatibility matrix and agent-handoff's bundle format. For the broader operating model, read the persistent-agent paper and Enoch's host-migration guide. Session Bridge is the best next reading here for repeated revision tracking.
The smallest useful evaluation remains one Claude→Codex→Claude roundtrip starting from a stopped Claude session using a selected converter, with original records retained. Observe whether an early exact detail and a new Codex contribution remain retrievable after return, whether the latest decision governs continuation, and whether the destination's own rules and tools load independently. This bounds the evaluation to the feature needed now. Machine transfer can be evaluated separately later; it need not become a prerequisite.
This pass inspected source and documentation but did not install or execute the projects. Compatibility with specific installed clients, complete media/child-session transfer and long sequences of roundtrips remain unverified. Publicly indexed X searches produced no usable primary posts; this was not an authenticated search of X's live feed. The evidence supporting the shortlist comes from project documentation, pinned source code and the paper.