How to Sync AI Agent Sessions Across Machines: What Atuin Threads Covers

Atuin 18.24, released with the vendor’s Threads launch post, extends a tool many developers already trust with their shell history to something new: syncing AI agent sessions across machines. If you run Claude Code or Codex on a laptop, a desktop, and a cloud VM, Threads promises that a session started on one machine is searchable, resumable, and even forkable into a different agent harness on another. The promise is real but narrower than it sounds. What travels is the transcript, the conversational history. What does not travel is the runtime state that makes a resumed session behave like the original, because at least one major agent deliberately keeps that state out of the transcript. Adopt Threads as a portable history layer, audit what your transcripts contain before they leave your machines, and do not expect it to replace each vendor’s native resume.

The problem Threads is solving

Anyone who runs terminal coding agents on more than one machine knows the failure mode. You spend a morning on your laptop steering Claude Code through a refactor, close the lid, open your desktop, and the working session is simply not there. Codex’s own repository describes it as a coding agent that runs locally on your computer, and that starting condition, sessions born machine-local, is exactly the gap Threads targets. Vendor resume features get you back into a session on the same machine. Getting the session onto a different machine has been your own problem until now.

The pain is not hypothetical. An empirical study of bugs in Claude Code, Codex, and Gemini CLI catalogs an entire failure category around sessions: “Session Persistence, Unsaved Progress & Task Resumption, Task & Agent State Loss, Context Continuity & Restoration, Session Timeouts & Expiry”. Those categories map closely onto the machine-switch experience, which means a sync layer is being added on top of substrate that already loses state on its own. That matters for expectations: Threads inherits those failure modes rather than eliminating them.

What Atuin Threads actually is

Atuin’s launch post states the capability set plainly: “Starting with Atuin 18.24, you can search your agent sessions across machines, resume them anywhere, or fork the session into a different agent harness.” Three features, each worth taking separately. Cross-machine search is the least ambitious and the most immediately useful: find that session where the agent figured out the migration order, from any machine. Resume anywhere is the headline claim, and the one that needs the most scrutiny, covered below. Forking a session into a different harness is the most unusual: take a conversation that started in one agent CLI and continue it in another.

On security and topology, Atuin says: “Like shell history, Threads is end-to-end encrypted when synced, so we can’t read your sessions. You can use our hosted sync server, run your own, or keep everything local. Capturing agent sessions is opt-in, too.” Three things to note. First, capture is opt-in, so nothing syncs until you turn it on. Second, the hosting choice is a real decision axis: Atuin’s hosted server, a self-hosted server, or local-only operation with no sync at all. Third, “end-to-end encrypted” is vendor language with no protocol detail in the launch post. The claim that Atuin cannot read your sessions is plausible given Atuin’s track record with encrypted shell-history sync, but the launch post does not document the mechanism behind Threads’ encryption, so treat it as a vendor assertion to verify against current docs before you rely on it for sensitive work.

What “resume anywhere” does and doesn’t mean

This is the crux of the decision, and the evidence here is unusually good. A design analysis of Claude Code documents its persistence model: “Session-scoped permissions live in memory only and are not serialized to the transcript, so a new process started with —resume rebuilds the permission context from CLI args and disk settings”. And when the rebuilt context meets something unfamiliar, “any request that the rebuilt context does not recognize falls back to deny-first prompting.”

Work through what that means for a synced transcript. Claude Code’s transcript is append-only durable state, and permission grants are deliberately excluded from it. Any tool that syncs transcripts, Threads included, can therefore carry the conversation but cannot carry the permission state, because that state is not in the artifact being synced. This is not a Threads deficiency; it is a design property of the agent. “Resume anywhere” means history-anywhere. When you resume a synced session on a fresh machine, expect Claude Code to rebuild permissions from that machine’s CLI arguments and disk settings, and to deny-first prompt on anything it does not recognize. The first few actions after a cross-machine resume will feel like a new session asking for consent, because functionally that is what they are.

For Codex, the equivalent statement cannot be made. Codex’s repository documents that the CLI runs locally but not where it stores sessions or what its resume semantics rebuild. That is an open question, not a gap to fill with assumption.

Which harnesses does Threads capture?

The launch post does publish a support list, separate from the MCP install command: “Right now, we supportClaude CodeCodexPiOmpOpenCodewith more agents coming soon” (spacing as in the original). That is a vendor statement that Threads captures sessions from Claude Code, Codex, Pi, Omp, and OpenCode, with more agents planned. Note the mismatch at the edges: Omp appears in the support list but not in the MCP install string, “Our MCP is available as atuin mcp, and can be automatically installed withatuin mcp install claude/codex/pi/opencode”, which names Claude Code, Codex, Pi, and OpenCode as targets for Atuin’s MCP server, the component that lets agents search and reference previous sessions themselves.

What the list does not give you is mechanics. The post does not document how capture hooks into each CLI’s session storage, so treat the list as a vendor claim rather than a tested matrix. Before enabling capture for a specific agent CLI, confirm in Atuin’s current documentation that Threads engages that CLI’s session storage.

What’s inside a synced transcript, and how much of it there is

Agent transcripts are not chat logs. They contain everything the agent saw and said: file contents it read, commands it ran, errors it hit, and the reasoning text around all of it. Community tooling built for Claude Code and Codex gives a concrete vocabulary for what leaks. The ai-tooling repository enforces a leak scan that “fails on private names, local paths, private IP ranges, email addresses, credential shapes and vendor credit lines.” Read that list again in the context of sync: every one of those categories is the kind of thing an agent legitimately touches while working, and every one becomes something that leaves your machines the moment capture is on. A sibling project, the claude-code-workspace-standard, states the underlying norm: “Secrets never land in the workspace in plaintext. Ask for access, not secrets.” Sync does not create these exposures, but it widens the blast radius from one machine’s disk to every synced machine plus whatever sync server sits between them.

Volume is the quieter problem. The workspace-standard repo cites an example of one laptop writing 1.77 TB in a single day of AI-driven development. Transcripts are a fraction of total writes, but agent sessions are verbose, and the “sync everything” instinct collides with storage questions the launch post does not answer. The post gives no sync size limits, and its only retention statement points in one direction: sync “keeps your history backed up forever”, with no quota or deletion policy attached. Check before you point Threads at a busy agent setup.

The pre-enable audit

Before turning on capture, run the same discipline the community tools apply to anything agent-generated that might travel. This checklist derives directly from the leak-scan categories above:

• Secrets and credential shapes. API keys, tokens, connection strings, anything that pattern-matches a credential. Agents see these in config files and environment dumps constantly.
• Local paths. Usernames in home directories, internal mount points, project layouts that reveal org structure.
• Private IP ranges and hostnames. Internal infrastructure the agent touched while debugging.
• Email addresses and private names. Teammates, customers, anyone whose name appeared in code or logs.
• Customer code and vendor credit lines. Third-party material whose presence in a transcript may itself be a disclosure.

The practical method: enable capture, run a representative day of agent work, then search the synced transcripts for each category before you let the volume grow. If your agent work routinely touches regulated customer data, the self-hosted or local-only topology stops being a preference and becomes the requirement.

Threads vs native continuity: the comparison

The choice is not Threads or nothing. It is Threads against two other continuity mechanisms with different guarantees:

The third row deserves explanation. AGENTS.md is a project file both Codex and Claude Code read, and the Project Progress Desk uses it as a continuity channel with no plugin at all: “To add a project, the Desk writes a short note into its AGENTS.md, which both Codex and Claude Code read; no plugin is needed.” File-based state is cross-harness and cross-machine by construction, you control its contents exactly, and the same source notes the Desk’s hygiene rule of keeping credentials and raw data out. What it cannot do is capture the full conversational record. Threads captures everything but with the exposure that implies. Native resume stays on its own machine, and even there, as the same design analysis shows, a —resume process rebuilds permissions from scratch rather than restoring them.

These mechanisms compose rather than compete. A reasonable setup: AGENTS.md and a workspace folder for deliberate, curated project state; native resume for same-machine continuity; Threads for the searchable, portable record of what actually happened across machines.

What I would do, and what to verify first

I would enable Threads on machines whose agent work can tolerate history being portable, in self-hosted or local-only mode if the work touches customer material, and only after running the leak audit above on a sample day of sessions. I would not enable it expecting cross-machine resume to pick up where I left off without re-prompting; Claude Code’s design guarantees it will not, and Codex’s behavior is undocumented.

Before publishing any wiring into your own setup, verify against current vendor docs, because Atuin’s post does not document: how capture hooks each supported CLI’s session storage (it names Claude Code, Codex, Pi, Omp, and OpenCode but not the mechanics); where Codex stores sessions and what its resume rebuilds; the protocol behind Atuin’s end-to-end encryption claim; and sync size limits and any deletion or expiry policy. The 2026-10-27 launch post is announcement-grade, strong on features, thin on mechanics. The durable judgment underneath it holds regardless: portability and state restoration are different properties, syncing transcripts widens your exposure surface by exactly what your agents have seen, and the audit you can run today is worth more than any launch-week headline.

Frequently Asked Questions

Which agent harnesses does Atuin Threads currently support?

Right now, we supportClaude CodeCodexPiOmpOpenCodewith more agents coming soon

Is capturing agent sessions for Atuin Threads mandatory?

Like shell history, Threads is end-to-end encrypted when synced, so we can’t read your sessions. You can use our hosted sync server, run your own, or keep everything local. Capturing agent sessions is opt-in, too.