# Reinstate: full documentation > Every indexable https://reinstate.dev page as Markdown, in reading order. Each section starts with its canonical URL. The curated index is https://reinstate.dev/llms.txt; the HTTP surface is described by https://reinstate.dev/openapi.json. Pages: 65 Capture. Encrypt. Reinstate. # Start on one device. Continue on another. Same session. > Find local coding-agent sessions and sync encrypted Claude Code and Codex work across macOS and Windows with your own S3-compatible storage. Move encrypted Claude Code or Codex sessions between macOS and Windows. Reinstate encrypts the session locally, then stores it in your own S3 or R2 bucket. `curl -fsSL https://reinstate.dev/install.sh | sh` [Read setup guide](https://reinstate.dev/docs/getting-started) [View on GitHub](https://github.com/HarjjotSinghh/reinstate) **Available now:** Claude Code · Codex macOS ↔ Windows 1. 1 **Capture** Select a local session 2. 2 **Encrypt** Seal it before upload 3. 3 **Reinstate** Pull and resume natively `rein` is the CLI for Reinstate Apache‑2.0 one Go binary your bucket, your keys Last reviewed September 7, 2026 02:13 · the plan isn't working ## Git has the code and its history. It does not have the conversation. Git still handles your code. Reinstate carries the encrypted Claude Code and Codex session state Git leaves behind, remapping project paths for the machine you are on. before · without Reinstate ### Context dies at the desk - Sessions trapped on one machine - Paths and agent state drift apart - Context must be rebuilt manually after · with Reinstate ### Portable state you control - Pull sessions onto another device - Remap paths across macOS and Windows - Store encrypted state in your own bucket ## One session. Two machines. Four commands. Zero lost context. List and push on the first machine. Pull on the second. Reinstate remaps the project path, restores the native session, and lets you continue where you left off. Device A ### Windows desktop PowerShell ``` PS C:\reinstate> rein list --agent claude claude ses_7f3a reinstate 2.1 MB 4h ago PS C:\reinstate> rein push --agent claude --session ses_7f3a Encryption passphrase: •••••••• pushed 1 snapshot, skipped 0 unchanged ``` E2E encrypted **age encrypted** your S3 or R2 bucket project map applied Device B ### MacBook zsh ``` $ rein pull --agent claude --session ses_7f3a Encryption passphrase: •••••••• pulled 1 snapshot project map: C:\reinstate → /Users/harjot/Code/reinstate $ claude --resume ses_7f3a ``` Representative CLI output Codex Same encrypted flow: `codex resume ses_7f3a` Trust · ownership · open source ## Sessions leave encrypted. Your bucket never sees plaintext. Your sessions can contain source code and private work. Reinstate encrypts them locally before storage. Your bucket holds ciphertext. Decryption happens locally with the passphrase you enter. *One session package is captured on-device, sealed locally with age, stored as ciphertext in your bucket, and restored on the second device. The one object stored beside them in the clear is keyring.v1.json, which holds no usable key.* ### Local encryption before anything leaves your device Reinstate seals every session snapshot on-device with age before upload. Your S3 or R2 bucket receives ciphertext only, never readable session content. ### Your encryption secret is never uploaded Enter the same passphrase privately on each device. Reinstate never uploads it or stores it in your bucket. Lose it and remote snapshots cannot be recovered. ### Your bucket, your controls Ciphertext lands in your own S3 or R2 bucket, under your region and access controls. ### No Reinstate account required Authenticate directly with your storage provider. Agent auth files and storage credentials are never included in snapshots. ### Backed up before restore Existing session files are backed up before replacement. Validated restores use atomic writes, while conflicts create explicit forks. [Read the security model](https://reinstate.dev/docs/security-model) [View encryption code](https://github.com/HarjjotSinghh/reinstate/tree/main/internal/crypto) [Report a vulnerability](https://github.com/HarjjotSinghh/reinstate/security/advisories/new) Why not Dropbox, iCloud, or rsync? ## Files can sync. Resume can still fail. Same repo, different path, different project key. The files copy successfully, but `--resume` may find nothing. Reinstate maps the destination path and rebuilds the project reference the agent expects. CLAUDE CODE EXAMPLE ### Same repository. Two project keys. RAW FILE SYNC **Windows** source machine same repo · api project root `C:\Users\harjot\projects\api` agent project key `C--Users-harjot-projects-api` Claude index`~/.claude/projects/C--Users-harjot-projects-api/` **macOS** destination machine same repo · api project root `/Users/harjot/dev/api` agent project key `-Users-harjot-dev-api` Claude index`~/.claude/projects/-Users-harjot-dev-api/` Files copied `--resume`: no matching project REINSTATE canonical project `api` destination root `/Users/harjot/dev/api` project identity **rebuilt** ### Files only copy bytes Cloud drives preserve session files, not the agent’s machine-specific project identity. ### Reinstate rebuilds identity It remaps the destination path, then reconstructs the project reference the agent expects. ### Resume stays in your agent Claude Code sessions resume in Claude Code; Codex rollouts resume in Codex—never in a generic transcript viewer. Available now Claude Code Codex macOS ↔ Windows S3 Cloudflare R2 [View compatibility](https://reinstate.dev/docs/adapters) [Compare approaches](https://reinstate.dev/docs/comparison) Where Reinstate fits ## Different tools keep work moving. Reinstate makes the handoff yours. Use cloud handoff for cloud sessions and remote control for a live machine. Use Reinstate when encrypted local session state needs to move between configured computers. 01 CLOUD → LOCAL ### Cloud handoff Continue work that began inside a vendor cloud in that vendor’s local surface. 02 LIVE ACCESS ### Remote control Steer a live session from another screen while the source machine keeps it running. 03 DURABLE HANDOFF ### Reinstate Restore encrypted local session state on another configured computer—even after the original session ends. **Sessions resume in the same agent:** Claude Code stays in Claude Code, and Codex stays in Codex. Cross-agent work uses explicit handoffs. Open source · available now ## Reinstate your next session. Install the CLI, connect your bucket, and continue supported Claude Code and Codex sessions across configured macOS and Windows machines. REINSTATE INSTALLER v0.6.0-rc.6 `curl -fsSL https://reinstate.dev/install.sh | sh` `irm https://reinstate.dev/install.ps1 | iex` checksum verified installs `rein` + `reinstate` [Install Reinstate](https://reinstate.dev/docs/getting-started) [View on GitHub](https://github.com/HarjjotSinghh/reinstate) Apache-2.0 One Go binary Your bucket Your keys No Reinstate account --- Source: https://reinstate.dev/ Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- About Reinstate # What Is Reinstate? Coding-Agent Work Continuity > Reinstate is an open-source continuity layer for coding-agent work, beginning with encrypted Claude Code and Codex session sync across devices. Reinstate is an open-source continuity layer for coding-agent work. Stable v0.2.0 moves encrypted Claude Code and Codex sessions between configured devices and adds configless local search plus same-vendor native resume/fork. Stable v0.3.0 adds verified resume. Stable v0.4.0 adds explicit structured cross-agent handoff after dual-platform tagged-artifact acceptance PASS. Stable v0.5.1 adds universal agent coverage by support tier after dual-platform tagged-artifact acceptance PASS. The v0.6.0-rc.6 release candidate carries Reinstate Hop (cloud continuity) and the interactive CLI; it is not yet certified, with tagged-artifact acceptance pending on native Windows x64 and Apple Silicon macOS deferred. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## The problem Reinstate solves Git moves source code, but it does not move the local history of a long coding-agent task: the rejected approaches, decisions, prompts, file context, and native session identifier. That history becomes fragmented across agents, projects, worktrees, operating systems, and devices. Reinstate owns continuity before and after execution. Coding agents continue to own the actual execution loop. The goal is to let a developer find and continue a task in the right native environment without re-explaining it from scratch. ## What is available today Phase 1 implements the trust-sensitive sync engine and CLI surface for supported Claude Code and Codex CLI sessions: - Same-vendor session discovery, push, pull, status, diff, and conflict handling. - Local age encryption before upload to user-owned S3-compatible storage. - Canonical project identity and macOS ↔ Windows structural path remapping. - Credential exclusions, OS-keyring storage, restore backups, and atomic writes. - Checksum-verifying installers and compatibility checks that fail closed. - Configless local indexing, literal search, bounded inspect, and a TTY switcher. - Native same-vendor Claude Code/Codex resume and fork; read-only discovery across a wider agent catalog by support tier. - Phase 3 verified-resume reports and gates for repository, agent, capability, and runtime state. - Phase 4 structured handoff into a new Claude Code or Codex session. - Phase 5 universal agent coverage: one catalog, one support-tier ladder (T0–T5), honest T0. Stable evidence stays platform-specific. Stable `v0.5.1` is physically verified on Apple Silicon macOS and native Windows x64 (dual-platform tagged-artifact acceptance PASS). Intel macOS and Linux/WSL2 packages are preview and unverified rather than inferred support. The `v0.6.0-rc.6` release candidate — Reinstate Hop and the interactive CLI — is not yet certified; its acceptance is native Windows x64 only, with Apple Silicon macOS deferred until that hardware returns. - **Latest public source tag:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6)(release candidate; cloud continuity and the interactive CLI, not yet a stable claim) - **Latest stable release:** v0.5.1 - **Initial public prerelease:** July 25, 2026 - **Supported operating systems:** Apple Silicon macOS and native Windows x64 verified; Intel macOS and Linux/WSL2 preview ## Where the product goes next | Phase | Direction | Status | | --- | --- | --- | | 1 | Encrypted same-vendor Claude Code and Codex session sync | Stable since v0.1.0 | | 2 | Local universal session index, search, inspect, resume, and last-session commands | Stable v0.2.0 | | 3 | Verified resume against repo, branch, runtime, MCP, and skill state | Phase 3 stable; dual-platform verified resume | | 4 | Explicit portable cross-agent checkpoints and capability diffs | Stable since v0.4.0 | | 5 | Universal agent coverage: one catalog, one support-tier ladder, honest T0 | Stable since v0.5.0/v0.5.1 | | 6C | Cloud continuity: Reinstate Hop (sign-in, locker, device pairing, daemon) | `v0.6.0-rc.6` release candidate; not yet certified, native Windows x64 acceptance pending, Apple Silicon macOS deferred | | 6A/6B | Universal non-secret configuration and automatic cross-device reconciliation | Planned for a later release | | 7 | Project continuity: durable rules and decisions rendered to every agent, plus learned memory with provenance | Planned for v0.8.0, after Phase 6A/6B | | 8+ | Optional thin console, then team continuity | Exploring | Later roadmap work is not present-day functionality. In particular, Reinstate does not provide cross-agent transcript translation, environment repair, configuration sync, or team handoffs. ## What Reinstate is not - Not a code editor, terminal emulator, or full agentic development environment. - Not a multi-agent scheduler, model router, or worktree orchestrator. - Not a Reinstate-owned plugin runtime or marketplace. - Not raw mirroring of entire vendor configuration or credential trees. - Not silent Claude Code ↔ Codex transcript conversion. Reinstate should integrate with the places developers already code. Its product boundary is whether work survives, can be found, and can continue safely—not where that work executes. ## Who Reinstate is for The primary audience is developers using terminal coding agents across multiple sessions, projects, or environments. A work desktop and personal laptop is the flagship multi-device case, especially across Windows and macOS, but physical device count is not the entire product identity. The long-term north-star metric is previously started coding tasks successfully resumed per active user—not storage volume or device count. ## Project and maintainer Reinstate was created and is maintained by[Harjot Singh Rana](https://harjot.co/). The project is available on[GitHub](https://github.com/HarjjotSinghh/reinstate) under the Apache License 2.0 and welcomes review, issues, and contributions. Reinstate is independent of Anthropic, OpenAI, Google, xAI, and other agent vendors. Vendor names describe compatibility targets, not sponsorship or endorsement. ## Learn more [Why open source](https://reinstate.dev/open-source) [Product roadmap](https://reinstate.dev/roadmap) [Current integrations](https://reinstate.dev/integrations) [Security model](https://reinstate.dev/security) [Install or evaluate Reinstate](https://reinstate.dev/docs/getting-started) --- Source: https://reinstate.dev/about/reinstate Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Developer resources # Reinstate Developer Resources: CLI, HTTP API, OpenAPI, and Agent Files > Every machine-readable Reinstate surface in one place: the rein CLI reference, the website HTTP API with its OpenAPI document, compatibility JSON, Markdown page twins, llms.txt, and agent instructions. Reinstate is a local CLI, so the only hosted surface is this website. Everything on it that a program or an AI agent might need is listed here: the CLI reference, the website HTTP API and its OpenAPI document, the compatibility matrix as JSON, a Markdown representation of every page, and the index files agents read first. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## What exists today - **Product:** Reinstate, an open-source coding-agent continuity tool written in Go - **CLI:** `rein` or `reinstate`; see the [command reference](https://reinstate.dev/docs/cli-reference) - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Hosted API:** None. The CLI talks only to your own S3-compatible bucket; this website exposes the endpoints below. - **Account:** Not required for the CLI or for any endpoint on this site - **License:** [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0) ## Reinstate CLI Install with the pinned bootstrap scripts, then use the[CLI reference](https://reinstate.dev/docs/cli-reference) for every command, flag, exit code, and recovery path. Scripts and agents should pass `--json` where a command supports it and `--dry-run` before any command that launches a vendor or writes to storage. ```sh curl -fsSL https://reinstate.dev/install.sh | sh rein doctor rein sessions --json ``` The installers live at [/install.sh](https://reinstate.dev/install.sh) (macOS, Linux, WSL2) and[/install.ps1](https://reinstate.dev/install.ps1) (native Windows PowerShell). Read them before piping them to a shell; they pin a specific signed release. ## Machine-readable files | URL | What it is | | --- | --- | | [OpenAPI 3.1 document](https://reinstate.dev/openapi.json) `/openapi.json` | Describes the JSON API with operation IDs, typed parameters, typed response schemas, rate-limit headers, and the versioning and deprecation policy. | | [API catalog (RFC 9727)](https://reinstate.dev/.well-known/api-catalog) `/.well-known/api-catalog` | Linkset that points at the OpenAPI description, the developer docs, and the agent index files. | | [Compatibility matrix](https://reinstate.dev/compatibility.json) `/compatibility.json` | Agent tiers, tested version ranges, operating-system status, evidence links, and review dates. Same data as the compatibility page. | | [llms.txt](https://reinstate.dev/llms.txt) `/llms.txt` | Curated index of canonical pages with one-line summaries and a when-to-use section for agents. | | [llms-full.txt](https://reinstate.dev/llms-full.txt) `/llms-full.txt` | Every indexable page as one Markdown file, each section prefixed with its canonical URL. | | [Agent instructions](https://reinstate.dev/agent-instructions.md) `/agent-instructions.md` | Best-fit jobs, jobs Reinstate is wrong for, the commands to run, and the safety rules that apply. | | [Sitemap index](https://reinstate.dev/sitemap-index.xml) `/sitemap-index.xml` | XML sitemap of every indexable page. | | [All-updates feed](https://reinstate.dev/rss.xml) `/rss.xml` | RSS feed of blog posts and changelog entries; /blog/rss.xml and /changelog/rss.xml are the split feeds. | ## Website HTTP API The website API is small and documented in full by [/openapi.json](https://reinstate.dev/openapi.json)(OpenAPI 3.1) and catalogued at [/.well-known/api-catalog](https://reinstate.dev/.well-known/api-catalog)(RFC 9727). No authentication, no API key. Every response links back to these documents in its `Link` header. | Method | Path | Behavior | | --- | --- | --- | | `GET` | `/api/v1/waitlist` | Service descriptor with the API major version; doubles as a liveness probe. | | `POST` | `/api/v1/waitlist` | Join the early-access waitlist with {"email":"you@example.com"}. Duplicate submissions return status "duplicate". | | `GET/POST` | `/api/waitlist` | Deprecated unversioned alias of /api/v1/waitlist. Same behavior plus Deprecation and Link rel="successor-version" headers; no Sunset scheduled. | | `GET` | `/.well-known/api-catalog` | RFC 9727 API catalog (linkset) pointing at the OpenAPI description, these docs, and the agent index files. | | `ANY` | `/api/*` | Undocumented paths, including unknown /api/v1/\* paths, return a problem+json 404; unsupported methods return 405 with an Allow header. | ### Versioning and deprecation Stable operations live under a major-version path, `/api/v1/`. Additive changes ship in place; a breaking change requires a new major path such as `/api/v2/`. A deprecated path keeps working and announces itself with the RFC 9745`Deprecation` header (the date in `@seconds` form), a`Link` with `rel="successor-version"`, and, once a removal date exists, the RFC 8594 `Sunset` header at least 90 days before removal. Today`/api/waitlist` is the only deprecated path; it has no scheduled Sunset. The same policy is machine-readable under `x-api-lifecycle` in[/openapi.json](https://reinstate.dev/openapi.json). ### Rate limits Every `/api/*` response carries the IETF RateLimit header fields (`RateLimit-Policy` and `RateLimit` as structured fields, plus the compatibility `RateLimit-Limit`, `RateLimit-Remaining`, and`RateLimit-Reset`). The policy is `"api";q=60;w=60`: 60 requests per client address per 60 seconds, counted per function instance, so treat it as advisory. A 429 response is a problem document with `code: "rate_limited"` and a`Retry-After` header. ```http RateLimit-Policy: "api";q=60;w=60 RateLimit: "api";r=59;t=42 RateLimit-Limit: 60 RateLimit-Remaining: 59 RateLimit-Reset: 42 ``` ### Errors Errors are RFC 9457 problem details (`application/problem+json`). The`type` URI resolves to the matching entry below, `code` is stable,`hint` says what to change before retrying, and the legacy `ok` and`error` members remain for early integrations. ```json { "type": "https://reinstate.dev/developers#error-invalid-email", "title": "Email address is invalid", "status": 400, "detail": "Enter a valid email address.", "instance": "/api/v1/waitlist", "code": "invalid_email", "hint": "Provide one deliverable address in the email field; it is trimmed and lower-cased before storage.", "docs": "https://reinstate.dev/developers#errors", "ok": false, "error": "Enter a valid email address." } ``` | Code | Status | When | | --- | --- | --- | | `invalid_json` | 400 | The request body is not JSON or lacks the email field. | | `invalid_email` | 400 | The email field is empty or not a deliverable address. | | `storage_unavailable` | 503 | Waitlist storage is temporarily down; Retry-After is set and the request is safe to repeat. | | `not_found` | 404 | No API route exists at the path. | | `method_not_allowed` | 405 | The path does not support the method; the Allow header lists the supported ones. | | `rate_limited` | 429 | More than 60 requests in 60 seconds from one client address; Retry-After is set. | ## Markdown for agents Every page negotiates on the `Accept` header. Send`Accept: text/markdown` to the canonical URL and the response is the page's Markdown representation with `Content-Type: text/markdown; charset=utf-8` and`Vary: Accept`; send `text/html` or nothing and the HTML page comes back. Each page also has a static twin at the same path plus `.md`(`/docs/getting-started.md`; the homepage is `/index.md`). ```sh curl -sH "Accept: text/markdown" https://reinstate.dev/docs/getting-started curl -s https://reinstate.dev/docs/getting-started.md ``` Unknown paths return a real HTTP 404. Browsers get the not-found page; any client that does not ask for HTML gets a short Markdown body that links to the sitemap, llms.txt, and the documentation index. An `Accept` header that rejects both HTML and Markdown returns 406 with a plain-text list of the two representations. ## Not provided - No hosted Reinstate service, API key, or account: sessions move between your devices through storage you own. - No MCP server, plugin runtime, or marketplace. Universal agent configuration is a [roadmap](https://reinstate.dev/roadmap) item, not a shipped feature. - No cross-vendor transcript translation. Cross-agent work uses the explicit [structured handoff](https://reinstate.dev/docs/handoff). ## Source, security, and support - [GitHub repository](https://github.com/HarjjotSinghh/reinstate) and [release tags](https://github.com/HarjjotSinghh/reinstate/tags) - [Security policy](https://github.com/HarjjotSinghh/reinstate/security/policy) and the [security model](https://reinstate.dev/docs/security-model) - [Compatibility](https://reinstate.dev/compatibility) and [agent-version history](https://reinstate.dev/compatibility/agent-version-history) - [Troubleshooting](https://reinstate.dev/docs/troubleshooting) and [FAQ](https://reinstate.dev/docs/faq) --- Source: https://reinstate.dev/developers Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Documentation > Learn how to install Reinstate, sync Claude Code and Codex sessions, remap project paths, and keep credentials out of encrypted storage. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate's stable v0.5.1 CLI finds local sessions across its full agent catalog by support tier without configuration, syncs same-vendor Claude Code and Codex sessions between devices through client-side-encrypted S3-compatible storage, and continues the same task in a new Claude Code or Codex session via structured handoff. The v0.6.0-rc.6 release candidate carries Reinstate Hop (cloud continuity) and the interactive CLI; it is not yet certified, with native Windows x64 acceptance pending and Apple Silicon macOS deferred. Universal configuration remains roadmap work. Prefer the short CLI alias `rein`. Full name `reinstate` is the same binary. ## Guides - [Install and sync Reinstate across devices](https://reinstate.dev/docs/getting-started) — Install Reinstate, configure encrypted S3-compatible storage, and restore a Claude Code or Codex session safely on another development machine. - [How Reinstate syncs coding-agent sessions](https://reinstate.dev/docs/architecture) — Understand Reinstate's adapters, structural path remapping, age encryption, immutable snapshots, conflict handling, and S3-compatible storage architecture. - [Reinstate features and commands from v0.1.0 to v0.5.1](https://reinstate.dev/docs/features) — See which Reinstate features and CLI commands shipped in stable v0.1.0 through v0.5.1, including encrypted sync, verified resume, structured handoff, and agent coverage. - [Claude Code and Codex session adapters](https://reinstate.dev/docs/adapters) — Learn how Reinstate adapters discover, normalize, and restore Claude Code and Codex sessions without translating native transcripts across vendors. - [Reinstate security and encryption model](https://reinstate.dev/docs/security-model) — See how Reinstate encrypts session data before upload, excludes credential files, stores storage keys, handles conflicts, and defines its threat boundaries. - [Universal agent configuration roadmap](https://reinstate.dev/docs/universal-configuration) — Explore the planned non-secret desired-state model for rendering MCP servers, skills, hooks, plugins, marketplaces, and safe settings across coding agents. - [Reinstate compared with vendor and file sync](https://reinstate.dev/docs/comparison) — Compare Reinstate with native agent sync, session browsers, full agent development environments, single-agent utilities, and do-it-yourself file syncing. - [Reinstate frequently asked questions](https://reinstate.dev/docs/faq) — Get direct answers about Reinstate's current session-sync scope, supported agents, encryption, storage, offline behavior, cross-agent handoffs, and roadmap. - [Troubleshoot Reinstate session sync](https://reinstate.dev/docs/troubleshooting) — Fix Reinstate installation, compatibility, session selection, mapping, manifest, passphrase, conflict, credential, performance, and active-agent errors safely. - [Install the Reinstate CLI](https://reinstate.dev/docs/installation) — Install the pinned Reinstate stable release on macOS, native Windows, or WSL2, verify its checksum and version, and diagnose PATH failures. - [Configure Reinstate profiles and project paths](https://reinstate.dev/docs/configuration) — Configure a Reinstate profile, S3-compatible storage coordinates, OS-keyring credentials, and portable project mappings across development devices. - [Configure storage for encrypted Reinstate sessions](https://reinstate.dev/docs/storage) — Understand Reinstate's S3-compatible storage fields, object layout, required permissions, encrypted payloads, profile isolation, and retention limits. - [Push one coding-agent session](https://reinstate.dev/docs/sync-a-session) — Select, dry-run, encrypt, and push one supported Claude Code or Codex session to user-owned S3-compatible storage with Reinstate. - [Restore and resume one coding-agent session](https://reinstate.dev/docs/restore-a-session) — Dry-run, safely restore, verify, and natively resume one encrypted Claude Code or Codex session on another configured device. - [Reinstate CLI command reference](https://reinstate.dev/docs/cli-reference) — Use every current Reinstate command with its purpose, parameters, expected evidence, platform notes, failure modes, and safe recovery path. - [Reinstate limitations and stable-platform boundaries](https://reinstate.dev/docs/limitations) — Review Reinstate limitations for agents, operating systems, native resume, storage, snapshots, path remapping, security, and release certification. - [Structured handoff between Claude Code and Codex](https://reinstate.dev/docs/handoff) — Continue the same coding-agent task in a new Claude Code or Codex session with Reinstate structured handoff, without native resume or transcript translation. - [Reinstate Hop: Sign-In, Devices, and the Locker](https://reinstate.dev/docs/hop) — See how Reinstate Hop's passwordless sign-in, device pairing, encrypted locker, verification, and daemon work in the v0.6.0-rc.6 candidate. - [Project continuity roadmap](https://reinstate.dev/docs/project-continuity) — Explore the planned model for one project understanding across agents: durable rules and decisions in the repository, plus learned memory with provenance. --- Source: https://reinstate.dev/docs Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Install and sync Reinstate across devices > Install Reinstate, configure encrypted S3-compatible storage, and restore a Claude Code or Codex session safely on another development machine. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate finds and continues local coding-agent sessions without setup, and optionally synchronizes same-vendor Claude Code and Codex CLI sessions across machines through client-side-encrypted, user-owned S3-compatible storage. > **Release status:** the public installers pin the newest release candidate, named in the [changelog](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md); stable remains `v0.5.1`. This candidate’s acceptance is native Windows x64 only; Apple Silicon macOS is deferred until that hardware returns. Intel macOS and Linux/WSL2 are optional and unverified. ## Prerequisites - Apple Silicon macOS or native 64-bit Windows for mandatory Phase 3 acceptance - Intel macOS, Linux, or WSL2 only as preview, unverified environments; WSL1 is refused - Claude Code and/or Codex CLI - an S3-compatible bucket you control, such as Cloudflare R2 - its endpoint, bucket name, access-key ID, and secret access key - one long encryption passphrase you can enter privately on every device Reinstate never needs your Anthropic or OpenAI account credentials. ## Install macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` Native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` Both bootstraps pin the newest release candidate named in the [changelog](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md), verify the exact tagged canonical installer and release binary, install without elevation, configure a user-local PATH, and print the next command. They install the CLI only; interactive configuration begins when you run `rein init`. The POSIX bootstrap can install the binary on Intel macOS, Linux, or WSL2, but those environments are optional and unverified for that candidate. Default locations: - macOS/Linux: `~/.local/bin` - Windows: `%LOCALAPPDATA%\Programs\Reinstate\bin` Verify: ```sh rein version --json rein setup check ``` Local discovery needs no initialization or cloud account: ```sh rein sessions rein search "webhook retry" rein inspect claude:SESSION_ID rein resume claude:SESSION_ID --dry-run rein handoff claude:SESSION_ID --to codex --dry-run --json ``` These commands use a private derived local index. Native resume and fork stay same-vendor; Gemini CLI and OpenCode records are read-only for native launch. Structured handoff can start a new Claude Code or Codex session from those sources. Before initialization, `setup check` should report only the missing Reinstate config. Platform, keyring, or agent-compatibility failures are blockers. ## Inspect first macOS/Linux: ```sh curl -fsSL https://reinstate.dev/install.sh -o reinstate-install.sh less reinstate-install.sh sh reinstate-install.sh ``` Windows PowerShell: ```powershell $Installer = Join-Path $env:TEMP "reinstate-install.ps1" Invoke-WebRequest https://reinstate.dev/install.ps1 -OutFile $Installer Get-Content $Installer & ([ScriptBlock]::Create([IO.File]::ReadAllText($Installer))) ``` ## First device ```sh rein init \ --project local/my-project=/absolute/path/to/my-project ``` Enter the S3/R2 service endpoint, bucket, and credentials privately. Do not add the bucket name to the endpoint URL. Credential input is hidden and stored in the native OS keyring. Reinstate probes storage before writing local configuration. Save the printed non-secret `profile_id`, then run: ```sh rein setup check rein doctor --self-test rein list --agent all ``` Create a harmless session and select its ID: ```sh rein list --agent claude rein push --agent claude --session SESSION_ID --dry-run rein push --agent claude --session SESSION_ID ``` Use `--all` only after you explicitly decide to sync every discovered session. ## Additional device Use the same profile ID and canonical project ID, mapped to this device’s local path: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project local/my-project=/different/absolute/path ``` Enter the same endpoint, bucket, credentials, and encryption passphrase. Reinstate requires the existing encrypted remote manifest to be readable before it saves the additional device’s configuration. Validate without mutation: ```sh rein setup check rein doctor --self-test rein status # Claude Code rein pull --agent claude --session SESSION_ID --dry-run # Codex rein pull --agent codex --session SESSION_ID --dry-run ``` Close the selected agent before replacing an existing local session, then run: ```sh # Claude Code rein pull --agent claude --session SESSION_ID rein list --agent claude claude --resume SESSION_ID # Codex rein pull --agent codex --session SESSION_ID rein list --agent codex codex resume SESSION_ID ``` ## Agent-assisted setup Copy the pinned setup prompt for your agent: - [Claude Code prompt](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/prompts/claude-code-setup.md) - [Codex prompt](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/prompts/codex-setup.md) The agent can inspect, install, and run redacted checks. You enter storage credentials and the encryption passphrase privately, never in chat. ## Prove Phase 1 Run the complete [MacBook + Windows acceptance checklist](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md) to evaluate both agents, both directions, backups, conflicts, wrong-passphrase refusal, and ciphertext-only storage. Passing the committed checklist is a release gate; this page does not claim that the gate has passed. ## Safety - remote manifests and snapshots are encrypted; - auth and credential files are hard-excluded; - pulls validate before mutation and back up existing targets; - divergence produces conflict records instead of silent overwrite; - mutating pulls refuse to replace a session while the matching agent is active; and - passphrases are accepted through hidden input or an explicit pre-opened file descriptor, never a normal CLI argument or environment value. --- Source: https://reinstate.dev/docs/getting-started Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Install the Reinstate CLI > Install the pinned Reinstate stable release on macOS, native Windows, or WSL2, verify its checksum and version, and diagnose PATH failures. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Install Reinstate with the official bootstrap for your operating system, then require `rein version --json` to report the pinned candidate named in the [changelog](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md). The bootstrap verifies the canonical tagged installer, release checksum, downloaded binary, and reported version before replacing an existing installation. > **Release status:** the publicly installed candidate is a pre-1.0 release whose tagged-artifact acceptance is pending on native Windows x64 (Apple Silicon macOS is deferred until that hardware returns). Stable remains `v0.5.1`; Intel macOS and Linux/WSL2 remain optional and unverified. ## Prerequisites - Apple Silicon macOS or native Windows x64 for mandatory Phase 4 acceptance, or an optional unverified environment (Intel macOS, Linux, or WSL2). WSL1 is refused. - A user account that can write to a user-local installation directory. - HTTPS access to `reinstate.dev` and the project’s GitHub Release assets. - A new terminal after PATH changes. Installation does not require an Anthropic account credential, OpenAI account credential, S3 credential, or Reinstate passphrase. Those secrets belong to later setup prompts, never the installer command or an agent chat. ## Install with Homebrew on Apple Silicon macOS ```sh brew install HarjjotSinghh/tap/reinstate ``` The tap formula may lag until the package-publish workflow lists `0.4.0`. GitHub Releases are the source of truth. Intel macOS and Linuxbrew remain optional and unverified for this release; use the bootstrap below if you prefer the canonical installer path. ## Install with the official bootstrap For macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` The default binary directory is `~/.local/bin`. The script installs `reinstate` and its shorter `rein` alias without elevation, updates the appropriate user shell startup file when needed, and prints an absolute next command that works in the current shell. For native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` The default directory is `%LOCALAPPDATA%\Programs\Reinstate\bin`. The script installs `reinstate.exe` and `rein.exe`, adds the directory to the user PATH and current PowerShell process, and does not configure WSL. Native Windows and WSL2 must use separate Reinstate homes and device identities. Do not point WSL2 at `%USERPROFILE%\.reinstate` or share one native agent-state directory between the two environments. ## Inspect the installer before execution Download and read the script when your environment requires review before execution. macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh -o reinstate-install.sh less reinstate-install.sh sh reinstate-install.sh ``` Native Windows: ```powershell $Installer = Join-Path $env:TEMP "reinstate-install.ps1" Invoke-WebRequest https://reinstate.dev/install.ps1 -OutFile $Installer Get-Content $Installer & ([ScriptBlock]::Create([IO.File]::ReadAllText($Installer))) ``` Both bootstraps pin the exact Reinstate tag, retrieve the canonical installer from that tag, verify its SHA-256, download the matching release asset and `checksums.txt`, verify the asset, and execute the downloaded binary’s version check before installation. ## Replacing an existing version An already installed different version is preserved until you explicitly approve replacement. On POSIX, the replacement prompt has a 30-second default timeout and refuses when the active shell cannot perform a timed TTY read. A timeout, unsupported shell, or invalid timeout preserves the existing binary. After reviewing the requested version change, deliberate POSIX automation may set `REINSTATE_CONFIRM_REPLACE=1`. The timeout can be set from 1 through 300 seconds with `REINSTATE_CONFIRM_TIMEOUT_SECONDS`. These switches approve only binary replacement; they do not approve configuration, credentials, or session transfer. ## Verify the installed CLI Open a new terminal and run: ```sh rein version --json reinstate version --json rein setup check ``` Before `rein init`, `setup check` should identify missing Reinstate configuration. An installed agent can also report `SUPPORTED`, `UNTESTED`, `UNSUPPORTED`, or `NOT_INSTALLED`; resolve platform, keyring, or compatibility failures before synchronization. ## Expected evidence - Both binary names resolve without an absolute path and report the same `0.4.0` version. - The binary architecture matches the current environment. - The installer reports successful checksum and release-version checks. - `rein setup check` runs as a read-only preflight and does not claim the uninitialized device is ready to sync. Save command output only after redacting private paths. Binary verification is not proof of stable support outside Apple Silicon macOS and native Windows x64. ## Failure paths - If the shell cannot resolve `rein`, follow [binary and PATH troubleshooting](https://reinstate.dev/docs/troubleshooting#why-is-the-rein-binary-not-found-after-installation). - Stop after any missing checksum entry, SHA-256 mismatch, release version mismatch, unsupported architecture, or installer download failure. - Treat `setup check` exit code `5` as a compatibility blocker, not a warning to bypass. - Report a suspected malicious or substituted release through the private [security policy](https://github.com/HarjjotSinghh/reinstate/security/policy). Do not solve an installer failure by downloading an unofficial mirror or disabling checksum verification. ## Security boundaries The installers establish release identity and binary integrity; they do not make the pre-1.0 product formally audited. They do not request agent credentials, storage credentials, or the session passphrase. Run installers with ordinary user permissions, inspect them when policy requires, and keep release output free of secrets. An agent may help inspect commands and redacted results. Enter later storage credentials and the encryption passphrase privately into Reinstate’s hidden prompts, never into Claude Code, Codex, shell history, or a public issue. ## Related pages - [Configure Reinstate after installation](https://reinstate.dev/docs/configuration) - [Complete first-device setup](https://reinstate.dev/docs/getting-started) - [Check current platform and agent compatibility](https://reinstate.dev/compatibility) - [Review the security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/docs/installation Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Configure Reinstate profiles and project paths > Configure a Reinstate profile, S3-compatible storage coordinates, OS-keyring credentials, and portable project mappings across development devices. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Run `rein init` once per device. Devices in one sync set use the same non-secret `profile_id`, bucket, prefix, and canonical project IDs, while each device receives its own `device_id`, local project roots, OS-keyring credential entry, and Reinstate home. > **Current scope:** `config.toml` configures Phase 1 session sync only. Commands for portable MCP servers, skills, hooks, plugins, marketplaces, and cross-harness settings are roadmap work and do not exist in Reinstate. ## Prerequisites - Reinstate `v0.5.1`, verified with `rein version --json`. - A private S3-compatible bucket, service endpoint, region, access-key ID, and secret access key. - One stable project ID and the repository’s absolute path on this device. - A supported Claude Code or Codex version if the device will push or restore sessions. - The first device’s exact `profile_id` when joining an existing profile. Do not use an agent account token as an object-storage credential. Reinstate does not need Anthropic or OpenAI account credentials. ## Reinstate home and files The default home is `~/.reinstate` on macOS and WSL2, and `%USERPROFILE%\.reinstate` on native Windows. An absolute `REINSTATE_HOME` value selects a different home for deliberate isolation or testing. | Path | Current contents | | --- | --- | | `config.toml` | Schema v1 profile, storage coordinates, credential reference, enabled adapters, and project mappings | | `state.json` | Schema v1 local and remote session revisions and last manifest revision | | `backups/` | Timestamped pre-replacement config, state, and session backups | | `conflicts/` | Unresolved conflict metadata and resolution audit records | | `cache/`, `locks/`, `logs/` | Private runtime data | Configuration and state are written atomically with owner-only permissions. Secret values are invalid configuration fields. ## Configure the first device Choose a canonical project ID that remains stable across devices. A repository identity such as `github.com/acme/app` is clearer than a device-specific path: ```sh rein init \ --project github.com/acme/app=/absolute/path/to/app ``` Enter the S3/R2 service endpoint, bucket, and storage credentials only in the interactive prompts. Keep the bucket name out of the endpoint URL; the bucket has its own field. Interactive setup probes storage before it writes config, stores storage credentials in the native OS keyring, initializes `config.toml` and `state.json`, and prints the new `profile_id`. Save that UUID. It is not a secret, but it is the identity that later devices must join. The default object prefix is `profiles/` unless you explicitly configure another prefix. ## Configure an additional device Reuse the profile and project identities, but map the project to the destination’s actual absolute path: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project github.com/acme/app=/different/absolute/path ``` Use the same service endpoint, region, bucket, prefix, and storage credential scope. Reinstate requires the existing encrypted `manifest.age` to be present and readable before saving an additional device’s config. It records `remote_profile_required = true`, so later `status`, `diff`, `pull`, and push operations fail if the established manifest disappears. Native Windows and WSL2 are different devices. Give each its own home and mapping even when both point to worktrees on the same physical computer. ## Project mapping contract The same canonical ID must identify the same repository on every device: ```text github.com/acme/app = /Users/me/code/app github.com/acme/app = C:\Users\me\code\app github.com/acme/app = /mnt/c/Users/me/code/app ``` Only one of those local roots belongs in a given device’s config. During export, adapters replace recognized structural roots with `${REPO:}`. During restore, the destination expands that token through its own mapping. Reinstate does not rewrite arbitrary path-like prose, prompts, tool output, or unknown fields. ## Reinitialize an existing home Reinstate refuses ordinary `init` when `config.toml` or `state.json` already exists and exits with safety code `7`. Review the current home before intentionally running: ```sh rein init --force ``` The forced path backs up the existing config and state together beneath one timestamped `backups/` directory before replacing them. It is not a merge, and it does not recover a lost passphrase or remote profile. ## Validate the configuration ```sh rein setup check --json rein doctor --self-test rein list --agent all --json rein status --json ``` `status` reads and decrypts the remote manifest, so wait for the hidden passphrase prompt. The passphrase is not stored. `doctor --self-test` uses synthetic data and does not read real session content. ## Expected evidence - `init` reports `config.toml + state.json`, a UUID `profile_id`, and a `credential_ref` without printing the credential. - The storage probe succeeds and cleans up its temporary probe object. - `setup check` reports the device and installed adapter states truthfully. - On an additional device, `status` returns the existing remote revision and session keys rather than an empty replacement profile. - A scoped push or pull dry-run expands the canonical project ID to the correct local destination. ## Failure paths - For a missing remote profile on an additional device, follow [remote-manifest troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-reinstate-report-a-remote-profile-manifest-is-missing). - For a passphrase failure, follow [passphrase troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-passphrase-verification-fail-on-a-second-device). - For a Claude session restored beneath the wrong project key, use the [native-resume diagnostic](https://reinstate.dev/docs/troubleshooting#why-does-claude---resume-not-see-a-pulled-session). - Do not create an empty `manifest.age`, invent a new profile ID, or use `--force` merely to silence a coordinate mismatch. ## Security boundaries `config.toml` contains endpoints, bucket names, prefixes, IDs, local paths, and a credential reference; treat paths and infrastructure names as private metadata even though they are not secret keys. Storage keys belong in the OS keyring. The explicit non-interactive provider may read `REINSTATE_S3_ACCESS_KEY_ID` and `REINSTATE_S3_SECRET_ACCESS_KEY` without persisting them, but they must never be committed, logged, or pasted into chat. Interactive `status`, `push`, and `pull` read the encryption passphrase through a hidden prompt. Automation must use a pre-opened descriptor through `REINSTATE_PASSPHRASE_FD`; ordinary passphrase environment values and CLI flags are rejected. ## Related pages - [Choose and configure object storage](https://reinstate.dev/docs/storage) - [Push one selected session](https://reinstate.dev/docs/sync-a-session) - [Restore one selected session](https://reinstate.dev/docs/restore-a-session) - [Understand current limitations](https://reinstate.dev/docs/limitations) - [Universal agent configuration roadmap](https://reinstate.dev/docs/universal-configuration) --- Source: https://reinstate.dev/docs/configuration Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Reinstate features and commands from v0.1.0 to v0.5.1 > See which Reinstate features and CLI commands shipped in stable v0.1.0 through v0.5.1, including encrypted sync, verified resume, structured handoff, and agent coverage. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** September 5, 2026 Stable **`v0.5.1`** is the current release. It includes every shipped surface from Phase 1 through Phase 5. Use this page as the versioned feature map. The `v0.6.0-rc.6` release candidate — Reinstate Hop (cloud continuity) and the interactive CLI — is covered in its own section below and is not yet a stable claim: its acceptance is native Windows x64 only, with Apple Silicon macOS deferred. Universal configuration, a Reinstate console, and team continuity remain later phases. A structured handoff starts a **new destination session continuing the same task**. Native resume stays same-vendor. Reinstate does not reconstruct a vendor session or translate one agent’s transcript into another. The `rein` and `reinstate` names run the same binary. ## Stable lines | Line | Shipped | Surface | | --- | --- | --- | | `v0.1.0` | 2026-07-30 | Encrypted Claude Code / Codex sync across devices | | `v0.2.0` | 2026-08-05 | Configless local index, search, inspect, last, resume, fork | | `v0.3.0` | 2026-08-11 | Verified resume environment report and launch gate | | `v0.4.0` | 2026-08-16 | Structured handoff into a new Claude Code or Codex session | | `v0.5.0` | 2026-08-21 | Universal agent coverage: 18-agent catalog, `rein doctor --agents` | | `v0.5.1` | 2026-08-21 | Patch: pure-Go SQLite driver bump; no product-surface change | Mandatory verified platforms remain Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 stay preview/unverified. The `v0.6.0-rc.6` release candidate is not in this table because it is not yet a stable line; see the release-candidate section near the bottom of this page. ## Command map | Command | Since | Needs `init` | | --- | --- | --- | | `rein version`, `doctor`, `setup check`, `completion` | 0.1 | no | | `rein init`, `list`, `status`, `diff`, `push`, `pull`, `conflicts` | 0.1 | yes after init | | `rein sessions`, `search`, `inspect` | 0.2 | no | | `rein last`, `resume`, `fork`, bare `rein` | 0.2 | no | | `--allow-environment-warning` | 0.3 | no | | `rein handoff`, `handoff list`, `inspect`, `export` | 0.4 | no | | `rein resume --with claude|codex` | 0.4 | no | | `rein doctor --agents [--acceptance-matrix]` | 0.5 | no | | `rein login`, `rein whoami` | 0.6.0-rc.6 (candidate) | no | | `rein init --hop`, `rein account init|recover|join|status` | 0.6.0-rc.6 (candidate) | yes | | `rein devices [approve|revoke]`, `rein hop status|credentials` | 0.6.0-rc.6 (candidate) | yes | | `rein sync verify`, `rein sync migrate --to byo` | 0.6.0-rc.6 (candidate) | yes | | `rein daemon run|install|start|stop|uninstall|status` | 0.6.0-rc.6 (candidate) | yes | | bare `rein` interactive switcher, `ctrl+k` palette, `--plain` | 0.6.0-rc.6 (candidate) | no | Flag-level syntax lives in the [CLI reference](https://reinstate.dev/docs/cli-reference). Rows marked “candidate” ship in `v0.6.0-rc.6`, not in stable `v0.5.1`. ## v0.1.0 — encrypted sync ```sh rein init --project github.com/acme/app=/absolute/path/to/app rein push --agent claude --session SESSION_ID --dry-run rein pull --agent claude --session SESSION_ID --dry-run ``` Client-side age encryption, user-owned S3-compatible storage, path remapping, credential exclusion, atomic restore, and conflict forks. ## v0.2.0 — local continuity ```sh rein sessions rein search "webhook retry" --agent claude rein inspect claude:SESSION_ID rein resume codex:SESSION_ID --dry-run ``` No bucket required. Gemini CLI and OpenCode are read-only. Native resume is Claude Code → Claude Code and Codex → Codex only. ## v0.3.0 — verified resume ```sh rein resume claude:SESSION_ID --dry-run --json rein resume claude:SESSION_ID --allow-environment-warning baseline.unavailable ``` Workspace, agent, capability, and runtime checks. Blockers cannot be overridden. ## v0.4.0 — structured handoff ```sh rein handoff claude:SESSION_ID --to codex --dry-run --json rein handoff list --json rein resume claude:SESSION_ID --with codex --dry-run --json ``` Sources: Claude Code, Codex, Gemini CLI, OpenCode, Grok Build. Destinations: Claude Code and Codex only. The destination first reply restates five acknowledgement bullets. Capsules stay local and are excluded from sync. Fail-closed ranges: Claude Code `2.1.219`–`2.1.238`, Codex CLI `0.133.0`–`0.149.0`. Dual-platform tagged-artifact acceptance passed on Apple Silicon macOS and native Windows x64 (44/44 on both devices). ## Not in v0.4.0 Reconstructed cross-agent sessions, Gemini/OpenCode/Grok destinations, universal configuration, and Intel macOS or Linux as verified platforms. ## v0.5.0 — universal agent coverage ```sh rein doctor --agents --json rein doctor --agents --acceptance-matrix --json ``` One catalog of eighteen coding agents, one support-tier ladder (T0–T5), and a conformance suite that holds each descriptor’s capabilities to its declared tier. Session discovery lands for six T1 agents (Kimi Code CLI, Qwen Code, Pi, Cursor CLI, GitHub Copilot CLI, Cline) and three more T2 handoff sources (Gemini CLI, OpenCode, Grok Build). Same-vendor native resume, fork, and encrypted sync stay Claude Code and Codex CLI only. Verified ranges reach Claude Code `2.1.238` and Codex CLI `0.149.0` on dual-platform physical resume evidence. Dual-platform tagged-artifact acceptance passed across the full 150-row matrix on Apple Silicon macOS and native Windows x64. `v0.5.1` is a patch on top of `v0.5.0`: a pure-Go SQLite driver bump with no product-surface change, re-verified on both platforms. ## Not in stable v0.5.1 Reconstructed cross-agent sessions; Gemini CLI, OpenCode, Grok Build, Qwen Code, or Kimi Code CLI as handoff destinations or native-resume agents; encrypted sync beyond Claude Code and Codex CLI; Reinstate Hop; the interactive CLI; universal configuration; and Intel macOS or Linux as verified platforms. ## v0.6.0-rc.6 — Reinstate Hop and the interactive CLI (release candidate) `v0.6.0-rc.6` is a release candidate, not a stable claim: stable remains `v0.5.1`, and this candidate’s acceptance is native Windows x64 only, with Apple Silicon macOS deferred until that hardware returns. ```sh rein login rein init --hop rein account init rein push --agent claude --session SESSION_ID # or --all for every discovered session rein hop status rein sync verify ``` Reinstate Hop ships as ordinary `rein` commands with no build tag or feature flag: passwordless sign-in (`rein login` / `rein whoami`), the locker and keyring (`rein init --hop`, `rein account init\|recover\|join\|status`), device pairing and revocation (`rein devices`, `approve`, `revoke`), verification (`rein sync verify`), leaving Hop (`rein sync migrate --to byo`), and a resident daemon (`rein daemon`). The hosted control plane is not yet open — `rein login` against the default URL reports that in one sentence, `REINSTATE_HOP_URL` / `[hop] url` point the client elsewhere, and no pricing, billing, or sign-up ships. **OpenCode reaches T5** (encrypted sync, the first embedded-SQLite agent to sync) and **Kimi Code CLI reaches T2** (handoff source). See [Reinstate Hop](https://reinstate.dev/docs/hop) for the full command reference. This candidate also carries the interactive CLI experience introduced by an earlier, uncertified candidate, unchanged: bare `rein` opens a session switcher with a readiness verdict per row, a handoff studio, a setup wizard with `--link` / `--paste` pairing codes, and a `ctrl+k` command palette. Every `--json` document and non-TTY byte stream stays byte-identical to `v0.5.1`; `--plain` and `REINSTATE_NO_TUI` freeze the old output. OpenCode and Grok Build gain verified native resume, and OpenCode, Grok Build, and Qwen Code become handoff destinations alongside Claude Code and Codex. See [handoff](https://reinstate.dev/docs/handoff), [getting started](https://reinstate.dev/docs/getting-started), [CLI reference](https://reinstate.dev/docs/cli-reference), [Reinstate Hop](https://reinstate.dev/docs/hop), and the [roadmap](https://reinstate.dev/roadmap). --- Source: https://reinstate.dev/docs/features Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-05. --- # Reinstate CLI command reference > Use every current Reinstate command with its purpose, parameters, expected evidence, platform notes, failure modes, and safe recovery path. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 The `rein` and `reinstate` names run the same binary. This reference covers every command shipped by Reinstate `v0.5.1`, including what it does, what success looks like, the flags it accepts, platform-specific behavior, common failures, and the available recovery path. > **Current scope:** Reinstate supports configless local discovery for Claude Code, Codex, Gemini CLI, and OpenCode; native resume/fork remains same-vendor and mutation-capable only for Claude Code and Codex. Structured handoff continues the same task in a *new* Claude Code or Codex session. MCP servers, skills, plugins, marketplaces, and universal configuration remain roadmap work. ## Prerequisites - Install and verify `v0.5.1` before relying on this syntax. - Run `rein init` before commands that need configuration or remote storage. - Close the selected Claude Code or Codex process before a mutating pull or `conflicts resolve --keep-remote`. - Use synthetic sessions while learning the workflow. Never paste a real transcript, storage credential, or passphrase into an issue or agent chat. ## Global command rules Use `rein` in daily work or replace it with `reinstate` in any example. The result is identical. ```sh rein --help rein COMMAND --help rein COMMAND --json ``` `--help` prints local syntax without changing state. The global `--json` flag requests machine-readable output where the selected command supports it; command-local `--json` flags are equivalent. JSON field names are an integration surface, but Reinstate remains pre-1.0 and may change before v1.0. Set `REINSTATE_HOME` to an absolute path only when you deliberately need an isolated Reinstate home. macOS and WSL2 otherwise use `~/.reinstate`; native Windows uses `%USERPROFILE%\.reinstate`. Native Windows and WSL2 must keep separate homes and device identities. Interactive encryption uses a hidden prompt. Non-interactive automation must open a secret file or pipe and set `REINSTATE_PASSPHRASE_FD` to that descriptor number. Reinstate rejects ordinary passphrase environment values and secret CLI flags. The explicit non-interactive storage provider may read `REINSTATE_S3_ACCESS_KEY_ID` and `REINSTATE_S3_SECRET_ACCESS_KEY`, but those values must never be committed or logged. ## Exit codes | Code | Meaning | Operator response | | --- | --- | --- | | `0` | Success | Continue only after checking the command-specific evidence. | | `1` | Unexpected runtime failure | Preserve redacted output and inspect logs; do not repeat a mutation blindly. | | `2` | Usage or invalid arguments | Correct the documented flag, value, or positional argument. | | `3` | Missing or invalid configuration | Run `rein setup check` and repair configuration before retrying. | | `4` | Authentication or storage failure | Verify endpoint, bucket, credential scope, network, and passphrase privately. | | `5` | Agent, layout, or platform compatibility failure | Stop writes and use a documented supported version or target. | | `6` | Sync conflict | Inspect the conflict and select an explicit resolution strategy. | | `7` | Safety refusal | Satisfy the reported safety condition; do not bypass it without understanding the state change. | There is no general `rein undo` command. Read-only commands need no rollback; `init --force` and mutating restores create local backups where documented; remote snapshots are immutable and require an explicit later retention process rather than silent deletion. ## Inspect the installed release ### `rein version` **Purpose:** identify the installed Reinstate version and build metadata without reading configuration, storage, or session content. ```sh rein version rein version --json ``` **Expected result:** human output contains the version string. JSON output contains `version`, `commit`, and `date`; the public Reinstate installer must report `0.4.0`. **Parameters:** `--json` selects machine-readable output. The command accepts no session, agent, storage, or path arguments. **Platform differences:** syntax and fields are the same on macOS, native Windows PowerShell, Linux, and WSL2. The reported artifact architecture must still match the current environment. **Failure modes:** a missing command indicates a PATH or installation problem. An unexpected version indicates the wrong binary or an incomplete replacement. **Undo or recovery:** this command is read-only. Reinstall the pinned release through the checksum-verifying installer; do not rename an unrelated binary to make the version check pass. ### `rein doctor` **Purpose:** produce redacted diagnostics; `--self-test` additionally exercises synthetic encryption, in-memory sync, adapter export/restore, and atomic local writes without reading a real transcript or contacting configured storage. ```sh rein doctor rein doctor --self-test --json ``` **Expected result:** the report identifies the redacted Reinstate home, configuration state, keyring and adapter checks, and a pass/fail summary. A self-test reports a synthetic local round trip without exposing credentials. **Parameters:** `--self-test` enables the synthetic round trip; `--json` returns structured diagnostics. **Platform differences:** keyring and agent locations are platform-native. Native Windows, WSL2, and macOS may therefore report different adapter or keyring evidence while using the same command syntax. **Failure modes:** missing configuration, unavailable keyring, unsupported agent layout, local filesystem failure, crypto failure, or synthetic export/restore mismatch produces a failed check and a nonzero exit. This command does not prove remote storage access; use `init`, `status`, or a scoped dry-run for that evidence. Treat redaction failure as a security defect. **Undo or recovery:** diagnostics are read-only apart from temporary, cleaned-up local self-test files. Correct the named prerequisite and rerun; never publish unredacted private paths or infrastructure identifiers. ### `rein setup check` **Purpose:** run the read-only preflight that decides whether the current device, configuration, storage, keyring, and installed agents are ready. ```sh rein setup check rein setup check --json ``` **Expected result:** every installed agent has an explicit `SUPPORTED`, `UNTESTED`, `UNSUPPORTED`, or `NOT_INSTALLED` state. The summary cannot claim success while an installed agent is blocked. **Parameters:** `--json` emits machine-readable checks. No mutation flags exist. **Platform differences:** compatibility evidence is specific to each native agent layout and operating-system target. WSL2 and native Windows count as different environments. **Failure modes:** missing config uses exit `3`; an installed untested or unsupported layout uses exit `5`; storage and keyring failures retain their documented nonzero category. **Undo or recovery:** the command is read-only. Install a supported agent version, repair the reported configuration, or stop the transfer. Do not change a compatibility result merely to clear the gate. ## Find and continue local sessions These commands refresh a private derived index at `$REINSTATE_HOME/cache/session-index-v1.sqlite`. They do not require `rein init`, storage credentials, an encryption passphrase, keyring access, or a network backend. ### `rein sessions` **Purpose:** list local session metadata across supported read adapters. ```sh rein sessions rein sessions --agent claude --json ``` **Expected result:** each row has a composite `agent:native-id` reference, timestamp, capability flags, and bounded metadata. Use `--agent claude|codex|gemini|opencode|grok|kimi|qwen|pi|cursor|copilot|cline|all`; scripts should use `--json`. ### `rein search` **Purpose:** find indexed sessions with literal, case-insensitive AND terms. ```sh rein search "webhook retry" --agent codex --limit 20 rein search SESSION_ID --json ``` **Expected result:** only matching metadata rows appear. Optional `--project`, `--branch`, and `--file` filters narrow the result. Search never prints the matching transcript passage. ### `rein inspect` **Purpose:** inspect one exact composite reference without dumping a transcript. ```sh rein inspect claude:SESSION_ID rein inspect opencode:SESSION_ID --json ``` **Expected result:** identity, workspace/project metadata, counts, capabilities, source fingerprint, and at most a 160-code-point user preview. ### `rein last` **Purpose:** select and launch the newest resumable Claude Code or Codex session. ```sh rein last --agent claude --dry-run rein last --project my-project ``` **Expected result:** `--dry-run` prints the exact executable, argument array, and working directory without launching a vendor. Remove it only after review. ### `rein resume` and `rein fork` **Purpose:** launch a same-vendor native continuation or native fork. ```sh rein resume codex:SESSION_ID --dry-run rein fork claude:SESSION_ID --dry-run ``` **Expected result:** the dry-run plan uses the recorded workspace and exact vendor-native ID. Claude Code and Codex may launch after review. Gemini CLI and OpenCode are read-only and refuse either action with compatibility exit `5`. JSON without `--dry-run` is refused because native child output is not a JSON response owned by Reinstate. ### Bare `rein` / `reinstate` **Purpose:** open the numbered session switcher on an interactive TTY. ```sh rein ``` Filter with `/text`, inspect with `i NUMBER`, resume with `NUMBER`, fork with `f NUMBER`, and quit with `q`. A non-TTY bare invocation exits promptly with a `rein sessions --json` hint. ## Configure a device ### `rein init` **Purpose:** create one device identity, storage profile, credential reference, project path map, `config.toml`, and `state.json` after probing storage. ```sh rein init \ --project github.com/acme/app=/absolute/path/to/app ``` To join an existing profile: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project github.com/acme/app=/different/absolute/path ``` **Expected result:** output reports `config.toml + state.json`, a UUID `profile_id`, and a `credential_ref` without printing the credential. Additional-device setup must read the existing encrypted remote manifest before saving configuration. **Parameters:** `--endpoint URL`, `--bucket NAME`, `--region REGION`, `--prefix PREFIX`, repeatable `--project ID=/absolute/local/path`, `--profile-id UUID`, `--yes`, and `--force`. `--yes` requires all storage coordinates plus the documented environment credential provider. `--force` backs up and replaces an initialized home; it is not a merge. **Platform differences:** project values must use the current platform’s absolute path form, such as `/Users/me/app`, `C:\Users\me\app`, or `/mnt/c/Users/me/app`. Store secrets in the native OS keyring during interactive setup. **Failure modes:** invalid or relative path maps use exit `2`; an existing home without `--force` uses exit `7`; inaccessible storage, partial credentials, keyring failure, or a missing established manifest uses exit `4`. **Undo or recovery:** before first successful use, remove only the exact new Reinstate home after preserving anything you need. For reinitialization, use the timestamped backup printed by `--force`. Do not delete an established remote manifest or invent a replacement profile ID. ## Discover and compare sessions ### `rein list` **Purpose:** discover local vendor-native sessions through the selected adapter, without uploading or restoring anything. ```sh rein list --agent all rein list --agent claude --json rein list --agent codex --json ``` **Expected result:** output lists redacted session metadata, including the agent and session identifier needed by scoped push or pull commands. An empty list is valid only when no matching local session exists. **Parameters:** `--agent claude|codex|all` defaults to `all`; `--json` emits structured metadata. **Platform differences:** adapters inspect each vendor’s native platform-specific session location. The same session may map to a different local project path on another device. **Failure modes:** invalid agent values use exit `2`; missing config, private path errors, or unsupported layouts fail with their corresponding config or compatibility exit rather than pretending the list is empty. **Undo or recovery:** the command is read-only. Correct the agent filter or compatibility issue and rerun. Never copy a session ID from a different vendor into the selected adapter command. ### `rein status` **Purpose:** decrypt and compare the remote manifest with local tracked state. ```sh rein status rein status --json ``` **Expected result:** output reports the remote manifest revision and session-level local/remote relationship without exposing transcript content. **Parameters:** `--json` selects structured output. Reinstate status has no agent or session filter. **Platform differences:** syntax is identical, but the hidden passphrase input and local keyring are platform-native. **Failure modes:** missing config, wrong passphrase, absent required remote profile, inaccessible bucket, or tampered ciphertext fails closed. Status does not create an empty replacement manifest. **Undo or recovery:** status is read-only. Recheck profile coordinates and enter the original passphrase privately. Do not reinitialize the device to silence an unexpected remote state. ### `rein diff` **Purpose:** show pending local-versus-remote metadata for all sessions or one selected agent/session; it does not print transcript content. ```sh rein diff --json rein diff --agent claude --session SESSION_ID ``` **Expected result:** output describes pending change metadata for the selected scope and provides the basis for a dry-run. **Parameters:** optional `--agent AGENT`, optional `--session SESSION_ID`, and `--json`. Pair an exact session ID with its owning adapter. **Platform differences:** command syntax is shared; structural source paths are compared through the configured canonical project mapping. **Failure modes:** bad filters use exit `2`; missing configuration, wrong passphrase, unavailable storage, or unsupported layout fails with a nonzero exit. **Undo or recovery:** diff is read-only. Repair the reported prerequisite, then run the relevant push or pull with `--dry-run` before mutation. ## Transfer a selected session ### `rein push` **Purpose:** export selected vendor-native session state, replace recognized structural roots with canonical project tokens, encrypt locally, and upload an immutable snapshot plus an encrypted manifest update. ```sh rein push --agent claude --session SESSION_ID --dry-run rein push --agent claude --session SESSION_ID ``` **Expected result:** dry-run prints `would push ... dry_run=true` and writes no remote snapshot. A successful mutation reports `pushed`, a snapshot count, and the unchanged-session skip count. **Parameters:** `--agent AGENT`, either `--session SESSION_ID` or `--all`, `--dry-run`, and `--json`. Prefer an exact session. `--all` is an explicit bulk-selection decision, not a shortcut for uncertainty. **Platform differences:** the adapter reads the current OS’s native session layout, while project mappings normalize only recognized structural paths. Plain Linux is not a certified Phase 1 resume target. **Failure modes:** missing or ambiguous selection, unsupported agent layout, wrong passphrase, credential/storage failure, manifest race, or failed encryption stops the operation. Credentials and auth files are hard-excluded. **Undo or recovery:** dry-run needs no undo. Snapshots are immutable and Reinstate has no general delete or undo command. If a push was unintended, stop further sync, preserve the evidence, and apply the documented bucket-retention process only after identifying the exact profile objects. ### `rein pull` **Purpose:** download and decrypt selected remote session state, map canonical project tokens to this device, validate the restore plan, back up an existing target, and restore atomically. ```sh rein pull --agent codex --session SESSION_ID --dry-run rein pull --agent codex --session SESSION_ID ``` **Expected result:** dry-run reports `would pull ... dry_run=true` and does not write agent state. A successful restore reports `pulled ... dry_run=false`; the same vendor can then discover and resume the session. **Parameters:** `--agent AGENT`, either `--session SESSION_ID` or `--all`, `--dry-run`, and `--json`. The session must belong to the selected agent. **Platform differences:** destination mappings expand canonical project IDs to the current OS’s configured absolute roots. Native Windows and WSL2 require their own homes and mappings. **Failure modes:** missing remote session, wrong passphrase, checksum or identity mismatch, unmapped project, unsupported layout, active agent process, or local divergence blocks mutation. Divergence records an explicit conflict instead of silently overwriting. **Undo or recovery:** dry-run needs no undo. For a completed replacement, close the agent and restore the timestamped local backup only after reviewing the current target. For a conflict, use the conflict commands below; do not manually delete the record first. ## Inspect and resolve conflicts ### `rein conflicts list` **Purpose:** list unresolved local conflict records for the configured home. ```sh rein conflicts list rein conflicts list --json ``` **Expected result:** output lists conflict IDs and redacted metadata, or an explicit empty set when configuration is valid and no records exist. **Parameters:** `--json` emits structured records. **Platform differences:** none in syntax; recorded local paths and agent locations remain device-specific private metadata. **Failure modes:** missing or invalid configuration fails instead of appearing as an empty conflict list. **Undo or recovery:** listing is read-only. Use `conflicts show` before any resolution. ### `rein conflicts show` **Purpose:** inspect one recorded conflict and the local/remote revision metadata needed for an informed resolution. ```sh rein conflicts show CONFLICT_ID ``` **Expected result:** output identifies the conflict, agent, session, project, and competing revisions without printing the full transcript. **Parameters:** the required positional `CONFLICT_ID` comes from `rein conflicts list`. The global `--json` request applies where supported. **Platform differences:** none in syntax. **Failure modes:** a missing positional ID or unknown record uses exit `2`; invalid configuration retains the config failure rather than fabricating a record. **Undo or recovery:** show is read-only. Copy the exact ID and choose one resolution strategy only after reviewing both sides. ### `rein conflicts resolve` **Purpose:** resolve one conflict explicitly by keeping local state, replacing with remote state, or restoring the remote state under a second session identity. ```sh rein conflicts resolve CONFLICT_ID --keep-local rein conflicts resolve CONFLICT_ID --keep-remote rein conflicts resolve CONFLICT_ID --keep-both ``` **Expected result:** the selected strategy completes, the resolution is audited, and the conflict is no longer unresolved. `--keep-remote` verifies the restored native session before completion. **Parameters:** one required `CONFLICT_ID` and exactly one of `--keep-local`, `--keep-remote`, or `--keep-both`. **Platform differences:** remote restoration applies the destination device’s project mapping. Close the native agent process on every platform before `--keep-remote`; `--keep-both` creates a separate local identity. **Failure modes:** no strategy, multiple strategies, an unknown ID, changed remote state, failed verification, or an active matching agent refuses the operation. **Undo or recovery:** there is no general conflict undo. Keep-remote replacement uses the restore backup path; keep-both preserves the original; keep-local updates remote continuity from the local side. Preserve the audit record and backup before attempting any manual reversal. ## Generate shell completion ### `rein completion` **Purpose:** print a completion script for one supported shell. ```sh rein completion bash rein completion zsh rein completion fish rein completion powershell ``` **Expected result:** stdout contains a shell script. Redirect or source it only according to that shell’s trusted completion-file conventions. **Parameters:** exactly one positional shell name: `bash|zsh|fish|powershell`. **Platform differences:** choose the active shell, not merely the operating system. PowerShell completion can be used on Windows; zsh is typical on macOS; WSL2 follows its Linux shell. **Failure modes:** a missing or unsupported shell name uses exit `2`. A generated script can be correct while a shell startup path or execution policy prevents it from loading. **Undo or recovery:** generation alone is read-only. If you installed the output, remove only the exact completion line or file you added, then start a new shell. ## Structured handoff ### `rein handoff` **Purpose:** continue the same task in a **new** Claude Code or Codex session. This is not native resume. ```sh rein handoff claude:SESSION_ID --to codex --dry-run --json rein handoff --last --from claude --to codex rein handoff list --json rein resume claude:SESSION_ID --with codex --dry-run ``` **Expected result:** `--dry-run --json` reports `mode` `structured handoff`. A live destination first-reply restates five acknowledgement bullets before mutation. **Parameters:** `--to claude|codex` is required. `--policy` is `checkpoint|balanced|full` (default `balanced`). Repeat `--allow-warning ID` for each current warning. `--json` requires `--dry-run` or `--no-launch`. **Platform differences:** dest launch needs a real TTY. Windows dest argv uses a one-line `projection.md` pointer when the briefing contains CR/LF. **Failure modes:** exit `5` for wrong repo or untested dest; exit `7` for unacknowledged warnings or non-TTY dest launch. **Undo or recovery:** `--dry-run` writes nothing durable. `--no-launch` stores local capsules only. Kill a dest TUI with the vendor quit command; do not reuse a dest session id that is already indexed. See [structured handoff](https://reinstate.dev/docs/handoff) and [features](https://reinstate.dev/docs/features). ## Expected evidence A complete same-vendor transfer record contains: - `rein version --json` showing `0.4.0`; - a passing or truthfully blocked `rein setup check --json` on each device; - the exact agent and `SESSION_ID` selected by `rein list`; - successful push and pull dry-runs before each mutation; - one encrypted remote snapshot and encrypted manifest revision without plaintext transcript objects; - the restored session visible to the same vendor’s native list and resume command; and - redacted output that contains no passphrase, storage secret, auth token, or transcript text. These checks prove the observed workflow only. They do not certify every platform or close the project’s physical two-device release gates. ## Failure paths - Start with [troubleshooting](https://reinstate.dev/docs/troubleshooting) for exact diagnostic, evidence, recovery, escalation, and verification contracts. - Use [configuration troubleshooting](https://reinstate.dev/docs/configuration) for profile, project-map, keyring, and additional-device errors. - Use [storage troubleshooting](https://reinstate.dev/docs/storage) for endpoint, bucket, policy, retention, or remote-manifest failures. - Check [compatibility](https://reinstate.dev/compatibility) before interpreting an untested agent layout as a transient sync problem. Do not retry a mutating command repeatedly after an exit `4`, `5`, `6`, or `7` without resolving the reported condition. ## Security boundaries Reinstate encrypts supported session snapshots and manifests before upload, but command output, shell history, private paths, storage coordinates, and local backups still require careful handling. Enter credentials and passphrases only through the documented private channels. Never weaken checksum, compatibility, active-process, conflict, or backup checks to obtain a green command. The current CLI performs same-vendor native resume and explicit structured handoff into a new destination session. It does not reconstruct vendor history, mirror complete vendor configuration trees, sync credentials, operate agents, or provide a Reinstate-owned plugin runtime. ## Related pages - [Install the verified CLI](https://reinstate.dev/docs/installation) - [Configure profiles and project paths](https://reinstate.dev/docs/configuration) - [Push one selected session](https://reinstate.dev/docs/sync-a-session) - [Restore and resume one selected session](https://reinstate.dev/docs/restore-a-session) - [Continue a task with structured handoff](https://reinstate.dev/docs/handoff) - [Review current limitations](https://reinstate.dev/docs/limitations) --- Source: https://reinstate.dev/docs/cli-reference Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # Push one coding-agent session > Select, dry-run, encrypt, and push one supported Claude Code or Codex session to user-owned S3-compatible storage with Reinstate. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 List local sessions, choose one explicit Claude Code or Codex session ID, inspect `push --dry-run`, and then repeat the same scoped command without `--dry-run`. Reinstate normalizes supported structural paths, encrypts the snapshot locally, uploads ciphertext, and conditionally advances the encrypted remote manifest. > **Current scope:** Reinstate pushes full immutable snapshots for supported same-vendor sessions. It does not continuously watch agent directories, synchronize Git state, or translate Claude Code sessions into Codex sessions. ## Prerequisites - Reinstate `v0.5.1` initialized on the source device. - A successful `rein setup check` with the selected adapter marked `SUPPORTED`. - An existing encrypted profile and reachable S3-compatible storage. - A configured canonical project mapping for the session’s repository. - The profile passphrase available for private entry. - One harmless Claude Code or Codex session that has finished writing. Commit or otherwise preserve the repository separately. Reinstate transfers the supported agent session artifact, not source files, dependencies, credentials, shell state, or running processes. ## Discover the exact session List metadata for the agent you intend to sync: ```sh rein list --agent claude --json rein list --agent codex --json ``` Choose the ID, agent, and canonical project deliberately. `list` reads local vendor metadata; it does not contact storage or print the transcript. Use Claude Code IDs only with `--agent claude` and Codex IDs only with `--agent codex`. Same-vendor identity is part of the snapshot contract. ## Inspect the push without mutation For Claude Code: ```sh rein push --agent claude --session SESSION_ID --dry-run --json ``` For Codex: ```sh rein push --agent codex --session SESSION_ID --dry-run --json ``` Wait for Reinstate’s hidden passphrase prompt before typing. The dry-run reads and authenticates the current remote manifest, checks the local revision, plans adapter export, builds and validates the portable artifact, and reports what would be uploaded. It does not publish a snapshot, advance the manifest, or update local sync state. Review these fields: - `dry_run` is `true`; - exactly one candidate snapshot is planned, unless the session is unchanged; - `skipped` reflects an already synchronized local/remote revision; - the selected agent and session match your intended scope; and - no compatibility, credential-exclusion, storage, or conflict error appears. ## Push the selected session Exit the selected agent normally so its file is not changing during export, then repeat the approved command without `--dry-run`: ```sh # Claude Code rein push --agent claude --session SESSION_ID --json # Codex rein push --agent codex --session SESSION_ID --json ``` The command exports one supported vendor-native session, replaces recognized structural project paths with portable tokens, hard-excludes known credential artifacts, encrypts the snapshot with age passphrase encryption, uploads the immutable `.age` object, and conditionally updates `manifest.age`. If the local and remote session already match recorded state, Reinstate skips the unchanged snapshot instead of creating a new revision. ## About `--all` `rein push --all` is available, but neither Reinstate nor a coding agent should select every discovered session on your behalf. `--all` can include large, old, irrelevant, or unexpectedly sensitive transcripts and increases transfer time under the current full-snapshot model. Prefer one agent and one session until you have reviewed the complete discovery set and deliberately accept its storage and disclosure scope. ## Verify remote state ```sh rein status --json rein diff --agent AGENT --session SESSION_ID --json ``` Replace `AGENT` with `claude` or `codex`. Both commands currently read the remote manifest and request the passphrase. They compare metadata; they do not print transcript content. ## Expected evidence - The approved dry-run reports one would-be snapshot and `dry_run=true`, or reports the selected session as unchanged. - The mutating command reports one pushed snapshot and `dry_run=false`. - `status` includes the `AGENT:SESSION_ID` remote key, snapshot ID, and remote revision. - A repeated push with no local changes reports the session as skipped. - Object storage contains an encrypted immutable snapshot and encrypted `manifest.age`; it never receives a plaintext session artifact. Do not decrypt or print a transcript merely to prove that upload succeeded. ## Failure paths - A conflict exit code `6` means the remote head changed or both sides diverged; follow [session-conflict troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-reinstate-create-a-session-conflict). - A slow large Codex rollout is subject to the [full-snapshot limitation](https://reinstate.dev/docs/troubleshooting#why-is-a-large-codex-session-slow-to-sync). - A missing remote manifest on an established device is a storage/profile failure, not permission to create an empty profile. Use [remote-manifest troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-reinstate-report-a-remote-profile-manifest-is-missing). - If the adapter is `UNTESTED` or `UNSUPPORTED`, stop at compatibility exit code `5`; Phase 1 has no unsafe write override. ## Security boundaries Known auth files, OAuth material, credential stores, tokens, caches, logs, and regenerable dependency trees are hard-excluded. A secret that an agent printed inside ordinary transcript text remains part of the selected encrypted snapshot. Reinstate does not semantically redact transcript prose. Never put a passphrase in a normal environment variable, argument, prompt transcript, or issue. Remote encryption reduces storage-provider exposure, but the local source, destination, passphrase, storage credentials, and transcript handling remain your responsibility. ## Related pages - [Restore the session on another device](https://reinstate.dev/docs/restore-a-session) - [Review storage behavior and object layout](https://reinstate.dev/docs/storage) - [Check supported agents and versions](https://reinstate.dev/compatibility) - [Follow the Claude Code outcome guide](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices) - [Follow the Codex outcome guide](https://reinstate.dev/guides/sync-codex-sessions-across-devices) --- Source: https://reinstate.dev/docs/sync-a-session Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Restore and resume one coding-agent session > Dry-run, safely restore, verify, and natively resume one encrypted Claude Code or Codex session on another configured device. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 On the destination device, inspect a session-scoped `pull --dry-run`, close the matching agent if an existing session will be replaced, run the approved pull, verify the restored ID with `rein list`, and resume through the same vendor’s native command. > **Current scope:** Claude Code sessions restore to Claude Code, and Codex sessions restore to Codex. Reinstate does not translate native transcripts, prepare the Git repository, install dependencies, copy agent credentials, or recreate the complete source-machine environment. ## Prerequisites - The same reviewed Reinstate version installed and initialized on the destination. - The source profile’s exact `profile_id`, storage bucket, prefix, and encryption passphrase. - The same canonical project ID mapped to this device’s real absolute path. - The selected agent installed in a `SUPPORTED` version and native layout. - The corresponding repository and required dependencies prepared separately. - The exact remote agent and session ID. Additional-device `init` must already have verified the existing encrypted manifest. Do not continue from an empty or newly invented replacement profile. ## Inspect available remote metadata ```sh rein setup check --json rein status --json rein diff --agent AGENT --session SESSION_ID --json ``` `status` and `diff` request the hidden encryption passphrase because they read the remote manifest. Confirm that the remote key uses the intended agent and session. Metadata does not prove that the repository checkout matches the source. The stable `v0.3.0` verified-resume report checks the local repository before native launch; it does not replace review of this remote restore plan. ## Dry-run the restore For Claude Code: ```sh rein pull --agent claude --session SESSION_ID --dry-run --json ``` For Codex: ```sh rein pull --agent codex --session SESSION_ID --dry-run --json ``` The dry-run fetches, authenticates, decrypts, and validates the selected artifact; checks adapter compatibility; expands known structural path tokens; and constructs the restore plan. It omits filesystem and state mutation. Review: - `dry_run` is `true`; - `pulled` is one; - the snapshot ID matches remote status; - every planned destination belongs to the destination agent’s native layout; - the destination uses this device’s project mapping, not the source path; and - the reported backup root belongs to this device’s Reinstate home. ## Close the agent before replacement A mutating pull refuses to replace an existing session while Claude Code or Codex may still be writing it. Save current work and exit every process for the selected agent normally. Do not force-kill a process during a session write. A dry-run and a restore of a genuinely new native session remain available because they do not overwrite an active existing target. Conflict `--keep-both` also restores a distinct identity, but use it only for a recorded conflict. ## Restore the selected snapshot Repeat the reviewed command without `--dry-run`: ```sh # Claude Code rein pull --agent claude --session SESSION_ID --json # Codex rein pull --agent codex --session SESSION_ID --json ``` Reinstate validates the full artifact before mutation. When the destination exists, it creates a timestamped private backup, writes a temporary sibling, syncs it, atomically replaces the target, verifies that the adapter rediscovers the exact restored session, and only then updates local state. If the local and remote revisions diverge, the pull records a conflict instead of silently choosing a winner. ## Verify and resume natively Claude Code: ```sh rein list --agent claude --json claude --resume SESSION_ID ``` Codex: ```sh rein list --agent codex --json codex resume SESSION_ID ``` For Claude Code, success requires discovery beneath the exact recomputed destination project directory key. Finding the same ID elsewhere under the Claude session tree is not equivalent. For Codex, Reinstate preserves the native date-partitioned rollout layout and expands the structural `session_meta.cwd` through the configured local project root. ## Resolve an explicit conflict Inspect conflict metadata without printing the transcript: ```sh rein conflicts list --json rein conflicts show CONFLICT_ID ``` Choose exactly one strategy: - `--keep-local` publishes the local branch on the current remote head; - `--keep-remote` backs up local state and restores the remote branch; or - `--keep-both` preserves local state and restores a vendor-safe fork with a distinct structural session ID. When uncertain, `--keep-both` preserves both native branches: ```sh rein conflicts resolve CONFLICT_ID --keep-both ``` The conflict record remains if resolution fails. Do not delete it simply to make the list appear clean. ## Expected evidence - The dry-run reports one validated plan, the correct destination, and `dry_run=true` without creating agent files. - The mutating pull reports one pulled snapshot and `dry_run=false`. - An existing target has one timestamped backup under the reported backup root. - `rein list --agent AGENT --json` rediscovers the exact restored or forked ID. - `claude --resume` or `codex resume` opens the session in the same vendor. - No transcript content is printed as part of verification. ## Failure paths - If the mutating pull reports an active process, use [active-agent troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-a-pull-fail-while-the-coding-agent-is-running). - If Claude cannot see a correctly pulled ID, use [Claude path-remapping troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-claude---resume-not-see-a-pulled-session). - If local and remote state diverged, follow [conflict troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-reinstate-create-a-session-conflict). - If authentication fails, do not test passphrases through shell arguments; use [passphrase troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-passphrase-verification-fail-on-a-second-device). ## Security boundaries Restores necessarily create plaintext session data on the trusted destination because the native agent must read it. Client-side encryption protects the remote artifact, not a compromised source or destination OS. Local backups are also plaintext vendor session files protected by owner-only filesystem permissions. Agent account credentials are never restored. Authenticate Claude Code or Codex independently on the destination. A restored transcript can contain secrets previously printed inside it; rotate exposed credentials and follow the [transcript-credential response](https://reinstate.dev/docs/troubleshooting#can-reinstate-upload-credentials-from-a-transcript). ## Related pages - [Push one selected session](https://reinstate.dev/docs/sync-a-session) - [Understand adapters and path mapping](https://reinstate.dev/docs/adapters) - [Review the backup and conflict architecture](https://reinstate.dev/docs/architecture) - [Check current compatibility](https://reinstate.dev/compatibility) - [Read all current limitations](https://reinstate.dev/docs/limitations) --- Source: https://reinstate.dev/docs/restore-a-session Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Structured handoff between Claude Code and Codex > Continue the same coding-agent task in a new Claude Code or Codex session with Reinstate structured handoff, without native resume or transcript translation. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Stable `v0.5.1` lets you continue the same task in a **new** Claude Code or Codex session. This is not native resume, not a transferred session, and not a lossless copy of the source transcript. ## Commands ```sh rein handoff --last --from claude --to codex --dry-run rein handoff claude:SESSION_ID --to codex rein handoff claude:SESSION_ID --to codex --no-launch rein handoff list --json rein handoff inspect HANDOFF_ID --json rein handoff export HANDOFF_ID --format markdown --out ./handoff.md rein resume claude:SESSION_ID --with codex --dry-run ``` `rein resume --with` is a structured handoff convenience alias. It still starts a new destination session. ## Directions in v0.5.1 | Source | Claude dest | Codex dest | | --- | --- | --- | | Claude Code | same-vendor native resume | structured handoff | | Codex CLI | structured handoff | same-vendor native resume | | Gemini CLI | structured handoff (source-only) | structured handoff (source-only) | | OpenCode | structured handoff (source-only) | structured handoff (source-only) | | Grok Build | structured handoff (source-only) | structured handoff (source-only) | | Kimi Code CLI | structured handoff (source-only) | structured handoff (source-only) | Gemini CLI, OpenCode, Grok Build, and Kimi Code CLI are not handoff destinations. ## First reply The destination’s first reply must restate five bullets before mutation: current goal and latest user request; critical constraints; changed files and test state; missing capabilities or uncertain evidence; proposed next action. ## Safety - `--dry-run` plans without launching. - `--allow-warning ID` acknowledges one exact warning. No wildcards. - Wrong Git repository: exit `5`. - Non-TTY dest launch: exit `7`. - Untested agent version: exit `5` unless `--allow-untested`. - Capsules stay under `$REINSTATE_HOME/handoffs/` and are excluded from sync. See the [feature map](https://reinstate.dev/docs/features), [CLI reference](https://reinstate.dev/docs/cli-reference), and [getting started](https://reinstate.dev/docs/getting-started). ## Prerequisites - Stable `v0.5.1` installed (`rein version --json`) - Apple Silicon macOS or native Windows x64 for certified dest-ack - A logged-in destination Claude Code or Codex CLI in the fail-closed range - The source session on this device; dest launch needs a real TTY ## Expected evidence - `--dry-run --json` reports `mode` `structured handoff` and a dest argv without CR/LF - Live dest first-reply restates the five bullets before mutation - `rein handoff list --json` keys are `mode` and `handoffs` - Marker files in the workspace are unchanged unless you later ask the dest to edit ## Failure paths | Symptom | Cause | Recovery | | --- | --- | --- | | Exit `5` | Wrong repo, untested agent, or unsupported dest | Use the source workspace; pin a supported Claude/Codex version | | Exit `7` | Unacknowledged warning or non-TTY dest launch | Pass each `--allow-warning ID`; run in a real terminal | | Dest theme/trust hang | Dest home not trusted | Keep dest `CLAUDE_CONFIG_DIR` / `CODEX_HOME`; do not copy oauth files | | No dest session file | Dest TUI never started | Launch from a local console, not a detached SSH PTY | See [troubleshooting](https://reinstate.dev/docs/troubleshooting). ## Security boundaries - Capsules are owner-only under `$REINSTATE_HOME/handoffs/` and excluded from sync - Known credentials stay excluded; session text can still contain secrets — review the projection - `--no-redact` is refused for Grok sources - Dest argv never includes `--dangerously-skip-permissions` ## Related pages - [Features and commands](https://reinstate.dev/docs/features) - [CLI reference](https://reinstate.dev/docs/cli-reference) - [Getting started](https://reinstate.dev/docs/getting-started) - [Limitations](https://reinstate.dev/docs/limitations) - [Troubleshooting](https://reinstate.dev/docs/troubleshooting) --- Source: https://reinstate.dev/docs/handoff Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # Configure storage for encrypted Reinstate sessions > Understand Reinstate - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** September 5, 2026 Reinstate `v0.5.1` stores encrypted manifests and immutable session snapshots in a private S3-compatible bucket you control. Configure the service endpoint, region, bucket, and profile prefix separately; interactive `rein init` stores the access-key pair in the operating-system keyring, not in `config.toml`. > **Current scope:** Cloudflare R2 is the recommended Phase 1 backend, and Amazon S3 is documented. Other S3-compatible services must implement the conditional request and object operations Reinstate uses; compatibility is not implied by an “S3-compatible” label alone. ## Prerequisites - A private bucket in an S3-compatible object-storage service. - A service endpoint and region appropriate for that bucket. - A dedicated, non-root credential limited to the intended bucket and profile prefix. - Permission to list the prefix and get, put, head, and delete its objects. - A retention, versioning, and incident-deletion policy you understand. - Reinstate installed on a trusted local device. Keep public website hosting and anonymous object access disabled. Reinstate does not require a Reinstate-hosted account or bucket. [Reinstate Hop](https://reinstate.dev/docs/hop), the optional hosted tier built into the client, is not yet open; bring-your-own storage as described on this page remains the only way to sync today. ## Storage configuration fields `rein init` writes non-secret storage coordinates similar to: ```toml [storage] type = "s3" endpoint = "https://" region = "auto" bucket = "reinstate" prefix = "profiles/" credential_ref = "reinstate//s3" ``` Use `region = "auto"` for R2. Use the bucket’s actual AWS Region and matching regional endpoint for Amazon S3. The endpoint is the service URL only; do not append the bucket name. `bucket` and `prefix` are independent fields. The default prefix is `profiles/`. Every device in a profile must use the same profile ID, bucket, and prefix. Credentials can differ by device as long as each credential authorizes the same required object operations. ## Required object operations | Reinstate behavior | S3 operation or permission | | --- | --- | | List the profile tree | `ListObjectsV2` / `s3:ListBucket` scoped by prefix | | Read a manifest or snapshot | `GetObject`, `HeadObject` / `s3:GetObject` | | Create a probe, snapshot, or manifest | `PutObject` / `s3:PutObject` | | Remove the initialization probe | `DeleteObject` / `s3:DeleteObject` | | Protect manifest updates | Conditional `If-Match` and `If-None-Match` writes | Grant only the intended bucket and `profiles//` object prefix. Provider-side deny policies, object retention, or Object Lock can prevent probe cleanup or later operations even when an allow policy looks correct. ## Remote object layout The current backend uses: ```text /manifest.age /snapshots/.age /probes/ ``` `manifest.age` is an encrypted index of session heads and profile revision. Snapshots are immutable, UUID-addressed encrypted artifacts. Probe objects contain a small test value and are deleted during successful initialization. The provider can observe bucket access, object timestamps, sizes, fixed layout segments, and opaque IDs. It should not receive plaintext transcripts, manifest JSON, or the encryption passphrase. ## Initialize and verify storage Interactive setup is the preferred path: ```sh rein init \ --project github.com/acme/app=/absolute/local/path ``` Enter the endpoint, bucket, access-key ID, and secret key in the private prompts. Initialization creates and deletes a probe before writing local configuration. On an additional device, pass the first device’s profile UUID: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project github.com/acme/app=/this/device/path ``` Reinstate requires that additional-device initialization can find the existing encrypted `manifest.age`; it does not silently create a new empty remote profile. After initialization: ```sh rein doctor --self-test rein status --json rein push --agent AGENT --session SESSION_ID --dry-run --json ``` The doctor self-test uses synthetic data. The scoped dry-run authenticates and validates the real profile without publishing a snapshot. ## Retention, backup, and deletion Phase 1 has no Reinstate retention or garbage-collection command. Full snapshots remain until removed by an explicit provider-side policy or operator action. Deleting a snapshot referenced by the encrypted manifest can make that session unrestorable; deleting `manifest.age` breaks an established profile. Treat provider lifecycle rules, versioning, replication, Object Lock, and backup as external controls. Review how they interact with required probe deletion and with incident-response deletion before relying on them. Reinstate’s local pre-restore backups are separate plaintext files on the destination and are not a substitute for a remote storage recovery plan. ## Expected evidence - `init` completes both probe creation and cleanup before saving config. - `config.toml` contains only storage coordinates and a `credential_ref`, not an access key or secret key. - A first successful push creates encrypted `manifest.age` and one opaque `.age` snapshot under the configured prefix. - An additional device verifies the existing manifest and `status` reports the same remote revision. - Inspecting stored bytes does not reveal plaintext transcript or manifest JSON. ## Failure paths - Use [remote-manifest troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-reinstate-report-a-remote-profile-manifest-is-missing) when an established profile appears empty or missing. - A probe put failure usually means endpoint, region, bucket, credential, or `PutObject` scope is wrong; a cleanup failure can indicate missing `DeleteObject` or retention policy. - A signature mismatch often indicates the wrong regional endpoint, region, credential pair, or system clock; preserve redacted output. - Do not bypass a missing manifest by uploading an empty file or changing the profile ID. ## Security boundaries Remote payloads are encrypted locally with age passphrase encryption before upload and transferred over TLS. The passphrase is never sent to the storage provider or stored by Reinstate. Interactive storage credentials are stored in the native OS keyring; non-interactive environment credentials are not persisted by Reinstate but remain exposed to the invoking process environment. Encryption does not hide access timing, object size, bucket identity, endpoint, or every key segment. It also does not protect a compromised local machine or a secret already embedded in transcript text. Apply least privilege, provider-side access logging, credential rotation, and an independent backup policy. ## Related pages - [Configure a Reinstate profile](https://reinstate.dev/docs/configuration) - [Use Cloudflare R2 step by step](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage) - [Use Amazon S3 step by step](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage) - [Review encryption and credential boundaries](https://reinstate.dev/docs/security-model) - [Understand the sync architecture](https://reinstate.dev/docs/architecture) - [Reinstate Hop: sign-in, devices, and the locker](https://reinstate.dev/docs/hop) --- Source: https://reinstate.dev/docs/storage Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Claude Code and Codex session adapters > Learn how Reinstate adapters discover, normalize, and restore Claude Code and Codex sessions without translating native transcripts across vendors. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate’s adapters index vendor-native Claude Code, Codex, Gemini CLI, and OpenCode sessions without translating sessions across agents. Claude Code and Codex additionally support encrypted export/restore and native same-vendor resume/fork; Gemini CLI and OpenCode remain read-only. ## Current v0.5.1 scope | Adapter | Local index | Native resume/fork | Encrypted sync | Structured handoff | | --- | --- | --- | --- | --- | | Claude Code | Full | Same-vendor | Supported | Destination and source | | OpenAI Codex CLI | Full | Same-vendor | Supported | Destination and source | | Gemini CLI | Read-only | No | No | Source-only | | OpenCode | Read-only | No | No | Source-only | Stable `v0.5.1` passed dual-platform tagged-artifact acceptance on Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 packages are preview and unverified; check the [compatibility page](https://reinstate.dev/compatibility) before relying on them. ## Later adapters | Adapter | Status | | --- | --- | | Cursor CLI | T1 Discover (read-only) | | Cline | T1 Discover (read-only) | | GitHub Copilot CLI | T1 Discover (read-only) | | Qwen Code | T1 Discover (read-only) | | Pi | T1 Discover (read-only) | | Kimi Code CLI | T1 Discover (read-only) | | Grok Build | Exploring | Configuration support is capability-specific and planned separately. Session support never implies support for MCP servers, skills, hooks, plugins, marketplaces, or settings. See [Universal agent configuration](https://reinstate.dev/docs/universal-configuration). ## How does the Claude Code adapter remap a project? Claude Code stores a project beneath a directory key derived from that device’s absolute project path. Reinstate records the configured canonical project ID in a snapshot and recomputes Claude’s directory key from the destination device’s `local_root`. Reinstate validates the exact planned destination after restore. Finding the same session ID elsewhere in `~/.claude/projects` does not count as success. ## How does the Codex adapter remap a project? Codex stores the source working directory in each rollout’s structural `session_meta.cwd`. When project mappings are configured, Reinstate resolves that directory to the canonical project ID during discovery and excludes rollouts outside mapped roots. Export normalizes the resolved source root to `${REPO:}`. Restore expands that token through the destination device’s `local_root` while preserving Codex’s native date-partitioned rollout layout. Phase 1 transfers full snapshots; append-aware delta transfer remains roadmap work. ## What do adapters exclude? Sync adapters hard-exclude authentication material, credentials, tokens, caches, logs, and regenerable dependencies. The local index additionally excludes assistant reasoning/messages, tool output, environment dumps, and auth stores while retaining bounded user-authored search text and metadata. Future configuration profiles may carry secret references, but never raw secret values. Tests use deterministic synthetic fixtures that are scanned for secrets. ## Contributing an adapter See [CONTRIBUTING.md](https://github.com/HarjjotSinghh/reinstate/blob/main/CONTRIBUTING.md#adapter-contributions). Minimum pull-request requirements: 1. Implementation + fixtures 2. Defensive parsing (skip unknown fields/types) 3. Explicit credential excludes 4. Docs row in this matrix + README 5. No network in unit tests ## Adapter request template Use [Adapter request](https://github.com/HarjjotSinghh/reinstate/issues/new?template=adapter_request.yml) and include: - Agent name + version - Session file locations - Sample **redacted** session header (no secrets) - How resume works --- Source: https://reinstate.dev/docs/adapters Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # How Reinstate syncs coding-agent sessions > Understand Reinstate - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate uses per-agent adapters, structural path remapping, client-side age encryption, immutable snapshots, and an encrypted remote manifest to move vendor-native sessions without becoming a coding harness. ```plaintext ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Claude Code │ │ Codex │ │ Future agents│ ... │ ~/.claude │ │ ~/.codex │ │ (roadmap) │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────────────────────┐ │ Agent Adapters (per tool) │ │ locate · parse · exclude secrets · project IDs │ └──────────────────────┬───────────────────────────┘ ▼ ┌──────────────────────────────────────────────────┐ │ Normalizer │ │ structural path tokens · project IDs │ │ credential hard-excludes │ └──────────────────────┬───────────────────────────┘ ▼ ┌──────────────────────────────────────────────────┐ │ Encryption (age / scrypt passphrase recipient) │ │ client-side only — remote never sees plaintext │ └──────────────────────┬───────────────────────────┘ ▼ ┌──────────────────────────────────────────────────┐ │ Sync Engine │ │ immutable snapshots · encrypted JSON manifest │ │ conflict detection · atomic restore + backup │ └──────────────────────┬───────────────────────────┘ ▼ ┌──────────────────────────────────────────────────┐ │ Backends: R2 · S3-compatible (Phase 1) │ └──────────────────────────────────────────────────┘ ``` ![Reinstate architecture from agent state watchers through path normalization, client-side encryption, sync, and restore](https://reinstate.dev/brand/05_architecture.svg) *Reinstate keeps vendor-native sessions intact while adapters, structural path remapping, client-side encryption, and immutable snapshots make same-vendor resume portable across devices.* ## Design principles 1. **Local-first** — agents remain the sole executors of sessions; Reinstate relocates files, it does not re-interpret or re-run them. 2. **Zero-knowledge remote** — ciphertext on object storage, apart from `keyring.v1.json`, which is plaintext by design, holds no usable key, and names the account and its enrolled devices. 3. **Native resume is same-vendor** — restore puts bytes where `claude --resume` / `codex resume` already know how to read them. 4. **Cross-agent handoffs are explicit** — never silently translated. `rein handoff` starts a new destination session. translate native transcripts between vendors. 5. **Fail-safe conflicts** — never overwrite; fork and surface. 6. **Adapter isolation** — format churn in one agent cannot break others. 7. **Normalize configuration intent** — later configuration adapters render a canonical desired-state profile into verified native harness formats. 8. **Secrets stay local** — profiles contain references, never raw API keys, OAuth tokens, cookies, or vendor credential stores. ## Pipeline stages ### 1\. Adapters Each adapter knows: | Concern | Example (Claude Code) | | --- | --- | | Root path | `~/.claude/projects/` | | Session format | Append-only JSONL | | Project key | Munged absolute path directory name | | Resume entry | `claude --resume [id]` | | Exclude globs | plugins, caches, credentials | Adapters implement a small Go interface under `internal/adapter/`. ### Configuration adapters (roadmap) Session and configuration support are separate. Later configuration adapters will import, diff, and render supported MCP servers, skills/instructions, hooks/loops, plugins, marketplaces, and safe settings: ```text native config ↔ configuration adapter ↔ Reinstate desired state ↕ encrypted sync another device ``` They must preserve unrelated settings, report unsupported/lossy mappings, preview and back up changes, write atomically, and fail closed on unverified schemas. See [Universal agent configuration](https://reinstate.dev/docs/universal-configuration). ### 2\. Path normalizer (`internal/pathmap`) The make-or-break feature for Windows ↔ macOS dual setups: - Store the released portable tokens `${HOME}` and `${REPO:}`. - Keep the lower-level `${WORK:}` primitive explicitly unwired until configuration, adapter integration, and compatibility tests ship. - On **push**: rewrite recognized structural path fields → tokens - On **pull**: rewrite tokens → this machine’s absolute paths - Maintain a **canonical project ID** (git remote + name, or user alias) mapped to per-device roots so munged slugs / hashes recompute correctly - Do not rewrite arbitrary prose, prompts, tool output, or unknown fields ### 3\. Encryption (`internal/crypto`) - Default: [age](https://github.com/FiloSottile/age) passphrase encryption - Enter the same passphrase on every device; no keyfile is copied or stored - File modes: `0600` for secrets, `0700` for config dirs ### 4\. Sync engine (`internal/sync`) - Versioned local sync state stored as atomic JSON - Immutable, UUID-addressed encrypted snapshots - Encrypted remote JSON manifest with conditional ETag updates - Streamed full-snapshot transfer with authenticated metadata, size, and SHA-256 validation - Full snapshots in Phase 1; chunking and append-aware deltas are roadmap work - `status` and `diff` currently require access to the remote manifest ### 5\. Restore path 1. Pull ciphertext → decrypt 2. Path-rewrite into local layout 3. If target exists: copy to `~/.reinstate/backups//` 4. Atomic write (temp + rename) 5. Refuse or warn if agent process holds the file open (liveness check) ## What is explicitly not synced See the [security model](https://reinstate.dev/docs/security-model). Defaults exclude: - `auth.json`, OAuth/credential stores - Plugin caches / `node_modules` / venvs - Machine-local logs - User-defined globs Future configuration sync carries non-secret declarations and secret references, never vendor auth stores or whole tool directories. ## Why not CRDTs / real-time collab? Dominant pattern is **sequential** multi-device use (desktop by day, laptop by night). Last-writer-wins with conflict *detection* and safe forks matches reality without tripling complexity. ## Tech stack | Layer | Choice | Why | | --- | --- | --- | | Language | Go | Single static binary, cross-compile, proven by peers | | Crypto | age | Passphrase UX + auditability | | Storage | S3-compatible first | R2 free tier; rclone-style backends later | | Local state | Versioned JSON | Small, inspectable, atomically replaced | | Remote index | Encrypted JSON manifest | Conditional updates and conflict detection | ## Related diagrams | Asset | Description | | --- | --- | | [01\_landscape.svg](https://reinstate.dev/brand/01_landscape.svg) | Agent scope vs state portability | | [02\_demand\_timeline.svg](https://reinstate.dev/brand/02_demand_timeline.svg) | Demand signals on vendor trackers | | [03\_traction.svg](https://reinstate.dev/brand/03_traction.svg) | GitHub traction landscape | | [04\_market.svg](https://reinstate.dev/brand/04_market.svg) | Market context | | [05\_architecture.svg](https://reinstate.dev/brand/05_architecture.svg) | MVP architecture | ## Package layout ```plaintext cmd/reinstate/ # CLI entrypoint (install as reinstate + rein) internal/ adapter/ # per-agent adapters config/ # local config + path_map crypto/ # age encryption pathmap/ # portable path rewriting sync/ # manifest, push/pull, conflicts backend/ # R2/S3-compatible docs/ # human docs testdata/ # golden fixtures (per adapter) ``` --- Source: https://reinstate.dev/docs/architecture Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # Reinstate security and encryption model > See how Reinstate encrypts session data before upload, excludes credential files, stores storage keys, handles conflicts, and defines its threat boundaries. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate encrypts every remote manifest and session snapshot locally before upload, hard-excludes known credential files, stores S3 credentials in the native OS keyring, and never stores the encryption passphrase. Coding-agent transcripts remain **high-sensitivity material** because they can contain source code, architecture decisions, and secrets that a tool printed to the terminal. Encryption reduces remote-storage risk; it does not make an unsafe transcript harmless. ## Threat model (summary) | Threat | Mitigation | | --- | --- | | Cloud storage provider reads your sessions | Client-side encryption; provider only sees ciphertext | | Network eavesdropper | TLS to backend + encrypted payloads | | Accidental sync of API keys / OAuth | Hard denylist of credential paths (default on) | | Overwriting good local history | Timestamped backups + conflict forks | | Weak passphrase | age scrypt recipient + long-passphrase guidance; user responsibility | | Compromised local machine | **Out of scope** (OS-level compromise) | | Malicious release artifact | Checksums / supply-chain process (see SECURITY.md) | ## Trust boundaries ```plaintext [Agent CLI] --files--> [Reinstate CLI] --ciphertext--> [Your bucket] ^ | | +-- keys never leave machine +-- only process that "understands" sessions ``` - Reinstate does **not** call vendor agent APIs - Reinstate does **not** require Anthropic/OpenAI/Google account credentials - Remote backends never receive your passphrase or age identity in plaintext form beyond ciphertext + opaque object keys ## Encryption | Property | Default | | --- | --- | | Algorithm | age passphrase encryption (`scrypt` recipient) | | Key UX | Enter the same passphrase privately on each device; it is not stored | | At rest (remote) | Ciphertext only | | At rest (local secrets) | Passphrase is not stored; storage keys use the OS keyring | | In transit | HTTPS/TLS to object storage | ### Passphrase guidance - Prefer a long passphrase (diceware / password manager) - Never commit passphrases to git or shell history - Interactive commands read it from a hidden terminal prompt - Automation must use `REINSTATE_PASSPHRASE_FD` pointing at a pre-opened descriptor; ordinary environment variables and CLI flags are rejected - Losing the passphrase = losing ability to decrypt remote data (by design) ## What is never synced (defaults) | Path / pattern | Reason | | --- | --- | | `**/auth.json` | API keys / OAuth | | `**/.credentials.json` | Tokens | | Claude OAuth / keychain material | Credentials | | Plugin `node_modules`, `.venv` | Huge, non-portable, regenerable | | User-configured globs | Local policy | Credentials and authentication files cannot be enabled for sync. Planned universal configuration profiles may contain secret references, never secret values. ## Future configuration reconciliation Applying skills, plugins, hooks/loops, marketplaces, and MCP declarations adds supply-chain and overwrite risk. Configuration adapters must manage known fields only, preview and back up writes, report lossy mappings, pin executable sources/versions, show permissions and commands, and require explicit consent. Reinstate may track auth status and coordinate official login flows. Token reuse is allowed only where the protocol, provider, or harness explicitly supports it; copying private credential stores is never the fallback. ## Secrets inside transcripts Agents sometimes echo `.env` values or tokens into session logs. Reinstate: 1. Encrypts everything it does sync (reduces blast radius of cloud leaks) 2. Syncs explicitly discovered Claude Code or Codex session artifacts in Phase 1 3. Plans optional transcript-redaction tooling for a later phase **You remain responsible** for not pasting production secrets into agent chats. ## Restore safety 1. `--dry-run` available on pull 2. Existing files backed up under `~/.reinstate/backups//` 3. Writes via temp file + atomic rename 4. Conflicts create `.conflict` forks — never silent last-writer-wins without notice 5. A mutating pull refuses to replace a session while the matching agent is active ## Reporting issues Follow [SECURITY.md](https://github.com/HarjjotSinghh/reinstate/blob/main/SECURITY.md). Private disclosure only for vulnerabilities. ## Independent review We welcome security review PRs and responsible disclosure. A formal audit is not claimed for pre-1.0 software — treat early versions accordingly. ## Non-affiliation Reinstate is independent of Anthropic, OpenAI, Google, xAI, and other agent vendors. Using those tools’ local files does not imply partnership. --- Source: https://reinstate.dev/docs/security-model Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # Troubleshoot Reinstate session sync > Fix Reinstate installation, compatibility, session selection, mapping, manifest, passphrase, conflict, credential, performance, and active-agent errors safely. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Use the smallest possible command while diagnosing a sync problem: one agent and one explicit session ID. Do not paste passphrases, storage credentials, session text, raw configuration, or unredacted absolute paths into an issue. Reinstate `v0.5.1` is a stable pre-1.0 release; Claude Code and Codex resume only with the same vendor. Local search shipped in `v0.2.0`. ## Why is the `rein` binary not found after installation? ### Symptom The shell reports that `rein` or `reinstate` is not recognized, not found, or not a command. Calling the binary by its full installation path may still work. ### Likely cause The installation directory is absent from the current shell’s `PATH`, the shell has not reloaded its environment, or the binary was not installed or built successfully. `rein` and `reinstate` are names for the same CLI. ### Affected agent(s) Claude Code and Codex. This is a Reinstate installation problem and occurs before an agent adapter can run. ### Affected OS macOS, native Windows, and WSL2. PATH syntax and executable discovery differ between POSIX shells and PowerShell. ### Diagnostic commands Run the block for your shell. These commands do not inspect session content. ```bash command -v rein command -v reinstate echo "$PATH" ./bin/rein version --json ``` ```powershell Get-Command rein -ErrorAction SilentlyContinue Get-Command reinstate -ErrorAction SilentlyContinue $env:Path -split [IO.Path]::PathSeparator ``` The relative `./bin/rein` command in the POSIX block is only for a source checkout where `make build` has already created the local binary. If that path is missing, the source build did not complete. ### Corrective action Reopen the terminal after installation. If the binary exists, add its installation directory—not the executable itself—to the user `PATH`, then open a new shell. If it does not exist, repeat the documented installation or run `make build` from the repository root and resolve any build error before changing `PATH`. Do not download an unverified binary from a third-party mirror. Use the [getting-started installation steps](https://reinstate.dev/docs/getting-started) and verify the release checksum. ### Expected recovery evidence Both `rein version --json` and `reinstate version --json` exit successfully and report the same Reinstate version. A new shell resolves `rein` without an absolute path. Continue with `rein setup check`; do not treat command discovery alone as proof that storage or agent compatibility is ready. ### When to file an issue File an issue when the verified official installer reports success but a new shell cannot resolve either binary, or when the two binary names report different versions. Include the installer version, OS and architecture, shell name, and a redacted installation directory. Do not include the complete `PATH` if it contains private directory names. ## Why does `claude --resume` not see a pulled session? ### Symptom `rein pull --agent claude --session SESSION_ID` reports a successful restore, but `claude --resume SESSION_ID` cannot find that exact session or the session does not appear for the destination project. ### Likely cause The destination project path was not mapped to the exact Claude project directory key expected on this device. A snapshot made before Reinstate may also lack the safely mappable Claude project identity required by the current adapter. ### Affected agent(s) Claude Code only. Codex uses a different native, date-partitioned rollout layout and must be diagnosed with its own adapter and resume command. ### Affected OS macOS, native Windows, and WSL2, especially transfers where source and destination use different absolute project roots. Treat native Windows and WSL2 as separate Reinstate devices. ### Diagnostic commands Replace `SESSION_ID` with the exact non-secret session identifier. The dry-run must name a destination on this device, not the source device’s directory key. ```bash rein version --json rein setup check --json rein list --agent claude --json rein pull --agent claude --session SESSION_ID --dry-run --json ``` Review the configured mapping locally. Use the same canonical project ID on both devices, but give it each device’s real absolute `local_root`. Do not paste the raw roots into a public issue. ### Corrective action Require Reinstate `0.4.0` on both test devices. Correct the destination mapping for the existing canonical project ID, close Claude Code, and repeat the scoped dry-run. If Reinstate rejects a legacy snapshot whose Claude project identity cannot be mapped, install Reinstate on the source device and push that one session again to an intentionally fresh Reinstate profile. Do not manually move the session file into a guessed Claude directory. After the dry-run shows the correct destination, run the same pull without `--dry-run`, then resume through Claude Code: ```bash rein pull --agent claude --session SESSION_ID rein list --agent claude --json claude --resume SESSION_ID ``` ### Expected recovery evidence The dry-run reports `dry_run=true`, one planned snapshot, and a destination under this device’s Claude project directory. The mutating pull reports one pulled snapshot. `rein list --agent claude --json` discovers the same ID at the planned destination, and `claude --resume SESSION_ID` opens that native Claude Code session. ### When to file an issue File an issue when Reinstate or newer plans and writes the correct destination, `rein list` discovers the exact restored ID, and Claude Code in the tested compatibility range still cannot resume it. Include both OS versions, Reinstate and Claude Code versions, the transfer direction, the redacted dry-run plan, and redacted project-path shapes. ## Why does passphrase verification fail on a second device? ### Symptom `rein status`, `push`, or `pull` reaches storage but rejects the passphrase or cannot decrypt the existing remote `manifest.age`. ### Likely cause The destination did not receive the exact passphrase used to encrypt the profile’s remote manifest. Typing before Reinstate displays its hidden prompt can send the secret to the shell instead of the Reinstate process. There is no passphrase recovery or alternate key that can decrypt existing ciphertext. ### Affected agent(s) Claude Code and Codex. The encrypted manifest is profile-wide, so verification fails before a selected agent session can be read. ### Affected OS macOS, native Windows, and WSL2. Shell and terminal behavior can differ, but the passphrase bytes must be identical on every device. ### Diagnostic commands First confirm local setup without entering a passphrase. Then invoke `status` and wait for Reinstate’s visible hidden prompt before typing. ```bash rein version --json rein setup check --json rein status --json ``` Do not use `echo`, a command-line flag, ordinary environment variables, clipboard logs, or chat messages to test the passphrase. ### Corrective action Rerun the command and enter the exact original passphrase only after the hidden prompt appears. Check keyboard layout, Caps Lock, and password-manager entry selection. If the process already exited, start it again rather than typing into the shell. If the original passphrase is irretrievably lost, preserve the ciphertext in case the passphrase is recovered. Creating a separate fresh profile or storage prefix deliberately abandons access to the old encrypted profile; it does not recover or re-key it. ### Expected recovery evidence `rein status --json` exits successfully and returns the remote revision and expected session keys. A scoped push or pull dry-run authenticates the manifest and reports a plan without modifying local or remote state. ### When to file an issue File an issue only when the same saved passphrase successfully decrypts the same profile on one device but fails on another device with matching profile, bucket, prefix, and current Reinstate version. Include redacted error output, OS and terminal names, and version output. Never include the passphrase, its length, hints, hashes, or password-manager screenshots. ## Why does Reinstate report a remote profile manifest is missing? ### Symptom Reinstate can contact the configured storage service but reports that the remote profile manifest is missing instead of showing the first device’s sessions. ### Likely cause The additional device is looking at a different `profile_id`, bucket, or `storage.prefix`, or the bucket name was incorrectly appended to the service endpoint. The existing profile’s encrypted `manifest.age` therefore is not at the coordinates Reinstate was given. ### Affected agent(s) Claude Code and Codex. The remote manifest indexes both supported agent types for one Reinstate profile. ### Affected OS macOS, native Windows, and WSL2. This is a profile/storage-coordinate issue, not an agent-specific filesystem layout issue. ### Diagnostic commands Run redacted diagnostics and a status check. `status` will request the passphrase if it finds the encrypted manifest. ```bash rein version --json rein setup check --json rein doctor --json rein status --json ``` Compare the non-secret `profile_id`, bucket, prefix, region, and service endpoint locally with the values used on the first device. Do not post credentials, signed URLs, or a complete unredacted configuration. ### Corrective action Correct the inputs so the additional device uses the exact existing `profile_id`, bucket, and prefix. Keep the bucket name separate from the service endpoint. Then rerun `init --profile-id` in a disposable or intentionally reinitialized Reinstate home. Do not create an empty `manifest.age` and do not silently substitute a new profile ID. If you intentionally reuse an initialized home, review it first; `rein init --force` backs up the existing config and state together before replacing them. ### Expected recovery evidence Initialization verifies the existing encrypted remote manifest before saving the additional device. With the correct passphrase, `rein status --json` reports the same remote revision and selected session keys visible from the first device. No empty replacement manifest is created. ### When to file an issue File an issue when an object listing confirms `manifest.age` exists at the exact configured prefix, the profile coordinates match, storage credentials can read that object, and Reinstate still reports it missing. Include redacted diagnostics, provider type, endpoint host, region, and object-key shape—not credentials, signed requests, bucket policies, or session payloads. ## Why does Reinstate create a session conflict? ### Symptom A push or pull exits with sync-conflict code `6`, and `rein conflicts list` shows local and remote revisions for the same Claude Code or Codex session. ### Likely cause Both devices changed the same session after their last common revision, or the local session changed outside the revision Reinstate recorded. Reinstate records this divergence instead of silently overwriting either side. ### Affected agent(s) Claude Code and Codex, independently. Conflict records are scoped to an agent and session ID; they do not translate or merge conversations across vendors. ### Affected OS macOS, native Windows, and WSL2. Conflicts can occur on one device or across any supported device pair. ### Diagnostic commands The conflict commands show metadata, not a semantic transcript merge. Replace `CONFLICT_ID` with the ID printed by the list command. ```bash rein conflicts list --json rein conflicts show CONFLICT_ID rein status --json rein diff --json ``` ### Corrective action Inspect the metadata and choose exactly one explicit strategy: - `--keep-local` retains the local branch and advances the remote head with it. - `--keep-remote` restores the remote branch over the selected local session; close that agent first. - `--keep-both` preserves the local branch and restores the remote revision as a distinct native session. When uncertain, prefer `--keep-both`, inspect both native sessions, and decide later: ```bash rein conflicts resolve CONFLICT_ID --keep-both ``` Do not edit the conflict record or session files by hand while resolving it. ### Expected recovery evidence The resolve command prints `resolved CONFLICT_ID via keep-both` (or the chosen strategy). The ID disappears from `rein conflicts list`. For `--keep-both`, `rein list --agent claude` or `rein list --agent codex` shows the preserved local session and a distinct restored session; each remains resumable only by its own vendor. ### When to file an issue File an issue if a conflict appears without local/remote divergence, if a documented resolution deletes the branch it should preserve, if `--keep-both` reuses the same session identity, or if the conflict remains after a successful resolution. Include redacted `list`/`show` metadata, strategy, versions, OS, agent, and reproducible steps. Do not attach session files. ## Why is a large Codex session slow to sync? ### Symptom A selected Codex session takes substantially longer to plan, encrypt, upload, download, or restore than a smaller rollout, especially when using `--all`. ### Likely cause Phase 1 transfers full immutable session snapshots. Append-aware delta transfer and retention controls remain roadmap work, so a large Codex rollout requires processing and transferring the complete selected artifact. ### Affected agent(s) Codex. Large Claude Code sessions can also take longer, but this entry addresses Codex’s rollout artifacts and date-partitioned native layout. ### Affected OS macOS, native Windows, and WSL2. Runtime varies with session size, CPU, disk, network, and the configured S3-compatible storage service. ### Diagnostic commands Use an explicit Codex session ID. Compare the scoped plan with `--all` without running two mutating transfers. ```bash rein version --json rein list --agent codex --json rein push --agent codex --session SESSION_ID --dry-run --json rein status --json ``` Do not print or attach the rollout to measure it. Record only non-secret metadata such as approximate byte size, elapsed time, agent version, and whether the delay occurred before or during network transfer. ### Corrective action Push or pull one explicit session instead of `--all`. Let the active Codex process finish writing, exit Codex before a mutating restore of an existing session, and avoid repeatedly transferring an unchanged snapshot. Keep independent backups. Do not assume roadmap delta or retention settings already exist in the current CLI. ### Expected recovery evidence The scoped dry-run reports exactly one planned snapshot. The mutating command eventually reports one pushed or pulled snapshot, and `rein status --json` shows its remote session key and snapshot revision. A repeat push without changes reports the snapshot as unchanged/skipped rather than uploading a new revision. ### When to file an issue File an issue if a scoped transfer never completes, crashes, exhausts expected resources, corrupts the restored rollout, or uploads an unchanged session again. Include approximate size and timing, transfer direction, storage provider type, OS, Codex and Reinstate versions, and redacted output. A large snapshot being slower than a small one is not by itself evidence of a defect. ## Can Reinstate upload credentials from a transcript? ### Symptom A secret, token, or credential value was pasted into or printed inside a coding agent conversation, and that session may already have been pushed. ### Likely cause Adapters hard-exclude known credential files, authentication artifacts, tokens, caches, and logs. They cannot determine the semantic meaning of every line in a selected transcript. A secret embedded in session text is therefore part of the encrypted session payload. ### Affected agent(s) Claude Code and Codex. This boundary applies to any supported transcript that contains sensitive text. ### Affected OS macOS, native Windows, and WSL2. Client-side encryption limits what the storage provider can read, but it does not make a compromised credential valid to keep using. ### Diagnostic commands Use metadata-only commands. Do not print, search, paste, or attach the transcript while investigating. ```bash rein list --agent claude --json rein list --agent codex --json rein status --json rein push --agent AGENT --session SESSION_ID --dry-run --json ``` Replace `AGENT` with `claude` or `codex`. The dry-run confirms selection and destination metadata; it does not certify that transcript prose contains no secret. ### Corrective action Revoke or rotate the exposed credential immediately. Treat every destination that received the session as sensitive. Remove or quarantine affected remote snapshot objects according to your storage provider’s retention/versioning policy, then create a clean agent session that does not contain the value. Push only the explicitly reviewed clean session. Reinstate has no current transcript-redaction command and cannot prove semantic secret removal. Do not weaken the adapter exclusions or attempt to synchronize vendor authentication files. ### Expected recovery evidence The exposed credential is invalidated at its issuer. Storage-provider evidence shows the affected object versions were removed, quarantined, or made inaccessible according to your incident policy. A subsequent scoped dry-run selects only the intended clean session. Reinstate output alone is not evidence that a transcript is secret-free. ### When to file an issue File a private security report—not a public issue—if Reinstate includes a documented hard-excluded credential artifact or uploads plaintext to remote storage. A secret included as ordinary transcript text is a documented boundary, but report any suspected exclusion bypass. Provide synthetic reproduction data and redacted metadata only; never send the real credential or session. ## Why does a pull fail while the coding agent is running? ### Symptom A mutating pull or `conflicts resolve --keep-remote` exits with safety-refusal code `7` because Claude Code or Codex may still be writing the destination session. ### Likely cause An active process for the selected agent owns or may mutate an existing local session. Reinstate refuses the overwrite to prevent a race, partial write, or loss of newer local history. A dry-run and a restore of a genuinely new session do not overwrite an active existing target. ### Affected agent(s) Claude Code and Codex. The refusal is evaluated for the agent whose existing session would be replaced. ### Affected OS macOS, native Windows, and WSL2. Process-discovery details vary by platform. ### Diagnostic commands The Reinstate dry-run remains safe. The process commands are observational and may also match helper processes; review their output rather than terminating them blindly. ```bash rein pull --agent AGENT --session SESSION_ID --dry-run --json pgrep -fl 'claude|codex' ``` ```powershell rein pull --agent AGENT --session SESSION_ID --dry-run --json Get-Process claude,codex -ErrorAction SilentlyContinue ``` Replace `AGENT` with `claude` or `codex`. ### Corrective action Save any work, exit every process for the selected agent normally, and verify that it has stopped. Repeat the scoped dry-run, review the planned destination and backup root, then run the same pull without `--dry-run`. Do not force-kill an agent while it may be writing a session. For a recorded conflict, `--keep-both` remains available because it restores a distinct session identity. Use it only after inspecting the conflict metadata; it is not a substitute for closing the agent before overwriting the existing target. ### Expected recovery evidence No selected-agent process remains. The scoped mutating pull exits successfully, reports one pulled snapshot, creates the planned timestamped backup when an existing target is replaced, and `rein list --agent AGENT --json` discovers the restored session. The same vendor’s native resume command opens it. ### When to file an issue File an issue when the safety refusal persists after a normal agent exit and process inspection shows no matching process, or when a mutating pull proceeds while the selected agent is demonstrably active. Include OS, agent and Reinstate versions, redacted process names, exit code, dry-run plan, and steps. Do not attach process command lines if they contain private paths or arguments. ## Why does push report `no matching local sessions found`? ### Symptom A scoped `rein push --agent AGENT --session SESSION_ID` command exits with usage code `2` and reports the exact message `no matching local sessions found`. No session snapshot is encrypted or uploaded. ### Likely cause The selected agent and session ID did not match any session that the local adapter discovered. Common causes are a mistyped or case-mismatched ID, selecting `claude` for a Codex session or `codex` for a Claude Code session, running on the wrong source device, or choosing a session that the installed agent has not created in its recognized native layout. An agent that is not installed also has no local sessions to select. ### Affected agent(s) Claude Code and Codex. Session IDs are vendor-native identifiers, so an ID listed by one adapter cannot be pushed through the other adapter. ### Affected OS macOS, native Windows, and WSL2. Discovery reads the selected agent’s native session root on the current device; it does not search another device or translate native Windows and WSL2 paths. ### Diagnostic commands Replace `AGENT` with exactly `claude` or `codex`. First confirm compatibility, then copy the exact session ID from the matching list result. The final command is a dry-run and performs no upload. ```bash rein version --json rein setup check --json rein list --agent AGENT --json rein push --agent AGENT --session SESSION_ID --dry-run --json ``` Do not switch to `--all` to make the error disappear. That broadens the selection and can include unrelated sessions. Do not publish the list output without redacting titles and absolute paths. ### Corrective action Run the list command on the device that contains the native session. Select the correct vendor and copy one exact discovered ID without editing its case or punctuation. If the intended session is absent, confirm that the same vendor can open it locally and that `rein setup check --json` reports that adapter as `SUPPORTED`. Resolve a compatibility refusal before trying to push. Repeat the scoped dry-run with the corrected values. Only after it identifies the intended session should you run the same push without `--dry-run`: ```bash rein push --agent AGENT --session SESSION_ID ``` Do not rename, relocate, or manufacture a vendor session file to force discovery. ### Expected recovery evidence `rein list --agent AGENT --json` contains the selected native session ID. The scoped dry-run exits successfully with `dry_run` set to `true` and either plans one snapshot or reports that the one selected session is unchanged. A mutating push then reports one pushed snapshot, or one unchanged skip, without selecting any other session. ### When to file an issue File an issue when the exact ID appears in `rein list --agent AGENT --json`, the same Reinstate binary and home are used, the adapter is `SUPPORTED`, and the immediately following scoped push still reports `no matching local sessions found`. Include Reinstate, agent, OS, and architecture versions; the selected agent; redacted list metadata; the exact exit code; and reproducible commands. Do not attach the session file or its transcript. ## Why does pull report `remote session not found`? ### Symptom A scoped `rein pull --agent AGENT --session SESSION_ID` command can read and decrypt the remote manifest but exits with usage code `2` and reports the exact message `remote session not found`. No session is restored. ### Likely cause The agent and session ID do not match an entry in the fetched remote profile manifest. The ID may be mistyped, paired with the wrong vendor, or never successfully pushed. The destination may instead be configured for a different existing profile, bucket, or prefix. A completely missing remote manifest is a different storage/profile error and uses exit code `4`. ### Affected agent(s) Claude Code and Codex. The remote key combines the native agent name and session ID, so matching only the ID while selecting the wrong vendor is not sufficient. ### Affected OS macOS, native Windows, and WSL2. This selection error can occur for any source and destination pair; path remapping happens only after Reinstate finds the selected remote entry. ### Diagnostic commands Run the first block on the destination. `status` reads metadata from the configured encrypted manifest; it does not print transcript content. ```bash rein version --json rein setup check --json rein status --json rein diff --agent AGENT --session SESSION_ID --json ``` If the expected `AGENT:SESSION_ID` key is absent, run this scoped block on the source device: ```bash rein list --agent AGENT --json rein push --agent AGENT --session SESSION_ID --dry-run --json rein push --agent AGENT --session SESSION_ID --json rein status --json ``` Do not use `pull --all` as a discovery command. Compare the non-secret profile ID, bucket, prefix, and endpoint locally, and redact remote keys, project IDs, snapshot IDs, and paths before sharing output. ### Corrective action If `status` contains the intended session under the other vendor, use that vendor only if it is also the vendor that created the session; Reinstate does not translate transcripts. If the key is absent, verify that both devices use the intended existing remote profile. Then push that one exact, locally listed session from the source and confirm that the source’s `status` output contains the `AGENT:SESSION_ID` key. On the destination, refresh `status` and repeat the exact scoped pull as a dry-run: ```bash rein pull --agent AGENT --session SESSION_ID --dry-run --json ``` Proceed without `--dry-run` only when the plan names one expected destination. Do not create an empty manifest, change to a new profile, or broaden the pull unless that is an explicit separate decision. ### Expected recovery evidence Both devices report the same remote manifest revision, and `rein status --json` includes the exact `AGENT:SESSION_ID` key and its snapshot metadata. The destination dry-run exits successfully with `pulled` equal to `1`, `dry_run` set to `true`, and one plan for the selected agent and session. The later mutating pull reports one pulled snapshot and the same vendor’s native resume command can open it. ### When to file an issue File an issue when `rein status --json` on the same device and profile contains the exact `AGENT:SESSION_ID` key, but an immediately following pull for that same agent and ID returns `remote session not found`. Include redacted status and dry-run output, the manifest revision shape, profile ID shape, transfer direction, versions, OS, and exit code. Never include the passphrase, storage credentials, signed URLs, snapshot contents, or a raw configuration file. ## Why does `rein setup check` exit with compatibility code `5`? ### Symptom `rein setup check` exits with code `5`. Human output marks a device or installed-agent check as failed. JSON output can report `layout/version untested; writes blocked`, `unsupported layout/version`, or a device refusal, and its summary does not claim that all checks passed. ### Likely cause An installed Claude Code or Codex version or native layout is outside the release’s verified compatibility evidence, or the detected device is explicitly unsupported. `UNTESTED` means Reinstate recognizes enough of the layout to report it but lacks release evidence for safe writes; `UNSUPPORTED` means the known layout or environment must fail closed. WSL1, for example, is refused in favor of native Windows or WSL2. ### Affected agent(s) Claude Code and Codex. The report identifies each adapter separately as `SUPPORTED`, `UNTESTED`, `UNSUPPORTED`, or `NOT_INSTALLED`. `NOT_INSTALLED` is informational by itself and does not cause compatibility exit `5`. ### Affected OS macOS, native Windows, WSL2, and explicitly refused environments such as WSL1. Current source compatibility evidence is narrower than the full release-gate matrix, so a successful synthetic check must not be presented as completed physical certification for every OS and architecture. ### Diagnostic commands These commands are read-only. Keep the full JSON report locally so you can identify whether code `5` belongs to `device`, `agent.claude`, or `agent.codex`. ```bash rein version --json rein setup check --json rein doctor --json claude --version codex --version ``` Run only the vendor version command that is installed. Do not post the unredacted `home` value from diagnostic output or any vendor authentication state. ### Corrective action Stop before push or pull; Phase 1 has no public unsafe compatibility override. Check the [current compatibility matrix](https://reinstate.dev/compatibility) for the exact Reinstate release, agent version range, OS, and architecture. If the installed agent version is outside the documented range, use a documented supported stable version when your environment and organizational policy permit, or wait for a Reinstate release that adds evidence for the newer layout. Use native Windows or WSL2 instead of WSL1. Do not edit version files, copy session trees into a recognized-looking directory, patch the adapter state, or claim an untested release is supported merely to clear the preflight. ### Expected recovery evidence `rein setup check --json` reports the intended installed adapter as `SUPPORTED`, with its corresponding `agent.AGENT` check marked `ok`. The device check is also `ok`, and compatibility code `5` is no longer returned. If another independent check such as missing configuration still fails, its own status and exit code remain visible rather than being mistaken for a compatibility success. ### When to file an issue File a compatibility issue when a version and platform explicitly listed as supported still produce code `5`, or when a previously passing supported layout becomes `UNTESTED` or `UNSUPPORTED`. Include Reinstate and exact agent versions, OS and architecture, the failing check name and message, redacted `setup check --json` output, installation method, and minimal reproduction. Use synthetic data if session discovery is required. Do not attach real sessions, credentials, passphrases, full home paths, or authentication files. ## Still stuck? - Review the [FAQ](https://reinstate.dev/docs/faq) and [security model](https://reinstate.dev/docs/security-model). - Follow the repository’s [support policy](https://github.com/HarjjotSinghh/reinstate/blob/main/SUPPORT.md). - Use [GitHub Issues](https://github.com/HarjjotSinghh/reinstate/issues) for reproducible non-security defects. - Use the private [security policy](https://github.com/HarjjotSinghh/reinstate/security/policy) for suspected credential-exclusion, plaintext-upload, or other security failures. --- Source: https://reinstate.dev/docs/troubleshooting Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Reinstate frequently asked questions > Get direct answers about Reinstate - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate answers common continuity questions with one present-scope rule: supported Claude Code and Codex sessions resume in the same vendor. Structured handoff continues the same task in a *new* Claude Code or Codex session. Cross-agent transcript translation and universal configuration remain later roadmap work. ## What is Reinstate? Reinstate is an open-source continuity layer for coding-agent work. Phase 1 implements encrypted, bring-your-own-storage sync for same-vendor Claude Code and Codex sessions. Phase 2 adds configless local indexing, literal search, metadata inspection, a TTY switcher, and same-vendor native resume/fork. Stable `v0.3.0` adds verified resume after dual-platform tagged-artifact acceptance PASS. Stable `v0.4.0` added explicit structured handoff into a new Claude Code or Codex session. Stable `v0.5.1` adds universal agent coverage: a catalog of eighteen agents, session discovery for eleven, and structured handoff from five. Cross-harness configuration remains a later phase. See [What is Reinstate?](https://reinstate.dev/about/reinstate) for current product facts, non-goals, roadmap boundaries, and maintainer information. ## What is a coding-agent session? A coding-agent session is the vendor-native record of an ongoing agent task, including its session identifier, conversation events, tool activity, working directory, and enough tool-specific state for that same agent to resume it. Reinstate preserves supported native session artifacts; it does not convert a Claude Code transcript into a Codex rollout or vice versa. See [adapter internals](https://reinstate.dev/docs/adapters). ## Is Reinstate free and open source? Yes. Reinstate is available under the Apache-2.0 license and the CLI does not require a Reinstate account. You provide your own S3-compatible storage and are responsible for any storage-provider charges. See the [open-source project page](https://reinstate.dev/open-source) for the repository, license, governance, security policy, and contribution paths. ## What is `rein` vs `reinstate`? **Same tool.** | Name | Role | | --- | --- | | **Reinstate** | Product / brand / docs / repo | | **`reinstate`** | Full CLI binary name | | **`rein`** | Short alias (preferred day-to-day) | ```bash rein version reinstate version # identical behavior ``` Config and data live under `~/.reinstate/` either way. ## Why not just use git? Git stores source history; it does not store the complete vendor-native coding-agent session. Reinstate handles session context while Git remains the source of truth for commits, branches, and repository collaboration. See [Reinstate compared with Git](https://reinstate.dev/docs/comparison) for the distinct roles of source history and coding-agent session continuity. ## Why not copy the session files manually? Manual copying can work for a narrow same-machine experiment, but it does not provide Reinstate’s canonical project identity, structural macOS ↔ Windows path remapping, client-side encryption, credential exclusions, immutable snapshots, conflict checks, or atomic restore backup. Reinstate remains same-vendor: those safeguards do not translate one agent’s transcript into another format. See [the architecture](https://reinstate.dev/docs/architecture). ## Can I restore a session without copying the whole repository? Yes. Reinstate transfers supported session artifacts, not the repository itself. The destination still needs an appropriate checkout of the source repository, branch, and dependencies through Git or the developer’s normal workflow. Map that local checkout to the same canonical project ID before restoring the session. See [installation and sync](https://reinstate.dev/docs/getting-started). ## Will this resume a Claude session inside Codex? **Native resume:** no — same-vendor only. Stable `v0.5.1` structured handoff starts a new destination session with a visible, lossy projection. It does not translate native history. ## Do I need two computers? No. Multi-device sync is the first release wedge, while Phase 2 local index/search/resume helps developers manage fragmented sessions and agents on one computer without a remote-storage dependency. ## Is Reinstate a cloud IDE or coding-agent harness? No. Claude Code, Codex, and other coding agents execute the work. Reinstate finds, verifies, restores, hands off, and syncs continuity state around those tools; it does not provide an editor, terminal emulator, or agent scheduler. ## Is Reinstate a remote desktop or live terminal mirror? No. Remote desktop streams or controls another machine’s live environment. Reinstate transfers supported encrypted session state into the destination agent’s native local layout so work can continue on that device. It does not stream a screen, terminal, process, or active agent. Review the [work-and-personal-computer use case](https://reinstate.dev/use-cases/work-and-personal-computers). ## Is Reinstate a general backup tool? No. Reinstate creates encrypted, immutable snapshots of supported coding-agent session artifacts, but it is not a whole-computer, repository, credential, or general file backup system. Keep independent backups and use Git for source history. The [security model](https://reinstate.dev/security) explains what is deliberately excluded. ## Will Reinstate configure the same MCP server in every harness? **That is planned after Phase 1.** The target is to define an MCP server once, preview the native changes, and apply it across Claude Code, Codex, and future verified adapters. The model also covers skills/instructions, hooks/loops, plugins, marketplaces, and safe settings. See [Universal agent configuration](https://reinstate.dev/docs/universal-configuration). ## Will MCP authentication also carry across tools and devices? Reinstate should report authentication state and coordinate supported official login flows. Raw API keys, OAuth tokens, cookies, and vendor credential stores will not be synced. Safe reuse is possible only where the protocol, provider, or harness explicitly supports it; otherwise a target may still require its own login. ## Is my data sent to Reinstate servers? No. The open-source CLI sends ciphertext to the S3-compatible bucket you configure, such as Cloudflare R2 or Amazon S3. Reinstate does not operate a required storage service. ## What if I lose my passphrase? You cannot decrypt remote data. That is intentional (zero-knowledge). Keep the passphrase in a password manager. ## Does this work offline? Session files remain local. Phase 2 `sessions`, `search`, and `inspect` work offline without sync configuration. The `status`, `diff`, `push`, and `pull` commands still read the remote manifest and need access to your storage backend. ## Does Reinstate support Windows and macOS? Windows ↔ macOS is the primary design target, and the structural path-remapping implementation shipped in v0.1.0, and v0.2.0 physical acceptance passed on Apple Silicon macOS and native Windows x64. Intel macOS, WSL2, and other POSIX packages are preview and unverified; check the [roadmap](https://github.com/HarjjotSinghh/reinstate/blob/main/ROADMAP.md). ## What happens when Claude Code or Codex changes its session format? Reinstate adapters validate known formats and tested agent-version ranges. An unknown or untested layout fails closed for writes instead of guessing. Maintainers update fixtures, adapter logic, compatibility evidence, and release notes before expanding the supported range. Check the [compatibility matrix](https://reinstate.dev/compatibility) and [changelog](https://reinstate.dev/changelog) before syncing after an agent upgrade. ## Is this affiliated with Anthropic / OpenAI / Google / xAI? **No.** Independent Apache-2.0 project by Harjot Singh Rana. ## Production ready? `v0.5.1` is the current pre-1.0 stable release on Apple Silicon macOS and native Windows x64. It includes encrypted sync, local search, verified resume, structured handoff, and universal agent coverage across the support-tier catalog. Public installers currently pin the newest release candidate, whose tagged-artifact acceptance is pending on native Windows x64 (Apple Silicon macOS is deferred until that hardware returns); the [changelog](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md) names it exactly. Intel macOS, WSL2, and other POSIX packages are optional and unverified. See the [roadmap](https://github.com/HarjjotSinghh/reinstate/blob/main/ROADMAP.md) and [changelog](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md), use it with backups, and report bugs through GitHub Issues. ## How do I contribute? See [CONTRIBUTING.md](https://github.com/HarjjotSinghh/reinstate/blob/main/CONTRIBUTING.md). ## How do I report a security issue? See [SECURITY.md](https://github.com/HarjjotSinghh/reinstate/blob/main/SECURITY.md) — private disclosure only. --- Source: https://reinstate.dev/docs/faq Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Reinstate limitations and stable-platform boundaries > Review Reinstate limitations for agents, operating systems, native resume, storage, snapshots, path remapping, security, and release certification. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate `v0.5.1` is a pre-1.0 continuity layer with configless local session indexing, encrypted same-vendor Claude Code and Codex session sync, verified resume, structured handoff into a new destination session, and universal agent coverage across the support-tier catalog. It is not a cross-agent translator, repository synchronizer, remote desktop, coding harness, or universal agent configuration system. > **Stable platform boundary:** exact `v0.5.1` installed artifacts passed dual-platform tagged-artifact acceptance on Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 are preview and unverified. This page does not convert installer availability into a stable platform claim. ## Prerequisites Before evaluating Reinstate, record the exact Reinstate version, agent version, operating system, architecture, storage provider, and transfer direction. Check the live [compatibility matrix](https://reinstate.dev/compatibility) and keep independent backups. Treat every limitation below as applying to Reinstate unless a later changelog and compatibility update explicitly replaces it. Repository roadmap items are direction, not current CLI syntax or support. ## Current support boundary | Area | Reinstate boundary | | --- | --- | | Agents | Claude Code and Codex full local/sync capabilities; Gemini CLI and OpenCode read-only local indexing | | Resume | Claude Code → Claude Code; Codex → Codex | | Primary platforms | Apple Silicon macOS and native Windows x64, stable and physically verified | | Preview platforms | Intel macOS, Linux, and WSL2 are unverified; WSL1 unsupported | | Storage | User-owned S3-compatible object storage; R2 recommended | | Transfer model | Manual push/pull of full immutable snapshots | | Configuration | Reinstate session-sync config only | | Release status | Stable `v0.5.1` on verified platforms; pre-1.0 formats and interfaces may still change | Versions outside the tested stable ranges, including prereleases, are `UNTESTED`. Recognizable untested sessions may be discovered read-only, but push and restore fail closed with compatibility exit code `5`. Phase 1 has no unsafe compatibility override. ## Native resume is same-vendor only Reinstate preserves each supported vendor’s native representation. It does not make a Claude Code transcript natively resumable in Codex or a Codex rollout natively resumable in Claude Code. Stable `v0.5.1` structured handoff starts a new destination session with a visible, lossy projection. Reconstructed conversations are not shipped. Reinstate also does not call vendor agent APIs, execute sessions, schedule agents, provide an editor or terminal, or replace Claude Code and Codex. ## The development environment is not synchronized Phase 1 does not transfer: - Git commits, branches, worktrees, uncommitted files, or repository hosting; - dependencies, build outputs, virtual environments, containers, or runtimes; - shell history, environment variables, running processes, or terminal state; - MCP servers, skills, instructions, hooks, plugins, marketplaces, or settings; - Anthropic or OpenAI accounts, logins, OAuth tokens, or API credentials. Prepare the repository and authenticate the same vendor independently on the destination. A restored session can carry assumptions about a branch, commit, dependency, tool, or service that is absent there. Automatic environment fingerprinting and repair are roadmap work. ## Path remapping is structural, not semantic Adapters normalize recognized structural paths with `${HOME}`, `${REPO:}`, and configured work-root tokens, then expand them through the destination mapping. Unknown fields, arbitrary prose, prompts, tool output, and path-like strings inside transcript text are left unchanged. The same canonical project ID must map to the correct local root on every device. Native Windows and WSL2 are distinct devices and must not share one agent-state directory. A bad or missing mapping can prevent native discovery even when bytes transfer successfully. ## Full snapshots, manual commands, and conflicts Reinstate transfers complete immutable session snapshots. Append-aware deltas, chunking, retention controls, garbage collection, and continuous background sync are not current features. Large Codex rollouts can therefore take longer, and `--all` can select more data than intended. There is no semantic transcript merge. When the same session diverges, Reinstate records a conflict and requires an explicit `--keep-local`, `--keep-remote`, or `--keep-both` resolution. Conditional manifest updates, local backups, and conflict forks reduce overwrite risk; they do not replace an independent backup and recovery plan. ## Storage and availability limits Current `status`, `diff`, `push`, and `pull` require the configured remote manifest and its passphrase. Phase 2 `sessions`, `search`, and `inspect` use a private local derived index and require no backend. Reinstate does not operate a hosted storage service or recover a provider account. Storage compatibility depends on S3 object operations, conditional request semantics, credentials, region/endpoint correctness, availability, lifecycle rules, and quota. Phase 1 has no built-in retention UI or remote snapshot deletion command. Removing a referenced object through provider tooling can make a session unrestorable. ## Security and privacy limits - The passphrase is not stored and cannot be recovered. Losing it means losing access to existing remote ciphertext. - Hard exclusions block known credential artifacts, but a secret printed or pasted into ordinary transcript text remains inside the encrypted snapshot. - Plaintext necessarily exists on trusted local machines during native use and restore; a compromised local OS is outside the threat model. - Object storage can observe access timing, size, bucket and endpoint metadata, and opaque object keys even though payloads are encrypted. - Source availability and checksums are not a formal independent security audit. No formal audit is claimed for pre-1.0. - Local backups contain plaintext vendor session files protected by local filesystem permissions. Never treat encrypted transcript storage as permission to include production secrets in agent conversations. ## Expected evidence A supported Reinstate workflow should provide all of the following: - `rein setup check` reports the selected adapter as `SUPPORTED`; - a scoped push dry-run and pull dry-run each plan one explicit session; - object storage contains ciphertext-only manifest and snapshot objects; - the destination plan uses the correct local project root; - a mutating restore backs up an existing target and is rediscovered by the adapter; and - the same vendor’s native resume command opens the exact restored session. Missing evidence leaves the corresponding platform, version, storage, or resume claim unverified. A successful synthetic test is not a physical two-device acceptance result. ## Failure paths - Start with [troubleshooting](https://reinstate.dev/docs/troubleshooting) for installation, mapping, passphrase, manifest, conflict, large-session, transcript-secret, and active-agent failures. - Check [compatibility](https://reinstate.dev/compatibility) before reporting an untested or unsupported agent version as a defect. - Use a private [security report](https://github.com/HarjjotSinghh/reinstate/security/policy) for exclusion bypass, plaintext remote storage, or another vulnerability. - Use the [changelog](https://reinstate.dev/changelog) to confirm whether a later release has changed a stated boundary. Do not work around a safety or compatibility refusal by manually moving vendor files, weakening credential exclusions, inventing an empty manifest, or claiming a roadmap command exists. ## Security boundaries Reinstate protects selected session transport with local encryption, credential exclusions, authenticated artifacts, conditional updates, private backups, and atomic restore. Users still own endpoint trust, bucket policy, credential lifecycle, passphrase strength, local-machine security, repository preparation, transcript sensitivity, provider retention, and backup recovery. The product is independent of Anthropic and OpenAI. Local adapter compatibility does not imply vendor partnership, endorsement, account access, or a guarantee that a future vendor release will preserve its current file layout. ## Related pages - [Review the exact compatibility matrix](https://reinstate.dev/compatibility) - [Understand the security model](https://reinstate.dev/docs/security-model) - [Inspect the architecture and roadmap boundaries](https://reinstate.dev/docs/architecture) - [Compare Reinstate with adjacent workflows](https://reinstate.dev/compare) - [Review release changes and open gates](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/docs/limitations Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Reinstate compared with vendor and file sync > Compare Reinstate with native agent sync, session browsers, full agent development environments, single-agent utilities, and do-it-yourself file syncing. - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** August 16, 2026 Reinstate is a continuity layer for coding-agent work: stable `v0.5.1` indexes local sessions from eleven agents without configuration and syncs same-vendor Claude Code and Codex sessions through encrypted, user-owned storage. It complements native agent features, full coding environments, session browsers, and Git instead of replacing them. ![Landscape chart comparing coding-agent continuity products by number of supported agents and portability of session state](https://reinstate.dev/brand/01_landscape.svg) *Reinstate is positioned around multi-agent continuity and portable state; the current release scope remains same-vendor Claude Code and Codex resume.* ## Feature matrix | Capability | Reinstate | Native agent features | General-purpose file sync | | --- | --- | --- | --- | | Agent scope | Claude Code and Codex, same-vendor resume | One vendor ecosystem at a time | Any selected files, without agent semantics | | Local discovery | Claude Code/Codex full; Gemini CLI/OpenCode read-only | Vendor-specific | Filename/path only | | Storage ownership | Your S3-compatible bucket | Vendor-defined | User-selected | | Remote payload encryption | age-encrypted locally before upload | Vendor-defined | Depends on the chosen tool and setup | | Cross-OS project paths | Canonical project IDs and structural path remapping | Usually internal to the vendor workflow | Manual path and layout handling | | Credential handling | Known credential artifacts are hard-excluded | Vendor-defined | User-maintained exclusions | | Transfer model | Full immutable snapshots in Phase 1 | Vendor-defined | File-level | | Cross-agent handoff | Structured handoff into a new Claude or Codex session | Outside Reinstate’s native-resume model | No transcript semantics | | MCP, skills, plugins, settings | Universal desired-state configuration is roadmap work | Vendor-local capabilities | Manual file selection | This table describes Reinstate’s verified product scope, not a ranking guarantee. Vendor and file-sync behavior changes, so evaluate those products against their current documentation. ## How does Reinstate differ from native agent features? Native session features stay inside their vendor’s ecosystem. Reinstate’s Phase 1 differentiator is neutral storage plus structural path remapping for same-vendor Claude Code and Codex sessions. Phase 2 adds a configless local index and same-vendor native launch plans. Phase 3 adds verified resume. Phase 4 adds explicit structured handoff. Universal configuration remains later work. Reinstate does not claim to natively resume a Claude transcript inside Codex. ## How does Reinstate differ from single-agent sync tools? Single-agent utilities can solve a focused vendor-specific transfer problem. Reinstate implements separate Claude Code and Codex adapters behind one continuity model, keeps native resume same-vendor, and treats Windows ↔ macOS project-path remapping as a first-class concern. ## How does Reinstate differ from config-only tools? Config-only tools address settings rather than session continuity. Reinstate’s current release scope is local session continuity plus encrypted session sync; universal agent configuration is planned for a later phase. The planned layer covers MCP servers, skills/instructions, hooks/loops, plugins, marketplaces, and safe settings. It translates desired state through verified per-harness adapters, reports unsupported fields, and keeps credentials local. ## How does Reinstate differ from generic file sync? Generic file sync moves bytes. Reinstate understands vendor session locations, canonical project identity, structural paths, active-agent safety, and known credential exclusions. A manual setup must recreate those safeguards itself. ## How does Reinstate differ from Git? Git remains the source-code history. Reinstate moves coding-agent session context and does not replace commits, branches, remotes, or repository sync. ## Positioning one-liner > Vendor sync owns *one* agent. File sync owns *bytes*. Reinstate owns **coding-agent continuity** — sessions first, verified environments and explicit handoffs later — across agents and machines. ## Related - [Architecture](https://reinstate.dev/docs/architecture) - [Adapters](https://reinstate.dev/docs/adapters) - [Universal agent configuration](https://reinstate.dev/docs/universal-configuration) - [Roadmap](https://github.com/HarjjotSinghh/reinstate/blob/main/ROADMAP.md) --- Source: https://reinstate.dev/docs/comparison Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-16. --- # Universal agent configuration roadmap > Explore the planned non-secret desired-state model for rendering MCP servers, skills, hooks, plugins, marketplaces, and safe settings across coding agents. - **Status:** Planned - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** July 27, 2026 > Status: planned after Phase 1. These commands are design direction, not part of the current `v0.1` CLI. Reinstate will eventually make the **agent development environment** portable, not only session history. Define an MCP server, skill, instruction, hook/loop, plugin, marketplace, or safe setting once, then reconcile it across supported harnesses and devices. A developer using Claude Code, Codex, Grok, OpenCode, or Gemini CLI should not have to paste the same MCP JSON into every tool. Reinstate will keep one versioned, non-secret desired-state profile and use configuration adapters to render each harness’s real native format. ```bash # Proposed workflow; exact syntax is not stable. rein mcp add mobbin --url https://example.invalid/mcp --target all rein config diff --target claude,codex,grok,opencode,gemini rein config apply --all rein config sync ``` ## Normalize, then render Harness schemas and installation mechanisms differ. Reinstate will not copy one tool’s raw configuration tree into another. ```text native harness config ↕ import / render configuration adapter ↕ Reinstate desired-state profile ↕ encrypt / sync other devices ``` Adapters must declare supported capabilities, report unsupported or lossy mappings, preserve unrelated native settings, preview changes, back up files, write atomically, and fail closed on unverified schemas. ## Authentication stays safe The intended outcome is **configure once, authenticate as few times as safely possible**: - synced profiles contain secret references, never raw API keys, OAuth tokens, cookies, or vendor credential stores; - local values may come from the OS keychain or an explicit secret provider; - authentication status should be visible per device and harness; - Reinstate may coordinate official login flows; and - token reuse happens only when the protocol, provider, or harness explicitly supports it. Some targets may still require separate official login when safe reuse is not available. ## Executable extensions Skills, plugins, hooks, loops, and marketplaces may introduce executable code. Applying them will require source/version pinning, digest or signature checks where available, a dry-run of commands and permissions, explicit consent, and rollback. Reinstate coordinates native harness mechanisms. It does not become a coding harness, plugin runtime, or agent marketplace. Full design: [docs/universal-configuration.md](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/universal-configuration.md). --- Source: https://reinstate.dev/docs/universal-configuration Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-07-27. --- # Project continuity roadmap > Explore the planned model for one project understanding across agents: durable rules and decisions in the repository, plus learned memory with provenance. - **Status:** Planned - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** September 6, 2026 > Status: planned as Phase 7, targeted at `v0.8.0`, after Phase 6A/6B ships in `v0.7.0`. Nothing on this page exists in the current CLI; commands shown here are design direction only. Reinstate carries a *session* from one agent, device, or environment to another. Phase 6 will extend that to the *configuration* of an agent environment. Project continuity is the third kind of state: what the project **knows**. ## The problem A developer states a rule to one agent — never use em dashes in user-facing copy, use `pnpm` and never `npm`, all API handlers validate with Zod. That rule binds that agent only. Claude Code writes it to `CLAUDE.md` and its own per-project memory; Codex, Cursor, Grok, OpenCode, and Gemini CLI keep separate instruction files and separate stores, and none of them learn it. Decisions and hard-won knowledge fracture the same way, until one instruction file grows stale and contradictory and the next agent re-derives what was already known, or silently contradicts it. ## Three kinds of state, three storage models Conflating these is what makes one enormous instruction file rot. | Kind | Example | Authored by | Lives in | | --- | --- | --- | --- | | **Durable context** | rules, conventions, architecture, decisions | a person, reviewed | the repository, in git | | **Learned memory** | gotchas, workarounds, rejected approaches | an agent, proposed | the local encrypted store, synced | | **Configuration** | MCP servers, skills, hooks, plugins, settings | a person, declared | the Reinstate desired-state profile | Durable context is reviewable and useful to a teammate who has never installed Reinstate. Learned memory is provisional and provenance-carrying — it does not belong in a pull request until a person promotes it. ## Canonical context, rendered The canonical project tree — rules, conventions, architecture, and decisions — will be committed to the repository, then rendered into `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, and editor rule files through the Phase 6A configuration adapters: ```text native instruction files ↕ import / render configuration adapter ↕ canonical project context (in the repository) ``` Generated content will sit in delimited regions; hand-written prose in the same file stays untouched. A rule scoped to a path renders into a harness’s scoped mechanism where one exists, or into the global file with a recorded lossy mapping where it does not. Uninstall Reinstate and the rules, decisions, and conventions remain plain reviewable markdown. `AGENTS.md` and the native instruction files stay render targets, not a format Reinstate replaces. ## Learned memory, with provenance A memory will be a typed, structured record, not a paragraph appended to a file: type (fact, decision, gotcha, workaround, preference, or rejected approach), scope, content, and status (proposed, active, superseded, or expired). Every record carries its source — agent, session, device, branch, commit, timestamp — so a wrong memory is removable and a stale one is traceable. Retrieval is scoped to the task at hand; an agent never receives the whole store. ## Capture and promotion ```text agent learns something → explicit capture → proposed memory → review queue │ promoted ──────┴────► reviewed context in the repository ``` Two invariants: **capture is explicit** — a tool call or `rein remember`, never mining transcripts in the background — and **promotion is human**. An agent proposes; it does not promote itself into durable project truth. ## A local Reinstate MCP server Agents will read and write memory through an MCP server Reinstate runs locally: `memory.search`, `memory.add`, `memory.update`, `memory.supersede`, and `memory.promote` (never auto-applied). This stays a store with provenance, not an execution ecosystem — it will not run an agent loop, schedule work, or execute plugins. Harnesses that cannot speak MCP will still receive durable context through rendered instruction files; they read, they cannot contribute. ## Conflict and staleness Because memories will carry dates, provenance, and supersede links, Reinstate can report a collision — a memory that a later decision contradicts — instead of serving both as true. Staleness works the same way: age, explicit expiry, and evidence that no longer matches the tree are meant to surface as a count in `rein status`, not as silent decay. ## Security and sync Project continuity is designed to inherit the existing security contract and add to it: durable context is committed to the repository and is as public as the repo; learned memory is meant to be stored locally encrypted and synced as non-secret project state, the way sessions are; every record is intended to pass the secret scanner before it is stored or synced; and no credentials, tokens, or vendor auth stores are meant to enter memory or context. ## What this is not | Not this | Why | | --- | --- | | Silent transcript mining | Durable state is created by an explicit act, not inferred from conversation | | A vector-database or knowledge-graph product | Retrieval stays scoped and explainable; every record names its source | | A replacement for git | Reviewed truth is committed; only learned memory and provenance live in the encrypted store | | Parallel-agent arbitration | Reinstate records who learned what; harnesses own concurrent execution and locks | | A credential store or MCP gateway | Authentication stays Phase 6B; a gateway is exploratory and gated on real demand | Full design: [docs/project-continuity.md](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/project-continuity.md). --- Source: https://reinstate.dev/docs/project-continuity Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-06. --- Compatibility # Reinstate Compatibility: Agents, Versions, and Operating Systems > Check Reinstate compatibility tiers for catalog agents, Claude Code and Codex version ranges, macOS, native Windows, WSL2, path mapping, and unsupported setups. The catalog names eighteen coding agents. Encrypted sync (T5) covers Claude Code, Codex CLI, and OpenCode. Grok Build and Qwen Code are T4 handoff destinations with same-vendor native resume. Gemini CLI and Kimi Code CLI are T2 handoff sources. Four more are T1 read-only, and seven are T0: named, with a reason they are not usable. Native resume stays same-vendor. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Support is a tier, not a yes-or-no flag T5 is encrypted same-vendor sync. T2 is a handoff source. T0 is a named agent that`rein doctor --agents` can explain. A T0 row is not an integration. Native resume stays same-vendor. Cross-agent work is an explicit portable handoff into a new Claude Code or Codex session. Catalog agent support tiers T0 through T5 | Agent | Family | T0Known | T1Discover | T2Handoff source | T3Verified resume | T4Handoff destination | T5Encrypted sync | Evidence | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Claude Code](https://reinstate.dev/integrations/claude-code) T5 | `F1` Home tree | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [OpenAI Codex CLI](https://reinstate.dev/integrations/codex) T5 | `F1` Home tree | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [Gemini CLI](https://reinstate.dev/integrations/gemini) T2 | `F1` Home tree | Yes | Yes | Current | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md) | | [OpenCode](https://reinstate.dev/integrations/opencode) T5 | `F3` Embedded DB | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md) | | [Grok Build](https://reinstate.dev/integrations/grok) T4 | `F1` Home tree | Yes | Yes | Yes | Yes | Current | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md) | | [Kimi Code CLI](https://reinstate.dev/integrations/kimi) T2 | `F1` Home tree | Yes | Yes | Current | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/kimi.md) | | [Pi](https://reinstate.dev/integrations/pi) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md) | | [Qwen Code](https://reinstate.dev/integrations/qwen) T4 | `F1` Home tree | Yes | Yes | Yes | Yes | Current | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md) | | [Cursor CLI](https://reinstate.dev/integrations/cursor) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cursor.md) | | [Cline](https://reinstate.dev/integrations/cline) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cline.md) | | Roo CodeT0 | `F3` Embedded DB | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/roo.md) | | AiderT0 | `F4` Project file | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/aider.md) | | [GitHub Copilot CLI](https://reinstate.dev/integrations/copilot) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/copilot.md) | | AmpT0 | `F5` Remote | server-backed history | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/amp.md) | | OpenHandsT0 | `F5` Remote | server-backed history | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/openhands.md) | | ZCodeT0 | `F5` Remote | desktop-only distribution | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/zcode.md) | | MiniMaxT0 | `F5` Remote | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/minimax.md) | | Antigravity CLIT0 | `F1` Home tree | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/antigravity.md) | Machine-readable status was last reviewed on 2026-09-07. The same records are available as [machine-readable JSON](https://reinstate.dev/compatibility.json). Fixture evidence is pinned to commit[`cf6e430f3aa7`](https://github.com/HarjjotSinghh/reinstate/commit/cf6e430f3aa73ab55d1c54ef30ffe832c76f689a). T0 rows have no last-tested date: the evidence is the descriptor and storage page, not a probe. ## Tested version ranges | Agent | Tier | Tested stable range | Resume mode | Last tested | | --- | --- | --- | --- | --- | | [Claude Code](https://reinstate.dev/integrations/claude-code) | T5 | `2.1.219`–`2.1.263` | Claude Code to Claude Code (T5 encrypted sync; T3 same-vendor resume) | 2026-08-16 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [OpenAI Codex CLI](https://reinstate.dev/integrations/codex) | T5 | `0.133.0`–`0.149.0` | Codex to Codex (T5 encrypted sync; T3 same-vendor resume) | 2026-08-16 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [Gemini CLI](https://reinstate.dev/integrations/gemini) | T2 | `0.55.1`–`0.55.1` | Handoff source only (T2); no native resume | 2026-08-16 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md) | | [OpenCode](https://reinstate.dev/integrations/opencode) | T5 | `1.18.21`–`1.18.29` | OpenCode to OpenCode (T5 encrypted sync; T3 same-vendor resume and fork); OpenCode as a structured handoff destination (T4) | 2026-08-22 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md) | | [Grok Build](https://reinstate.dev/integrations/grok) | T4 | `1.0.5`–`1.0.13` | Same-vendor native resume via grok --resume (T3); handoff destination via grok --session-id (T4) | 2026-09-07 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md) | | [Pi](https://reinstate.dev/integrations/pi) | T1 | `0.73.1`–`0.73.1` | Not usable (T1 discover only) | 2026-08-17 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md) | | [Qwen Code](https://reinstate.dev/integrations/qwen) | T4 | `0.21.12`–`0.23.0` | Qwen Code to Qwen Code (T3 same-vendor resume and fork); Qwen Code as a structured handoff destination (T4) | 2026-09-07 [Test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md) | Every agent with a fail-closed version range is listed here, whatever its tier — T5 encrypted sync, T4 handoff destination and native resume, T2 handoff source, or T1 discovery. Ranges reflect current source compatibility evidence and deterministic synthetic fixtures; they are not a claim that every platform row has passed physical-device certification. Prereleases and versions outside each inclusive range are `UNTESTED`. The[agent-version change tracker](https://reinstate.dev/compatibility/agent-version-history) records when the inclusive ranges and fail-closed behavior changed across releases. ## Operating-system matrix | Environment | Claude Code | Codex CLI | Reinstate status | Evidence | | --- | --- | --- | --- | --- | | macOS native · arm64 | Required | Required | Stable Verified | 2026-08-16 [Evidence and gate](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | macOS native · amd64 | Preview Unverified | Preview Unverified | Preview Unverified | No completed result [Evidence and gate](https://github.com/HarjjotSinghh/reinstate/issues/97) | | Windows 11 native · amd64 | Required | Required | Stable Verified | 2026-08-16 [Evidence and gate](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-windows-phase4-V040RC11.md) | | Windows 11 WSL2 · amd64 | Preview Unverified | Preview Unverified | Preview Unverified | No completed result [Evidence and gate](https://github.com/HarjjotSinghh/reinstate/issues/98) | ## What the compatibility states mean - **Supported:** Exact layout and version range has release evidence; discovery, push, and pull proceed. - **Untested:** Recognizable but unverified; discovery is read-only and writes fail closed. - **Unsupported:** Known-incompatible layout, version, environment, or agent; the operation stops. - **Not installed:** No local installation or session root found; reported as informational. `rein setup check` returns compatibility exit code `5` when an installed adapter is `UNTESTED` or `UNSUPPORTED`. Phase 1 has no unsafe compatibility override. Unknown layout is exit code `5`, never a best-effort parse. ## How cross-platform path compatibility works Reinstate rewrites known structural paths to portable tokens such as`$${HOME}` and `$${REPO:}`. The destination device expands those tokens using its own configured paths. The internal mapper's work-alias primitive is not wired into Reinstate configuration or adapters. Free-form transcript prose and unknown fields are left unchanged. Native Windows and WSL2 are separate devices. Do not point both environments at one shared agent-state directory. Their path semantics and vendor layouts differ, so each must have its own Reinstate device identity and mappings. ## Explicitly unsupported - WSL1. - Treating native Windows and WSL as one Reinstate device. - Automatically sharing one agent-state directory between Windows and WSL. - Exporting or restoring an untested agent layout. - Encrypted sync for any agent other than Claude Code, Codex CLI, and OpenCode (T5 only). - Native resume for T2 handoff sources or T0 catalog names. - Silent translation between vendor-native transcripts. - Syncing vendor credentials, raw secrets, MCP settings, skills, or plugins. ## Verify your own device Run `rein setup check` before pushing real sessions. Treat its state as authoritative for the installed version and local layout, and review the repository's compatibility evidence when a vendor ships a new version. ## Compatibility resources [Agent integrations](https://reinstate.dev/integrations) [Agent-version history](https://reinstate.dev/compatibility/agent-version-history) [Path-mapping visualizer](https://reinstate.dev/tools/path-mapping-visualizer) [Troubleshooting](https://reinstate.dev/docs/troubleshooting) [Security model](https://reinstate.dev/security) [Release changes](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/compatibility Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Compatibility history # Claude Code and Codex Version Support History > Track the evidence-backed Claude Code and Codex CLI version ranges supported by each Reinstate release, including fail-closed compatibility changes. Reinstate v0.6.0-rc.6 (stable v0.5.1) accepts Claude Code versions 2.1.219–2.1.263 and Codex CLI versions 0.133.0–0.149.0, each on evidence reviewed 2026-08-16; versions outside the ranges still fail closed. - **Published:** July 27, 2026 - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Current tested stable ranges | Agent | Inclusive range | Resume mode | Evidence reviewed | | --- | --- | --- | --- | | [Claude Code](https://reinstate.dev/integrations/claude-code) | `2.1.219`–`2.1.263` | Claude Code to Claude Code (T5 encrypted sync; T3 same-vendor resume) | Aug 16, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [OpenAI Codex CLI](https://reinstate.dev/integrations/codex) | `0.133.0`–`0.149.0` | Codex to Codex (T5 encrypted sync; T3 same-vendor resume) | Aug 16, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [Gemini CLI](https://reinstate.dev/integrations/gemini) | `0.55.1`–`0.55.1` | Handoff source only (T2); no native resume | Aug 16, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md) | | [OpenCode](https://reinstate.dev/integrations/opencode) | `1.18.21`–`1.18.29` | OpenCode to OpenCode (T5 encrypted sync; T3 same-vendor resume and fork); OpenCode as a structured handoff destination (T4) | Aug 22, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md) | | [Grok Build](https://reinstate.dev/integrations/grok) | `1.0.5`–`1.0.13` | Same-vendor native resume via grok --resume (T3); handoff destination via grok --session-id (T4) | Sep 7, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md) | | [Pi](https://reinstate.dev/integrations/pi) | `0.73.1`–`0.73.1` | Not usable (T1 discover only) | Aug 17, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md) | | [Qwen Code](https://reinstate.dev/integrations/qwen) | `0.21.12`–`0.23.0` | Qwen Code to Qwen Code (T3 same-vendor resume and fork); Qwen Code as a structured handoff destination (T4) | Sep 7, 2026 [Immutable test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md) | The matrix is rendered from the same committed compatibility data as[the public compatibility page](https://reinstate.dev/compatibility). Ranges cover stable three-component versions only. A prerelease, malformed version, or version below or above the inclusive endpoints is not silently accepted. ## What happens outside a tested range A recognizable installed agent outside the tested range is `UNTESTED`.`rein setup check` exits with compatibility code `5`, and the Phase 1 CLI blocks session export and restore. There is no public unsafe override in the current CLI.`UNSUPPORTED` and `NOT_INSTALLED` also prevent mutation. This source-level gate is necessary but does not certify every operating system. Native Windows, macOS amd64, WSL2, and the complete Reinstate two-device matrix retain separate physical acceptance evidence on the [current matrix](https://reinstate.dev/compatibility). ## Release-by-release compatibility tracker | Reinstate release | Date | Agent-version range | Related compatibility change | | --- | --- | --- | --- | | [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.6/CHANGELOG.md) | 2026-09-08 | Widens the verified Grok Build range to 1.0.5-1.0.13 (was the single 1.0.5 build), on the maintainer's own console evidence, under ADR 0005 D3: the acceptance host's Grok Build self-updated past the in-tree 1.0.5 ceiling, and the pinned 1.0.5 binary no longer completes a prompt against xAI from any console, including the maintainer's own, while 1.0.13 answers instantly there. This widening's own evidence is read-only (grok --version/--help output shape, and the session file layout and JSON key names observed under a real Grok home); version-output parsing and every launch-plan-relevant --help flag (--resume, --fork-session, --continue, --session-id) are unchanged from 1.0.5. Completed-turn grok:E1-E3 evidence against 1.0.13 is executed by the maintainer at their own console in this candidate's tagged run. Claude Code (2.1.219-2.1.263), Codex CLI (0.133.0-0.149.0), OpenCode (1.18.21-1.18.29), and Qwen Code (0.21.12-0.23.0) ranges are unchanged. macOS evidence is pending. | Corrective candidate after v0.6.0-rc.5 tagged-artifact acceptance on native Windows x64, plus two same-artifact rechecks, ended device verdict FAIL (211/4/0/0 of 215 required rows, zero product defects). Refines the MatrixH:H7 live-home acceptance check from aggregate byte-for-byte digest equality of the live agent-home roots (shown unmeasurable on a live, multi-session host by both rc.5 rechecks) to a full per-file before/after listing of only the session-bearing subtrees with per-entry attribution to a process other than rein. Schedules issue #424 (the daemon Task-Scheduler task not pinning the agent-root environment it was installed under) for v0.6.1 rather than this candidate. No agent tier changes. See CHANGELOG.md. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.6/docs/compatibility.md). | | [v0.6.0-rc.5](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.5/CHANGELOG.md) | 2026-09-07 | Widens the verified OpenCode range to 1.18.21-1.18.29 (was 1.18.21-1.18.27 through v0.6.0-rc.4), on native Windows evidence only, under ADR 0005 D3: against the shared live OpenCode store, a real OpenCode 1.18.29 session was created in a throwaway project and identified by a token planted in its own first turn, then indexed, resumed, and forked through the launch plan Reinstate produces, and the resumed session returned that same token. Session row shape (session/message/part tables and columns), --session, --session --fork, --continue, the non-interactive run form, version-output parsing, and the structured-handoff capsule path are unchanged from 1.18.27. Claude Code (2.1.219-2.1.263) and Qwen Code (0.21.12-0.23.0) ranges are unchanged. macOS evidence is pending. | Corrective candidate after v0.6.0-rc.4 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (208/1/4/2 of 215 required rows; both of that candidate's own fixes, the Pi reader and the widened Qwen Code range, were confirmed). Fixes the agent probe redaction gap that let real project-name path segments reach a committed artifact unshaped (MatrixB:B4), the gap where an existing-but-empty overridden agent root was indistinguishable from an absent one (MatrixB:B7), and the interactive switcher's all-projects readiness defect that showed every visible row as unresumable regardless of true state. Widens the verified OpenCode range to 1.18.29. No agent tier changes. See CHANGELOG.md. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.5/docs/compatibility.md). | | [v0.6.0-rc.4](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.4/CHANGELOG.md) | 2026-09-07 | Widens the verified Qwen Code range to 0.21.12-0.23.0 (was 0.21.12-0.21.13 through v0.6.0-rc.3), on native Windows physical-resume evidence only, under ADR 0005 D3: a real Qwen Code 0.23.0 session was created, indexed, resumed, and forked through the launch plan Reinstate produces, and the resumed session returned a token that existed only in the original session's history. Session file location and naming, the first-user-message shape, --resume, --resume --fork-session, --session-id, and version-output parsing are unchanged from 0.21.13. Claude Code (2.1.219-2.1.263) and OpenCode (1.18.21-1.18.27) ranges are unchanged. macOS evidence for the widened part is pending. | Corrective candidate after v0.6.0-rc.3 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (201/3/1/10 of 215 required rows; all 22 CLI rows and all 16 Hop rows passed, and the Cursor CLI store-schema fix was confirmed on real data). Fixes exactly two things: the Pi reader now indexes message.content for prompt\_preview and search text (a confirmed code defect, pi:C3), and the verified Qwen Code range widens to 0.23.0 (a version-compatibility block, not a defect). No agent tier changes. See CHANGELOG.md. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.4/docs/compatibility.md). | | [v0.6.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.3/CHANGELOG.md) | 2026-09-07 | Unchanged from v0.6.0-rc.2: inclusive Claude Code range 2.1.219-2.1.263 and OpenCode range 1.18.21-1.18.27. The Codex CLI range stays 0.133.0-0.149.0. | Corrective candidate after v0.6.0-rc.2 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (203/5/2/5 of 215 required rows). Fixes exactly the Cursor CLI store reader: a post-commit schema-only inspection of real Cursor CLI 2026.08.11 store.db files found blobs/meta tables, not the messages/message/bubbles shape the prior reader guessed at, so message\_count and search\_text now read the real schema. No agent tier changes. See CHANGELOG.md. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.3/docs/compatibility.md). | | [v0.6.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.2/CHANGELOG.md) | 2026-09-07 | Unchanged from v0.6.0-rc.1: inclusive Claude Code range 2.1.219-2.1.263 and OpenCode range 1.18.21-1.18.27. The Codex CLI range stays 0.133.0-0.149.0. | Corrective candidate after v0.6.0-rc.1 tagged-artifact acceptance on native Windows x64 found 7 required-row failures (201 of 216 rows passed). No agent tier changes; fixes Cursor CLI session-discovery isolation, Cline/Cursor message\_count and Cursor size\_bytes, push/pull --agent completion, OpenCode handoff determinism, and adds Windows-shaped partial-final-record fixtures for Claude Code, Codex, and Grok Build. See CHANGELOG.md. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.2/docs/compatibility.md). | | [v0.6.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.1/CHANGELOG.md) | 2026-09-06 | Widens the inclusive Claude Code range to 2.1.219-2.1.263 (was 2.1.219-2.1.238 through v0.5.2-rc.1) and the OpenCode range to 1.18.21-1.18.27 (was the single 1.18.21 build). The Codex CLI range is unchanged at 0.133.0-0.149.0. Both new ceilings rest on native Windows physical resume evidence only, under ADR 0005: a session created with the installed version was indexed and resumed through the launch plan Reinstate produced, returning a token that existed only in that session's history. Apple Silicon macOS evidence for the widened part is pending. | Carries the Hop client: OpenCode reaches encrypted sync (T5) and Kimi Code CLI becomes a handoff source (T2). Both are merged into this candidate but not yet part of a stable release; the published compatibility matrix moves with the tag, not with the tree. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.6.0-rc.1/docs/compatibility.md). | | [v0.5.2-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.2-rc.1/CHANGELOG.md) | 2026-08-23 | | | | [v0.5.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.1/CHANGELOG.md) | 2026-08-21 | Unchanged from v0.5.0: inclusive Claude Code range 2.1.219-2.1.238 and Codex CLI range 0.133.0-0.149.0. | Patch release. Updates the pure-Go SQLite driver behind the session index and the OpenCode embedded store. No product code changed, and no agent tier moved. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.1/docs/testing/v0.5.0-rc.6-agent-verification-prompts.md). | | [v0.5.0](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0/CHANGELOG.md) | 2026-08-21 | Inclusive Claude Code range 2.1.219-2.1.238 and Codex CLI range 0.133.0-0.149.0, each raised on dual-platform physical resume evidence during the Phase 5 candidates. | Stable Phase 5 release. Universal agent coverage across a catalog of 18 agents, with Claude Code and Codex remaining the only native resume and sync surfaces. Authorized by dual-platform tagged-artifact acceptance on v0.5.0-rc.6. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0/docs/testing/v0.5.0-rc.6-agent-verification-prompts.md). | | [v0.5.0-rc.6](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.6/CHANGELOG.md) | 2026-08-21 | Unchanged from v0.5.0-rc.5: inclusive Claude Code range 2.1.219-2.1.238 and Codex CLI range 0.133.0-0.149.0. | Sixth Phase 5 candidate. Carries the single defect physical v0.5.0-rc.5 acceptance found: the agent probe emitted a raw 38-character Git object hash, because the shape normaliser recognised only exactly 32, 40 and 64 characters while OpenCode keeps a Git object store under each snapshot. A committed probe artifact must not carry a content hash of the operator own repository. Claude Code and Codex remain the only T3-T5 surfaces. This candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.6/docs/testing/v0.5.0-rc.6-agent-verification-prompts.md). | | [v0.5.0-rc.5](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.5/CHANGELOG.md) | 2026-08-21 | Raises both inclusive ranges on dual-platform physical evidence: Claude Code to 2.1.219-2.1.238 and Codex CLI to 0.133.0-0.149.0. On macOS and on Windows a session created with the new version was indexed by Reinstate, resumed through the launch plan Reinstate produced, and returned a token that existed only in the original session history. | Fifth Phase 5 candidate. Fixes an index that never re-read a source after Reinstate itself changed, so a reader fix reached nobody who already had an index. Also recovers Gemini project paths on case-insensitive filesystems, makes an agent root override authoritative when it names a missing path, and skips parsing an unchanged source. Claude Code and Codex remain the only T3-T5 surfaces. This candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.5/docs/testing/v0.5.0-rc.5-agent-verification-prompts.md). | | [v0.5.0-rc.4](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.4/CHANGELOG.md) | 2026-08-20 | Raises both inclusive ranges on dual-platform physical evidence: Claude Code to 2.1.219-2.1.238 and Codex CLI to 0.133.0-0.149.0. On macOS and on Windows a session created with the new version was indexed by Reinstate, resumed through the launch plan Reinstate produced, and returned a token that existed only in the original session history. | Fourth Phase 5 candidate. Makes the agent probe reproducible, normalizes raw content hashes out of probe output, refuses native actions on a T0 agent with the compatibility exit code, narrows an agent-filtered refresh to that agent, and completes agent keys per flag. Claude Code and Codex remain the only T3-T5 surfaces. This candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.4/docs/testing/v0.5.0-rc.4-agent-verification-prompts.md). | | [v0.5.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.3/CHANGELOG.md) | 2026-08-20 | Unchanged from v0.5.0-rc.2: inclusive Claude Code range 2.1.219-2.1.229. The Codex CLI range is unchanged at 0.133.0-0.147.0. | Third Phase 5 candidate. Restores Kimi, Copilot, and OpenCode session discovery after those vendor CLIs changed their on-disk formats. Claude Code and Codex remain the only T3-T5 surfaces. This candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.3/docs/testing/v0.5.0-rc.3-agent-verification-prompts.md). | | [v0.5.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.2/CHANGELOG.md) | 2026-08-19 | Unchanged from v0.5.0-rc.1: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Second Phase 5 candidate after v0.5.0-rc.1 dual-platform tagged-artifact acceptance FAILED. Structured-handoff projection pairs tool\_result with its tool\_call. Claude Code and Codex remain the only T3–T5 surfaces. This candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.2/docs/testing/v0.5.0-rc.2-agent-verification-prompts.md). | | [v0.5.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.1/CHANGELOG.md) | 2026-08-19 | Unchanged from v0.4.0: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | First Phase 5 candidate. Six T1 discover agents and three T2 handoff sources. Claude Code and Codex remain the only T3–T5 surfaces. Dual-platform tagged-artifact acceptance FAILED (macOS 88/150, Windows 93/150); this candidate does not authorize stable v0.5.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.5.0-rc.1/docs/testing/v0.5.0-rc.1-agent-verification-prompts.md). | | [v0.4.0](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0/CHANGELOG.md) | 2026-08-16 | Unchanged from v0.4.0-rc.11: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Phase 4 stable after dual-platform tagged-artifact acceptance PASS on v0.4.0-rc.11 (Apple Silicon macOS 44/44, native Windows x64 44/44). Structured handoff continues the same task in a new Claude Code or Codex session. Native resume remains same-vendor. Gemini CLI, OpenCode, and Grok Build remain handoff sources only. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md). | | [v0.4.0-rc.11](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.11/CHANGELOG.md) | 2026-08-15 | Unchanged from v0.4.0-rc.10: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Eleventh Phase 4 candidate after v0.4.0-rc.10 physical dual-platform acceptance FAILED (macOS 41/44 A1/A3/A7, Windows 40/44 A1/A2/A3/A5). This candidate requires the five-bullet dest first-reply in bootstrap and Windows one-line argv, records lineage before dest Launch, recovers artifact dirs in handoff list, and Materializes dest-home workspace trust. Dual-platform tagged-artifact acceptance later PASS (macOS 44/44, Windows 44/44); promoted to stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.11/internal/handoff/desttrust.go). | | [v0.4.0-rc.10](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.10/CHANGELOG.md) | 2026-08-15 | Unchanged from v0.4.0-rc.9: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Tenth Phase 4 candidate after v0.4.0-rc.9 physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44). This candidate falls back to a one-line absolute projection.md pointer whenever dest briefing contains CR/LF so Windows CreateProcess cannot truncate argv. Physical dual-platform acceptance FAILED (macOS 41/44 A1/A3/A7, Windows 40/44 A1/A2/A3/A5; remaining product defects dest first-reply, lineage-after-launch, dest folder-trust); this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.10/internal/handoff/pipeline.go). | | [v0.4.0-rc.9](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.9/CHANGELOG.md) | 2026-08-15 | Unchanged from v0.4.0-rc.8: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Ninth Phase 4 candidate after v0.4.0-rc.8 physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44). This candidate maps a recognized off-PATH layout to inspect JSON status=supported without claiming a verified version range, and still fail-closes destination launch when the executable is missing. Physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44; dest-ack A4 PASS, A1/A2/A3/A5/A6/A7 FAIL; remaining product defect Windows dest argv CR/LF truncation); this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.9/internal/agentcheck/agent.go). | | [v0.4.0-rc.8](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.8/CHANGELOG.md) | 2026-08-15 | Unchanged from v0.4.0-rc.7: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Eighth Phase 4 candidate after v0.4.0-rc.7 physical dual-platform acceptance FAILED (macOS 38/44, Windows 34/44). This candidate scans recognized Claude layout on off-PATH Inspect instead of returning before the layout scan (R1) and pins Go 1.25.13 for govulncheck. Physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44; remaining product defect Windows inspect JSON not\_installed); this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.8/internal/agentcheck/agent.go). | | [v0.4.0-rc.7](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.7/CHANGELOG.md) | 2026-08-15 | Unchanged from v0.4.0-rc.6: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Seventh Phase 4 candidate after v0.4.0-rc.6 physical dual-platform acceptance FAILED. This candidate bounds Windows process listing, fails closed on determined out-of-range Claude (2.1.230) during read-only handoff, classifies hung --version as Compatibility UNTESTED instead of Runtime, and does not block source-only Grok preflight on missing native layout. Physical dual-platform acceptance FAILED (macOS 38/44, Windows 34/44; remaining product defect R1 off-PATH Inspect); this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.7/internal/processcheck/process_windows.go). | | [v0.4.0-rc.6](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.6/CHANGELOG.md) | 2026-08-14 | Unchanged from v0.4.0-rc.5: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Sixth Phase 4 candidate after v0.4.0-rc.5 physical dual-platform acceptance FAILED. This candidate remaps foreign/fixture-user workspaces only when the project leaf matches the cwd git repo, refuses a different-repository bind, and refuses non-TTY destination launch before index open. Dual-platform tagged-artifact acceptance is pending; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.6/internal/handoff/workspace.go). | | [v0.4.0-rc.5](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.5/CHANGELOG.md) | 2026-08-13 | Unchanged from v0.4.0-rc.4: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Fifth Phase 4 candidate after v0.4.0-rc.4 physical dual-platform acceptance FAILED. This candidate kills hanging Windows --version process trees, refuses non-TTY destination launch before Plan, remaps foreign-OS and fixture-user workspaces onto the local git checkout, and classifies Codex compaction as summarized. Physical dual-platform acceptance FAILED; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.5/internal/adapter/exec_windows.go). | | [v0.4.0-rc.4](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.4/CHANGELOG.md) | 2026-08-13 | Unchanged from v0.4.0-rc.3: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Fourth Phase 4 candidate after v0.4.0-rc.3 physical dual-platform acceptance FAILED. This candidate treats an explicit empty dest home as supported, bounds hanging --version probes including grandchild-held pipes, persists --no-launch without warning acks, keeps sidecared summarized fidelity, and fixes Windows passphrase-FD / isolation-env unit failures. Physical dual-platform acceptance FAILED; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.4/internal/adapter/version.go). | | [v0.4.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.3/CHANGELOG.md) | 2026-08-13 | Unchanged from v0.4.0-rc.2: inclusive Claude Code range 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Third Phase 4 candidate after v0.4.0-rc.2 physical dual-platform acceptance FAILED. This candidate carries C4 (wrong-repo cwd refused), F8 (non-TTY fail-closed before spawn), Grok-source busy-check, R4 timed-out probe classified UNTESTED/Compatibility, plus remaining matrix product defects (--no-redact, list isolation, fidelity/projection\_events, checkpoint sidecar refs, destination MCP/skill gaps). Physical dual-platform acceptance FAILED; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.3/internal/handoff/projection.go). | | [v0.4.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.2/CHANGELOG.md) | 2026-08-13 | Widened the inclusive Claude Code range from 2.1.219–2.1.228 to 2.1.219–2.1.229. The Codex CLI range is unchanged at 0.133.0–0.147.0. | Second Phase 4 candidate. v0.4.0-rc.1 physical acceptance FAILED, and this candidate fixes what it found: Claude-sourced handoffs no longer depend on a version file real installs never create, reader-emitted paths are tokenized before capsule validation, live changed files reach the destination, a timed-out version probe is classified UNTESTED instead of accepted, and capsule validation checks path-typed fields instead of rejecting prose that starts with a slash. Physical dual-platform acceptance FAILED; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.2/internal/handoff/projection.go). | | [v0.4.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.1/CHANGELOG.md) | 2026-08-12 | Widened the inclusive Claude Code range from 2.1.219–2.1.227 to 2.1.219–2.1.228. The Codex CLI range is unchanged at 0.133.0–0.147.0. | First Phase 4 candidate: explicit structured handoff of the same task into a new Claude Code or Codex session. Gemini CLI, OpenCode, and Grok Build are handoff sources only. The 2.1.228 patch is source-tested only, and dual-platform tagged-artifact acceptance is pending; this candidate does not authorize stable v0.4.0. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.4.0-rc.1/internal/handoff/projection.go). | | [v0.3.0](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0/CHANGELOG.md) | 2026-08-11 | Claude Code 2.1.219–2.1.227 and Codex CLI 0.133.0–0.147.0 unchanged from RC7. | Stable Phase 3 release after dual-platform tagged-artifact acceptance PASS on v0.3.0-rc.7. Fresh stable dual validation is required after tag publication. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0/docs/testing/results/2026-08-11-macos-phase3-V030RC7.md). | | [v0.3.0-rc.7](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.7/CHANGELOG.md) | 2026-08-11 | Claude Code 2.1.219–2.1.227 and Codex CLI 0.133.0–0.147.0 unchanged from RC6. | Packages the post-RC6 Phase 3 harden stack (non-TTY fail-closed native launch, Windows Ctrl+C safety, capability probe demotion, isolated CLAUDE\_CONFIG\_DIR/CODEX\_HOME roots, expanded local smoke) without widening Claude Code 2.1.219–2.1.227 or Codex CLI 0.133.0–0.147.0. Tagged-artifact acceptance is pending. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.7/scripts/testing/phase3-local-smoke.sh). | | [v0.3.0-rc.6](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.6/CHANGELOG.md) | 2026-08-11 | Expanded the inclusive Claude Code range from 2.1.219–2.1.220 to 2.1.219–2.1.227 and the Codex CLI range from 0.133.0–0.146.0 to 0.133.0–0.147.0. | Widened fail-closed product ranges so primary-host Claude Code 2.1.225/2.1.227 and Codex CLI 0.147.0 installs were SUPPORTED for dual-platform Phase 3 retest. Dual-platform tagged-artifact acceptance failed on real-launch baseline, TTY/picker, and related host evidence rows. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.6/internal/adapter/claude/claude.go). | | [v0.3.0-rc.5](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.5/CHANGELOG.md) | 2026-08-08 | No agent-version range change documented. | Carries the RC4 Windows-first product fixes and makes PowerShell release-artifact verification portable without widening Claude Code 2.1.219–2.1.220 or Codex CLI 0.133.0–0.146.0. Tagged-artifact acceptance is pending. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.5/scripts/check-release-artifacts.ps1). | | [v0.3.0-rc.4](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.4/CHANGELOG.md) | 2026-08-08 | No agent-version range change documented. | Fixes the RC3 native-Windows PowerShell 5.1 staging and human-output privacy blockers without widening Claude Code 2.1.219–2.1.220 or Codex CLI 0.133.0–0.146.0. Its release workflow failed before publication. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.4/internal/doctor/redact.go). | | [v0.3.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.3/CHANGELOG.md) | 2026-08-07 | No agent-version range change documented. | Hardens Windows trusted executable resolution and PowerShell snapshot/staging gates after RC2 native Windows FAIL without widening Claude Code 2.1.219–2.1.220 or Codex CLI 0.133.0–0.146.0. Native Windows acceptance still failed on later staging/privacy gates. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.3/internal/executabletrust/resolve.go). | | [v0.3.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.2/CHANGELOG.md) | 2026-08-07 | No agent-version range change documented. | Corrects Windows trusted executable resolution for extensionless vendor names via PATHEXT without widening Claude Code 2.1.219–2.1.220 or Codex CLI 0.133.0–0.146.0. Tagged-artifact acceptance is pending. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.2/internal/executabletrust/resolve.go). | | [v0.3.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.1/CHANGELOG.md) | 2026-08-05 | No agent-version range change documented. | Adds Phase 3 verified-resume observation and authorization without widening the Claude Code 2.1.219–2.1.220 or Codex CLI 0.133.0–0.146.0 ranges. macOS acceptance passed; native Windows failed. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.3.0-rc.1/internal/preflight/verify.go). | | [v0.2.0](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0/CHANGELOG.md) | 2026-08-05 | No agent-version range change documented. | Ships the RC2-tested runtime adapter tree unchanged. Apple Silicon macOS and native Windows x64 are verified stable platforms; Intel macOS and Linux/WSL2 artifacts remain preview until their deferred physical acceptance completes. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0/internal/adapter/codex/codex.go). | | [v0.2.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0-rc.3/CHANGELOG.md) | 2026-08-02 | No agent-version range change documented. | No adapter behavior change from v0.2.0-rc.2. This candidate adds verified package-manager distribution metadata and native package artifacts without widening the tested Claude Code or Codex CLI ranges. | | [v0.2.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0-rc.2/CHANGELOG.md) | 2026-08-02 | No agent-version range change documented. | No adapter behavior change from v0.2.0-rc.1. This candidate corrects release-artifact provenance and native-Windows verification without widening the tested Claude Code or Codex CLI ranges. | | [v0.2.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0-rc.1/CHANGELOG.md) | 2026-08-01 | Expanded the inclusive Codex CLI range from 0.133.0–0.145.0 to 0.133.0–0.146.0; the Claude Code range remains 2.1.219–2.1.220. | Codex CLI 0.146.0 passed the complete Phase 2 physical matrix on both macOS and native Windows. The adapter still fails closed for stable versions above 0.146.0 and for every prerelease. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.2.0-rc.1/internal/adapter/codex/codex.go). | | [v0.1.0](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/CHANGELOG.md) | 2026-07-30 | No agent-version range change documented. | No behavior change from v0.1.0-rc.8. The stable release ships that candidate’s product code unchanged, so the two-device Phase 1 acceptance evidence applies directly to it. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/processcheck/process.go). | | [v0.1.0-rc.8](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.8/CHANGELOG.md) | 2026-07-29 | No agent-version range change documented. | Restore liveness no longer depends on an open file handle. Claude Code closes its session file between appends, so a live session held no handle and RC7 treated it as free. Detection now also matches an agent naming the exact session on its command line, or working inside the session’s mapped project. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.8/internal/processcheck/process.go). | | [v0.1.0-rc.7](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.7/CHANGELOG.md) | 2026-07-28 | No agent-version range change documented. | Restore liveness detection became session-scoped. A restore now checks whether the exact target session file is held open, using operating-system file handles, instead of asking whether any Claude Code or Codex process is running. A session that is genuinely in use is restored alongside the live one rather than refused. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.7/internal/processcheck/process.go). | | [v0.1.0-rc.6](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.6/CHANGELOG.md) | 2026-07-27 | No agent-version range change documented. | Codex working directories resolve to canonical project IDs. Additional-device init changed from RC5’s metadata-only manifest probe to reading the complete remote ciphertext; init still does not decrypt it or validate the passphrase. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.6/internal/cli/commands_impl.go). | | [v0.1.0-rc.5](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.5/CHANGELOG.md) | 2026-07-27 | No agent-version range change documented. | Additional-device init required a metadata-only existence probe for the remote manifest before saving local setup; it did not read or decrypt the ciphertext. [Tagged implementation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.5/internal/cli/commands_impl.go). | | [v0.1.0-rc.4](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.4/CHANGELOG.md) | 2026-07-26 | No agent-version range change documented. | Claude restore paths became destination-aware, legacy unmapped snapshots fail closed, and exact native restore locations are verified. | | [v0.1.0-rc.3](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.3/CHANGELOG.md) | 2026-07-26 | Introduced the current inclusive ranges: Claude Code 2.1.219–2.1.220 and Codex CLI 0.133.0–0.145.0. | Installed versions outside a tested stable range become UNTESTED and setup check exits with compatibility code 5. | | [v0.1.0-rc.2](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.2/CHANGELOG.md) | 2026-07-25 | No agent-version range change documented. | Release CI corrected signed-tag verification; no adapter compatibility change is recorded. | | [v0.1.0-rc.1](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0-rc.1/CHANGELOG.md) | 2026-07-25 | Claude Code and Codex adapters launched with fixture-backed checks, but this changelog does not publish an exact historical version range. | Established fail-closed adapter compatibility states and same-vendor session restore. | “No change documented” is intentional. It means the tagged changelog does not claim a range change; it does not reconstruct private test history or guess what an earlier binary accepted. RC1 and RC2 do not publish exact historical endpoints in the current release evidence, so this tracker leaves them unstated. ## How a range changes 1. A vendor version is exercised against deterministic synthetic adapter fixtures. 2. Discovery, structural path handling, export, restore, exclusions, and failure behavior are reviewed. 3. The adapter constants and tests change together. 4. `compatibility.json`, documentation, and release notes cite the exact evidence. 5. Physical platform results remain separately qualified until their acceptance rows pass. A new vendor release is not supported merely because its version number is close to the current range. The range expands only after evidence is committed and released. ## Before upgrading an agent - Check this tracker and the current compatibility matrix. - Keep the existing agent and Reinstate installers or another recovery path. - Run `rein setup check` before any push or pull. - Use a synthetic, non-sensitive session for a newly accepted version. - Report the exact agent version, Reinstate version, operating system, and redacted failure. ## Compatibility sources [Current compatibility matrix](https://reinstate.dev/compatibility) [Reinstate release notes](https://reinstate.dev/changelog) [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Codex integration](https://reinstate.dev/integrations/codex) [Troubleshooting](https://reinstate.dev/docs/troubleshooting) --- Source: https://reinstate.dev/compatibility/agent-version-history Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-07. --- Security # Reinstate Security: Local Encryption and BYO Storage > Learn how Reinstate encrypts coding-agent sessions locally with age, excludes credentials, uses your S3-compatible storage, and restores safely. Reinstate encrypts selected Claude Code and Codex session artifacts locally with age passphrase encryption before uploading ciphertext to storage you control. Vendor credentials are excluded, storage keys remain in the OS keyring, and restores use backups, atomic writes, and explicit conflict handling. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Security properties at a glance - **Remote payloads:** age-encrypted ciphertext - **Storage ownership:** Your S3-compatible or R2 bucket - **Session passphrase:** Not stored by Reinstate - **Storage credentials:** Operating-system keyring - **Vendor API access:** Not required - **Formal security audit:** Not claimed for pre-1.0 ## Where plaintext exists 1. A supported adapter reads selected local session files from Claude Code or Codex. 2. Reinstate normalizes known structural paths and builds the portable artifact on the local machine. 3. The artifact is encrypted locally using an age scrypt recipient derived from your passphrase. 4. Reinstate sends ciphertext over TLS to your configured S3-compatible endpoint. 5. Another configured device downloads the ciphertext, decrypts it locally, remaps paths, and restores the native files. The object-storage provider does not receive plaintext session content or the passphrase from Reinstate. It can still observe bucket access, object timing, size, and opaque object keys. ## Encryption and key handling | Property | Current behavior | | --- | --- | | Payload encryption | age passphrase encryption with an scrypt recipient | | Multi-device decryption | Enter the same long passphrase on each trusted device | | Passphrase storage | Not stored; interactive commands read a hidden terminal prompt | | Automation | Use a pre-opened file descriptor through `REINSTATE_PASSPHRASE_FD`; ordinary environment variables and CLI passphrase flags are rejected | | Storage credentials | Stored in the native OS keyring, not in `config.toml` | There is no passphrase recovery. Use a long, unique passphrase and keep it in a trusted password manager. Losing it means losing the ability to decrypt remote artifacts; that is a consequence of the design, not an account-recovery bug. ## Credentials and files excluded from sync Phase 1 hard-excludes agent authentication files, API keys, OAuth tokens, credential stores, OS keyring contents, caches, logs, and regenerable dependency directories. Credential and authentication paths cannot be opted back into sync. | Example | Reason | | --- | --- | | `**/auth.json` | May contain API or OAuth material | | `**/.credentials.json` | May contain tokens | | Claude OAuth or keychain material | Device-local credentials | | `node_modules`, `.venv`, caches | Large, regenerable, and non-portable | This boundary does not inspect the semantic meaning of every transcript line. If a tool prints a production secret into an agent conversation, that secret becomes part of the encrypted transcript. Avoid pasting secrets into agent chats and rotate any exposed credential. ## Restore and conflict safety - Use `pull --dry-run` to inspect planned changes before a restore. - Existing local files receive timestamped backups before replacement. - Writes use a temporary file and atomic rename. - Divergent changes create explicit conflict records and forks. - Active Claude Code or Codex processes are refused before mutating session restores. - Artifact metadata and hashes are authenticated and validated before use. ## Threats and boundaries | Threat | Mitigation or boundary | | --- | --- | | Storage provider reads session content | Client-side encryption; remote payload is ciphertext | | Network eavesdropping | TLS plus an already-encrypted payload | | Accidental credential-tree sync | Hard exclusions and narrow adapter discovery | | Overwrite of good local history | Dry-runs, backups, atomic writes, and conflict forks | | Compromised local machine | Out of scope; plaintext is necessarily available during local use | | Malicious or vulnerable release | Checksums and supply-chain controls reduce risk; independent verification is encouraged | ## Audit status and responsible disclosure Reinstate is open source under Apache-2.0, but source availability is not the same as a formal audit. No independent formal audit is claimed for Reinstate. Review the code and threat model before using sensitive transcripts. Report suspected vulnerabilities privately using the repository's[security policy](https://github.com/HarjjotSinghh/reinstate/security/policy). Do not open a public issue for an unpatched vulnerability. ## Security resources [Full threat model](https://reinstate.dev/docs/security-model) [System architecture](https://reinstate.dev/docs/architecture) [Open-source project](https://reinstate.dev/open-source) [Compatibility gates](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/security Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Coding-agent integrations # Coding-Agent Integrations by Support Tier | Reinstate > See Reinstate coding-agent integrations by support tier: T5 encrypted sync, T4 handoff destinations, T2 handoff sources, and T1 discovery. T0 catalog names stay on the matrix. Encrypted sync (T5) covers Claude Code, Codex CLI, and OpenCode, same-vendor. Grok Build and Qwen Code are T4 handoff destinations with same-vendor native resume. Gemini CLI and Kimi Code CLI are T2 handoff sources. T0 catalog agents appear on the matrix with a reason; they do not have integration pages. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Integrations at T1 and above An integration page exists only when the catalog tier is T1 or higher. T0 names belong on the [compatibility matrix](https://reinstate.dev/compatibility), not on a page that implies a working adapter. [### Claude Code T5 · Claude Code to Claude Code (T5 encrypted sync; T3 same-vendor resume) Read Claude Code integration →](https://reinstate.dev/integrations/claude-code)[### OpenAI Codex CLI T5 · Codex to Codex (T5 encrypted sync; T3 same-vendor resume) Read OpenAI Codex CLI integration →](https://reinstate.dev/integrations/codex)[### Gemini CLI T2 · Handoff source only (T2); no native resume Read Gemini CLI integration →](https://reinstate.dev/integrations/gemini)[### OpenCode T5 · OpenCode to OpenCode (T5 encrypted sync; T3 same-vendor resume and fork); OpenCode as a structured handoff destination (T4) Read OpenCode integration →](https://reinstate.dev/integrations/opencode)[### Grok Build T4 · Same-vendor native resume via grok --resume (T3); handoff destination via grok --session-id (T4) Read Grok Build integration →](https://reinstate.dev/integrations/grok)[### Kimi Code CLI T2 · Handoff source only (T2); no native resume Read Kimi Code CLI integration →](https://reinstate.dev/integrations/kimi)[### Pi T1 · Not usable (T1 discover only) Read Pi integration →](https://reinstate.dev/integrations/pi)[### Qwen Code T4 · Qwen Code to Qwen Code (T3 same-vendor resume and fork); Qwen Code as a structured handoff destination (T4) Read Qwen Code integration →](https://reinstate.dev/integrations/qwen)[### Cursor CLI T1 · Not usable (T1 discover only) Read Cursor CLI integration →](https://reinstate.dev/integrations/cursor)[### Cline T1 · Not usable (T1 discover only) Read Cline integration →](https://reinstate.dev/integrations/cline)[### GitHub Copilot CLI T1 · Not usable (T1 discover only) Read GitHub Copilot CLI integration →](https://reinstate.dev/integrations/copilot) ## Catalog tier matrix Breadth is a matrix. Encrypted sync covers Claude Code, Codex CLI, and OpenCode. Grok Build and Qwen Code add handoff destinations without sync. The remaining catalog rows are T2 handoff sources, T1 discover-only agents, or T0 known names. Catalog agent support tiers for integrations | Agent | Family | T0Known | T1Discover | T2Handoff source | T3Verified resume | T4Handoff destination | T5Encrypted sync | Evidence | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Claude Code](https://reinstate.dev/integrations/claude-code) T5 | `F1` Home tree | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [OpenAI Codex CLI](https://reinstate.dev/integrations/codex) T5 | `F1` Home tree | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md) | | [Gemini CLI](https://reinstate.dev/integrations/gemini) T2 | `F1` Home tree | Yes | Yes | Current | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md) | | [OpenCode](https://reinstate.dev/integrations/opencode) T5 | `F3` Embedded DB | Yes | Yes | Yes | Yes | Yes | Current | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md) | | [Grok Build](https://reinstate.dev/integrations/grok) T4 | `F1` Home tree | Yes | Yes | Yes | Yes | Current | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md) | | [Kimi Code CLI](https://reinstate.dev/integrations/kimi) T2 | `F1` Home tree | Yes | Yes | Current | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/kimi.md) | | [Pi](https://reinstate.dev/integrations/pi) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md) | | [Qwen Code](https://reinstate.dev/integrations/qwen) T4 | `F1` Home tree | Yes | Yes | Yes | Yes | Current | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md) | | [Cursor CLI](https://reinstate.dev/integrations/cursor) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cursor.md) | | [Cline](https://reinstate.dev/integrations/cline) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cline.md) | | Roo CodeT0 | `F3` Embedded DB | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/roo.md) | | AiderT0 | `F4` Project file | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/aider.md) | | [GitHub Copilot CLI](https://reinstate.dev/integrations/copilot) T1 | `F1` Home tree | Yes | Current | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/copilot.md) | | AmpT0 | `F5` Remote | server-backed history | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/amp.md) | | OpenHandsT0 | `F5` Remote | server-backed history | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/openhands.md) | | ZCodeT0 | `F5` Remote | desktop-only distribution | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/zcode.md) | | MiniMaxT0 | `F5` Remote | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/minimax.md) | | Antigravity CLIT0 | `F1` Home tree | layout unverified | — | — | — | — | — | [Evidence](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/antigravity.md) | ## What each published tier can do | Capability | Claude Code, Codex CLI, OpenCode (T5) | Grok Build, Qwen Code (T4) | Gemini CLI, Kimi Code CLI (T2) | Pi, Cursor CLI, Copilot CLI, Cline (T1) | | --- | --- | --- | --- | --- | | Local session discovery (T1) | Included | Included | Included, read-only | Included, read-only | | Handoff source (T2) | Included | Included | Included | Not supported | | Same-vendor native resume (T3) | Included | Included | Not supported | Not supported | | Handoff destination (T4) | Included | Included | Not supported | Not supported | | Encrypted push and pull (T5) | Same-vendor sessions | Not supported | Not supported | Not supported | | Native cross-agent translation | Not supported | Not supported | Not supported | Not supported | | MCP, skills, plugins, or settings sync | Later roadmap | Later roadmap | Later roadmap | Later roadmap | Reinstate fails closed for recognized but untested agent versions: discovery can remain read-only, while export and restore are blocked. See the exact ranges and release evidence on the [compatibility page](https://reinstate.dev/compatibility) and see when those ranges changed in the[agent-version history](https://reinstate.dev/compatibility/agent-version-history). ## How a T5 integration moves a session 1. **Discover.** An adapter finds session artifacts in the agent's local, vendor-owned data layout. 2. **Normalize.** Reinstate replaces known structural absolute paths with portable project tokens. It does not rewrite free-form transcript prose. 3. **Encrypt and store.** The portable artifact is sealed locally with age passphrase encryption before it is uploaded to your S3-compatible bucket. 4. **Restore.** On the destination device, Reinstate expands project tokens using that device's configured roots and writes to the native agent layout with backups and conflict handling. 5. **Resume natively.** You continue using the same agent vendor. Reinstate remains a continuity layer, not the place where the agent executes. Native resume is same-vendor only. Reinstate does not silently translate a Claude Code transcript into a Codex rollout or vice versa. Explicit structured handoff starts a *new* Claude Code or Codex session with a visible, lossy checkpoint. ## T0 names are not integrations Roo Code, Aider, Amp, OpenHands, ZCode, MiniMax, and Antigravity CLI are T0. They appear in`rein doctor --agents` with a machine-readable reason such as`layout_unverified`, `server_backed`, or `desktop_only`. That is a complete result, not a preview of sync. Reinstate is independent of Anthropic, OpenAI, Google, xAI, and the other vendors named here. Reading local vendor session files does not imply a partnership, endorsement, or access to vendor accounts. ## Continue exploring [Compatibility matrix](https://reinstate.dev/compatibility) [Security model](https://reinstate.dev/security) [Adapter documentation](https://reinstate.dev/docs/adapters) [Getting started](https://reinstate.dev/docs/getting-started) --- Source: https://reinstate.dev/integrations Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Guides # Guides > Follow verified, answer-first Reinstate guides for encrypted Claude Code and Codex session sync, project path mapping, safe restore, and native resume. Use these step-by-step guides to configure encrypted, same-vendor coding-agent session sync across two devices. Every command is checked against stable Reinstate v0.5.1 and includes dry-run, path-mapping, security, and verification steps. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Session sync guides Start with the coding agent whose session you need to move. Phase 1 preserves each vendor's native format: Claude Code resumes Claude Code sessions, and Codex resumes Codex sessions. [General · 17 min ## Move a Coding-Agent Session from Mac to Windows Move one encrypted Claude Code or Codex session from macOS to native Windows with Reinstate path remapping, dry-runs, backups, and native resume. Read guide →](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows)[Claude Code · 12 min ## How to Sync Claude Code Sessions Across Devices Set up encrypted Claude Code session sync between two computers with Reinstate, including project path mapping, dry runs, restore, and native resume. Read guide →](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices)[Codex CLI · 12 min ## How to Sync Codex Sessions Across Devices Set up encrypted Codex CLI session sync between two computers with Reinstate, including project mapping, dry runs, safe restore, and native resume. Read guide →](https://reinstate.dev/guides/sync-codex-sessions-across-devices)[General · 14 min ## Use Cloudflare R2 for Encrypted Coding-Agent Session Storage Configure a private Cloudflare R2 bucket and bucket-scoped S3 credentials for Reinstate, then verify encrypted Claude Code or Codex storage. Read guide →](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage)[General · 15 min ## Use Amazon S3 for Encrypted Coding-Agent Session Storage Configure a private Amazon S3 bucket and least-privilege credentials for Reinstate, then verify encrypted Claude Code or Codex session storage. Read guide →](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage) ## Start with one harmless session Evaluate Reinstate with a non-sensitive session and an explicit session ID. Confirm the destination mapping in a dry run before a mutating pull, and keep the coding agent closed when replacing an existing local session. ## Before your first transfer [Install and initialize Reinstate](https://reinstate.dev/docs/getting-started) [Check supported agent versions](https://reinstate.dev/compatibility) [Review the security boundary](https://reinstate.dev/security) [Prepare for failure and recovery](https://reinstate.dev/docs/troubleshooting) --- Source: https://reinstate.dev/guides Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Engineering notes # Blog > Read evidence-backed engineering and product articles about coding-agent session continuity, encrypted sync, path portability, and safe native resume. The Reinstate blog explains the engineering boundaries behind coding-agent continuity. Articles distinguish current stable behavior from roadmap work and link claims to the implementation, documentation, or release evidence. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Latest articles [engineering · Aug 27, 2026 ## The transcript is not the session Your session file survives the crash. That is not the same as being able to continue, because a session is a transcript plus the conditions it ran under. Read article →](https://reinstate.dev/blog/the-transcript-is-not-the-session)[engineering · Jul 27, 2026 ## Why Git Alone Does Not Sync Coding-Agent Sessions Git preserves source history, but coding-agent continuity also depends on local conversations, tool context, vendor layouts, paths, and safe restore. Read article →](https://reinstate.dev/blog/why-git-does-not-sync-coding-agent-sessions) ## The editorial contract Product claims are tied to a visible review date and the current release status. Current, planned, and experimental capabilities are labeled separately. Reinstate does not publish fabricated benchmarks, ratings, compatibility results, or cross-agent fidelity claims. ## Explore Reinstate [Step-by-step guides](https://reinstate.dev/guides) [Technical documentation](https://reinstate.dev/docs) [Open-source project](https://reinstate.dev/open-source) [Release changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/blog Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- engineering # The transcript is not the session > Your session file survives the crash. That is not the same as being able to continue, because a session is a transcript plus the conditions it ran under. A coding-agent session is a transcript plus the conditions it ran under: the repository state, the branch, and the environment on the machine. Crash recovery usually returns only the transcript, which is why a resume can succeed and still be wrong. Reinstate verifies those conditions before the agent starts. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** August 27, 2026 - **Updated:** August 27, 2026 - **Reviewed:** August 27, 2026 ## Three failures you have stopped noticing It is Tuesday. You open a terminal in a repository you were deep inside on Friday, start your agent, and type out a paragraph explaining a design the agent itself proposed four days ago. You restate the constraint you already argued through with it. You list the same three files. It starts cold, so you re-explain, and neither of you finds this strange. Second one. You are forty minutes into something hard, the context fills, and compaction runs. What the agent is carrying forward is now a summary of the stretch you argued through, not the stretch itself. Or the terminal dies outright and takes the whole thing with it. Either way you have lost the thread, and the recovery move is identical: open a fresh session and start typing background. Third. The session survives. You pick it up mid-task on Monday, it names four files with total confidence, and two of them moved when you merged `main` on Saturday. It works against the layout written down in the transcript. You find out at the diff. None of these read as failures now. They read as weather. You have priced them in the way you price a slow test suite: an annoyance with a known shape, absorbed into what running agents costs. That pricing is what I want to argue with, because it treats all three as the same problem, and they are not. ## The words were never the thing that went missing Go and look at the crash case. Claude Code and Codex both write the session to a file on your disk as you work: JSON Lines, one event per line, appended live. It keeps being written until the process dies. After the crash that file is still sitting there. A hard kill can cut the final record short, which is why Reinstate’s readers ignore an incomplete trailing line, but the turns before it are intact. The third case is starker. The transcript was perfect. Nothing about it was lost, damaged, or truncated. The repository moved underneath it. Compaction is the one I would not overstate. What a vendor leaves in the file after a compaction is that vendor’s decision, and it differs between them, so I am not going to make a claim about all of them from here. What Reinstate does with the result is fixed: a vendor compaction summary is carried as a summary, labelled as one, never as turns you actually exchanged. So in the crash and the stale-workspace cases the words are on disk, and retrieval is the part that already works. In the compaction case what you lost was never on disk to begin with. It was what the model was holding. In none of the three would getting the text back be enough to continue. What went missing is everything around the words. ## A session is a transcript plus the conditions it ran under Here is the definition I would like to argue for, because most of the confusion in this category comes from not having one. A session is a transcript **plus the conditions it ran under**: which repository, which branch, which working tree, which agent binary, and whether that binary is the one you think it is. Search and preview give you back the first half. They are useful and I would not want to work without them. But the transcript is a set of statements about a world. This file has that shape. That test fails for this reason. Every one of those statements has an expiry date, and the repository sets it, not the file the agent wrote. Continuing correctly needs both halves. Getting your words back is not the same as being able to continue. ## What a preflight actually does before the agent starts Reinstate runs an environment preflight before every same-vendor native continuation. It reports the environment it can actually observe, compares only facts that have trustworthy recorded provenance, and refuses a silent bad continuation instead of guessing. That shipped in `v0.3.0`, and it is the part of this product I would defend hardest. The provenance rule is the whole design. A vendor session file records some things reliably: the workspace, and often a branch. It does not reliably record repository identity, HEAD, working-tree state, or which agent version you were running when the session started. Where there is no trustworthy baseline, the report says `unknown`. It never says `match`. The first time you continue a session that predates any recorded observation, a lot of lines come back `unknown`, and that is the honest answer rather than a poor one. What that means when you are actually at the terminal: a warning holds the launch until you confirm it, or acknowledge each warning by its exact ID, with no wildcards. A different known repository identity is not a warning at all. It is a block, and there is no flag that overrides it. Reinstate is allowed to stop you. Stopping you is the feature. The alternative is not neutral. An agent that continues against a workspace it cannot recognise does not sit there confused. It works, confidently, against statements that stopped being true, and you pay for that in review time and in edits you have to undo. I am not going to put a number on how often that happens or what it costs, because I do not have one I could defend. ## Two words we are strict about: resume and handoff This is the second thing I want to plant, and it matters more than the first because it is where the category is loosest. A **resume** restores a session. It is same-vendor only: Claude Code to Claude Code, Codex to Codex. Those are the two agents Reinstate resumes natively. The vendor’s own native continuation is doing the work; the preflight decides whether starting it is safe. A **handoff** is a different operation with a different name because it is a different thing. It builds an explicit structured capsule and starts a **new** Claude Code or Codex session from it. It does not translate a native session and it does not transfer one. There is no version of this where a Claude Code session becomes a Codex session. Handoff shipped in `v0.4.0`. Since a handoff is lossy, the loss should be legible before you accept it. What the capsule carries: - your messages, verbatim, subject to redaction; - the visible assistant replies, attributed to their source; - tool names, inputs, and outputs, carried as **evidence** and never re-executed; - the current changed files and branch state, read live from Git rather than from the transcript; - attachments by reference: hash, type, size; - vendor compaction summaries, labelled as summaries rather than as turns. What it drops: - pending or unfinished tool calls, closed as interrupted; - hidden or encrypted reasoning state, which is vendor-opaque and not portable; - credentials, tokens, and approvals, which are never read; - live processes, shells, and sandboxes; only observable results carry over. And one thing it deliberately refuses to manufacture. Reinstate does not derive a list of “decisions” or “rejected approaches” from prose, because guessing them produces confident nonsense. They are reported as omitted. Your own recent messages, verbatim, carry that information honestly instead. Every component comes back classified `exact`, `normalized`, `summarized`, `referenced`, or `omitted`, with a reason, and you can see the whole classification in a dry run before anything launches. There is a related rule inside the handoff: where the transcript and the repository disagree, the repository wins. A plan from ninety turns ago does not get to overrule what is on disk now. The drop list is published on purpose. A continuation you cannot audit is worse than one that refuses, because the refusal costs you a minute and the unaudited one costs you a review cycle you did not budget for. The [handoff documentation](https://reinstate.dev/docs/handoff) carries the full table, and [limitations](https://reinstate.dev/docs/limitations) is the page I would read first if you are trying to find the edges rather than the pitch. ## What you can check today without installing anything Your agent’s session files are already on your disk. That is not a Reinstate feature; it is how Claude Code and Codex work. Go and open the directory. The text you thought you lost on Friday is very likely sitting in it. Then ask the question that the text cannot answer for you. Before you continue anything: which branch was this written against, does that repository still have the same identity, is the working tree the one those file paths described, and is the agent binary the same one that produced them? You can almost always get the words back. That was never the question. The question is whether anything those words assumed has changed since. If the answer is yes and you continue anyway, you are asking an agent to act on statements you already know are stale. If you want to see what the checking looks like when it is written down, [restoring a session](https://reinstate.dev/docs/restore-a-session) walks the path, and the source is Apache-2.0, so the check list is readable rather than something you take on faith. Stable is `v0.5.1`, dated 2026-08-21. When a session does move between machines, snapshots are encrypted locally with an age envelope before upload and land in storage you own: S3, Cloudflare R2, or S3-compatible. Auth and credential files are excluded by policy, and there is no Reinstate account anywhere in that path. The mandatory release targets for agent resume today are Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 are optional and unverified, and are not certified Phase 1 agent-resume targets. The transcript was never the hard part. The conditions it assumed are, and nothing in the file will tell you whether they still hold. --- CONTINUE READING ## Related Reinstate resources [How Reinstate works](https://reinstate.dev/about/reinstate) [Structured handoff](https://reinstate.dev/docs/handoff) [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Why Git alone does not sync sessions](https://reinstate.dev/blog/why-git-does-not-sync-coding-agent-sessions) [Architecture](https://reinstate.dev/docs/architecture) --- Source: https://reinstate.dev/blog/the-transcript-is-not-the-session Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-08-27. --- engineering # Why Git Alone Does Not Sync Coding-Agent Sessions > Git preserves source history, but coding-agent continuity also depends on local conversations, tool context, vendor layouts, paths, and safe restore. Git does not automatically sync coding-agent sessions because those conversations and vendor runtime records usually live outside the repository. Even when copied manually, they need compatibility checks, secret exclusions, path remapping, encryption, conflict handling, and native-agent restore. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** July 27, 2026 - **Reviewed:** July 27, 2026 ## Git preserves the repository, not the whole coding session Git is the right source of truth for code and committed project history. It records snapshots of files that belong to a repository, plus the graph of commits that connects them. A coding-agent session contains a different kind of state: the conversation, tool calls, rejected approaches, files already examined, working-directory identity, and vendor-specific resume records. Claude Code and Codex CLI keep their resumable session artifacts in vendor-managed locations under the user’s home directory. Those files are not part of a project repository unless someone deliberately copies or links them into it. A normal `git push` therefore sends the repository history but leaves the native agent session on the original machine. This distinction is why a clean checkout on a second computer can contain every commit and still force the agent to rebuild the task context from scratch. ## What is missing after a normal Git pull Suppose a developer commits a refactor on a Windows workstation and opens the repository on a MacBook. Git can restore: - committed source files; - branches, tags, and commit ancestry; - repository-tracked instructions and configuration; and - any other file intentionally added to that repository. Git does not automatically restore: - the Claude Code or Codex conversation that led to those edits; - uncommitted agent reasoning or decisions preserved only in a session; - vendor-native resume identifiers and rollout layout; - the mapping between the Windows and macOS checkout paths; - session-specific conflict and restore state; or - credentials and encryption material, which should not be committed at all. That does not make Git incomplete. It means source history and agent-session continuity are separate responsibilities. ## Why committing raw session files is not a safe general solution Git can technically track any file placed inside a repository. That capability does not make a vendor session store suitable project content. ### Sessions can contain sensitive material Coding-agent transcripts may include source excerpts, architecture decisions, terminal output, and secrets that a person or tool printed during the session. Committing that material can spread it to every clone, fork, cache, and backup that receives the repository. Reinstate’s [security contract](https://reinstate.dev/docs/security-model) treats transcripts as high-sensitivity data. It encrypts selected session artifacts before upload and hard-excludes known authentication and credential paths. Encryption does not excuse putting secrets into transcripts, but it avoids turning session continuity into plaintext repository history. ### Vendor layouts are not portable repository formats Claude Code and Codex use different native session layouts. Their resume paths are agent-specific, and compatibility can change across agent versions. Reinstate uses separate [Claude Code and Codex adapters](https://reinstate.dev/docs/adapters) to discover, export, validate, and restore only the supported native artifacts. A raw directory committed on one machine has no mechanism to establish that the destination’s installed agent understands that layout. Reinstate reports `SUPPORTED`, `UNTESTED`, `UNSUPPORTED`, or `NOT_INSTALLED` and blocks writes when a recognized layout lacks release evidence. ### Absolute project paths change between devices A repository might be `C:\src\app` on Windows and `/Users/dev/src/app` on macOS. Claude Code derives project storage from the local project path, while a Codex rollout records its working directory in structural session metadata. Copying the bytes does not make either source path valid on the destination. Reinstate’s path-mapping layer gives the repository a canonical project ID. Its adapters normalize allow-listed structural paths during export and expand them through the destination’s local mapping during restore. Ordinary prose is preserved rather than rewritten merely because it looks like a path. ### Concurrent histories need session-aware conflict behavior Two devices can both advance a session while offline. Git can represent conflicting text changes, but a vendor-native session log is not ordinary source code that a generic line merge can safely repair. Reinstate uses revision metadata, dry runs, backups, active-session checks, and conflict records to avoid silently replacing one history with another. The user decides how to resolve divergence instead of receiving a syntactically merged transcript with unknown resume semantics. ## The evidence in Reinstate’s implementation Reinstate’s current repository separates these responsibilities explicitly: | Concern | Repository evidence | What it establishes | | --- | --- | --- | | Vendor discovery and restore | [`internal/adapter`](https://github.com/HarjjotSinghh/reinstate/tree/main/internal/adapter) | Claude Code and Codex session formats are handled through distinct adapters. | | Portable project identity | [`internal/pathmap`](https://github.com/HarjjotSinghh/reinstate/tree/main/internal/pathmap) | Known structural paths can be normalized and restored per device. | | Client-side encryption | [`internal/crypto`](https://github.com/HarjjotSinghh/reinstate/tree/main/internal/crypto) | Remote snapshots are encrypted with a passphrase-derived age recipient. | | Transfer and conflict state | [`internal/sync`](https://github.com/HarjjotSinghh/reinstate/tree/main/internal/sync) | Push, pull, manifests, revisions, backups, and conflicts belong to a sync protocol. | | Product boundary | [`ROADMAP.md`](https://github.com/HarjjotSinghh/reinstate/blob/main/ROADMAP.md) | Git remains source truth; Reinstate is responsible for context continuity. | The public `v0.1.0` scope is deliberately narrower than the full roadmap: same-vendor Claude Code and Codex session sync. Local universal search, cross-agent portable handoffs, and universal agent configuration are later phases, not hidden features of the current CLI. ## Git and Reinstate are complementary The practical workflow uses both tools: 1. Use Git to commit and exchange source history. 2. Use Reinstate to encrypt and transfer the selected native coding-agent session. 3. Map the same canonical project ID to the repository’s real path on each device. 4. Pull with a dry run, restore safely, and resume through the same vendor’s native CLI. Git answers, “Which code and commits belong to this project?” Reinstate answers, “Which coding-agent context should be restored, and is this environment safe and compatible enough to continue it?” Reinstate does not replace Git, host a code editor, or execute the agent loop. It is a continuity layer before and after coding-agent execution. ## When Git alone is enough Git may be all you need when the important context is already captured in commits, issues, design documents, and repository instructions, and you do not need to resume a native coding-agent conversation. Session sync becomes useful when the unfinished task depends on conversation state that is expensive to reconstruct, when project paths differ across devices, or when you want an encrypted transfer with explicit compatibility and conflict checks. For a current, command-by-command example, follow the [Claude Code guide](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices) or the [Codex guide](https://reinstate.dev/guides/sync-codex-sessions-across-devices). CONTINUE READING ## Related Reinstate resources [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Codex CLI integration](https://reinstate.dev/integrations/codex) [How Reinstate works](https://reinstate.dev/about/reinstate) [Claude Code session sync guide](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices) [Codex session sync guide](https://reinstate.dev/guides/sync-codex-sessions-across-devices) [Security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/blog/why-git-does-not-sync-coding-agent-sessions Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-07-27. --- Changelog # Reinstate Changelog and Release Notes > Read Reinstate release notes, including v0.6.0-rc.6 compatibility, path mapping, restore verification, security, and installer changes. The latest published Reinstate tag is v0.6.0-rc.6, dated September 8, 2026. v0.6.0-rc.6 is a release candidate, not the current stable release: stable remains v0.5.1. It carries Reinstate Hop (cloud continuity) and the interactive CLI experience on top of verified resume, structured handoff, and universal agent coverage; its acceptance is native Windows x64 only, with Apple Silicon macOS deferred. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Unreleased Current unreleased website work adds the SEO, answer-engine, AI-search, and social-preview foundation and introduces signed `website-vYYYY.MM.DD.N` deployment tags. A website tag can publish reviewed site changes from current `main` while the public CLI and installer routes remain pinned to the separately signed `v0.6.0-rc.6`release. It is not a new Reinstate version or evidence for any platform outside the documented release boundary. The repository's[canonical CHANGELOG.md](https://github.com/HarjjotSinghh/reinstate/blob/main/CHANGELOG.md) is authoritative if this summary and the current branch differ. ## v0.6.0-rc.6 · September 8, 2026 `v0.6.0-rc.6` is a release candidate, not the current stable release: stable remains `v0.5.1`. Public installers currently pin this candidate while its own acceptance run is pending, not stable. Its acceptance is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. ### Reinstate Hop - Every hosted journey ships as an ordinary `rein` command, with no build tag or feature flag: `rein login` / `rein whoami` (passwordless sign-in),`rein init --hop` and `rein account init` / `recover` /`join` / `status` (the locker and the keyring),`rein devices` / `approve` / `revoke` (pairing and revocation), `rein hop status` / `rein hop credentials`,`rein sync verify`, `rein sync migrate --to byo`, and`rein daemon` (a resident sync process; launchd on macOS, systemd`--user` on Linux, Task Scheduler on Windows). - **The hosted control plane is not open.** The default control-plane URL,`https://hop.reinstate.dev`, does not resolve yet; `rein login`against it reports that in one sentence instead of hanging, and`REINSTATE_HOP_URL` / `[hop] url` point the client at a control plane you run yourself or a staging instance. No pricing, billing, trial, or sign-up ships in this release. - OpenCode reaches **T5, encrypted sync** — the first embedded-SQLite agent to sync — and Kimi Code CLI reaches **T2, a handoff source**. - See [the Hop documentation](https://reinstate.dev/docs/hop) for the full sign-in, device, and locker walkthrough. ### The interactive CLI experience Carried unchanged from `v0.5.2-rc.1`, which this candidate supersedes without a separate stable tag: - Bare `rein` opens an interactive session switcher with a readiness verdict per row; a warning checklist replaces retyped `--allow-environment-warning`identifiers; a handoff studio previews every policy; `rein init` becomes a wizard with `--link` / `--paste` pairing codes; `ctrl+k`opens a command palette. - Every `--json` document and non-TTY byte stream stays byte-identical to`v0.5.1`; `--plain` and`REINSTATE_NO_TUI` freeze the old output. - OpenCode and Grok Build gain verified native resume; OpenCode, Grok Build, and Qwen Code become handoff destinations alongside Claude Code and Codex. ### Continuity and privacy boundary - Native execution remains same-vendor; Reinstate does not translate transcripts across agents. - The Hop locker holds ciphertext plus one documented plaintext object,`keyring.v1.json`; credentials are never synced. - Stable `v0.5.1` verified resume, local continuity, structured handoff, and encrypted sync remain available and unchanged. ### Acceptance boundary - This candidate's acceptance runs on native Windows x64 (`windows/amd64`, never WSL) only. Apple Silicon macOS acceptance is deferred until that hardware returns; nothing here implies a macOS result. - Verified compatibility ranges widen on native Windows physical resume evidence and are marked "Windows evidence; macOS pending" until the deferred run lands. See the[compatibility matrix](https://reinstate.dev/compatibility). - Passing this candidate's Windows run does not by itself authorize stable`v0.6.0`; the deferred macOS rows and the promotion decision are recorded separately. [View the v0.6.0-rc.6 tag on GitHub](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6). ## Release-candidate history | Release | Date | Primary focus | | --- | --- | --- | | [v0.6.0-rc.6](https://reinstate.dev/changelog#v0-6-0-rc-6) | 2026-09-08 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Corrective candidate after v0.6.0-rc.5 tagged-artifact acceptance on native Windows x64, plus two same-artifact rechecks, ended device verdict FAIL (211 PASS / 4 PARTIAL / 0 FAIL / 0 NOT TESTED of 215 required rows, zero product defects; the four PARTIAL rows were grok:E1/E2/E3, live backend connectivity to xAI compounded by the host's grok self-updating to 1.0.13 outside the verified 1.0.5 range, and MatrixH:H7, the daemon round-trip mechanism completing on both rechecks but its digest-equality pass condition proving unmeasurable on a live, multi-session host). This candidate changes exactly two things: the verified Grok Build range widens to 1.0.13 on the maintainer's own console evidence, since the pinned 1.0.5 binary no longer completes a prompt against xAI from any console; and MatrixH:H7's live-home check is refined from aggregate digest equality to a full per-file before/after listing of the session-bearing subtrees with per-entry attribution. Because Grok cannot be driven to a completed turn from this harness, the completed-turn grok:E1-E3 rows against 1.0.13 are executed by the maintainer at their own console in this candidate's tagged run. Nothing else changes: no other agent tier moves, no other compatibility range widens. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. | | [v0.6.0-rc.5](https://reinstate.dev/changelog#v0-6-0-rc-5) | 2026-09-07 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Corrective candidate after v0.6.0-rc.4 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (208 PASS / 1 PARTIAL / 4 FAIL / 2 NOT TESTED of 215 required rows; both of that candidate's own fixes, the Pi reader and the widened Qwen Code range, were confirmed). That run found two new confirmed redaction/correctness gaps in the agent probe (MatrixB:B4, real project-name path segments reaching a committed artifact unshaped; MatrixB:B7, an existing-but-empty overridden agent root indistinguishable from an absent one), a stale sync-completion contract sentence (MatrixG:G4, scored against unchanged shipped behavior), a confirmed interactive-CLI defect (CLI row 13, the switcher's default all-projects scope showing every visible row as unresumable regardless of true state), a host version-compatibility block (OpenCode self-updated to 1.18.29, above the verified 1.18.27 ceiling), and an operator/elevation-availability gap (MatrixH:H7). This candidate changes exactly these things: probe shape normalization at every tree depth with root state reported (closes B4/B7), the switcher's all-projects readiness (closes row 13), the verified OpenCode range widens to 1.18.21-1.18.29 on native Windows evidence, and the G4/H7 contract text is corrected. Nothing else changes: no other agent tier moves, no other compatibility range widens. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. Published and tagged: native Windows tagged-artifact acceptance, plus two same-artifact rechecks, ended device verdict FAIL (211 PASS / 4 PARTIAL / 0 FAIL / 0 NOT TESTED of 215 required rows); zero product defects. It found a live grok backend-connectivity gap compounded by a grok version drift to 1.0.13, and an H7 disposition whose digest-equality pass condition proved unmeasurable on a live host; both addressed in v0.6.0-rc.6. Does not authorize stable v0.6.0. | | [v0.6.0-rc.4](https://reinstate.dev/changelog#v0-6-0-rc-4) | 2026-09-07 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Corrective candidate after v0.6.0-rc.3 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (201 PASS / 3 PARTIAL / 1 FAIL / 10 NOT TESTED of 215 required rows; all 22 CLI rows and all 16 Hop rows passed, and the Cursor CLI store-schema fix was confirmed on real data). That run found a confirmed code defect (pi:C3: the Pi reader handed the whole message object to the shared text-flattening helper instead of message.content, so prompt\_preview and search text were silently empty for every real, version-3 Pi session) and a version-compatibility block (the host Qwen Code self-updated to 0.23.0, above the verified 0.21.13 ceiling, correctly refusing ten rows). This candidate changes exactly two things: the Pi reader now reads message.content (indexing only user-turn text, matching the Claude and Codex readers), and the verified Qwen Code range widens to 0.21.12-0.23.0 on native Windows physical-resume evidence. Nothing else changes: no other agent tier moves, no other compatibility range widens. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. Published and tagged: native Windows tagged-artifact acceptance ended device verdict FAIL (208 PASS / 1 PARTIAL / 4 FAIL / 2 NOT TESTED of 215 required rows); both of this candidate's own fixes, the Pi reader and the widened Qwen Code range, were confirmed on real data. It found a probe redaction gap, an empty-vs-absent override root gap, a stale sync-completion contract sentence, the switcher's all-projects readiness defect, an OpenCode version-compatibility block, and an operator-availability gap on MatrixH:H7; corrective fixes land in v0.6.0-rc.5. Does not authorize stable v0.6.0. | | [v0.6.0-rc.3](https://reinstate.dev/changelog#v0-6-0-rc-3) | 2026-09-07 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Corrective candidate after v0.6.0-rc.2 tagged-artifact acceptance on native Windows x64 ended device verdict FAIL (203 PASS / 5 PARTIAL / 2 FAIL / 5 NOT TESTED of 215 required rows; all 22 CLI rows and 15 of 16 Hop rows passed). A post-commit, schema-only inspection of two real Cursor CLI 2026.08.11 store.db files found blobs(id, data)/meta(key, value) tables, not the messages/message/bubbles shape the v0.6.0-rc.2 Cursor reader guessed at and no real store ever had, so real Cursor CLI sessions kept reporting message\_count 0 and were not found by search despite cursor:C2/cursor:C3 being marked fixed. This candidate changes exactly the Cursor CLI store reader to read that real schema and nothing else: no agent tier changes, no compatibility range widens. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. Published and tagged: native Windows tagged-artifact acceptance ended device verdict FAIL (201 PASS / 3 PARTIAL / 1 FAIL / 10 NOT TESTED of 215 required rows); all 22 CLI rows and all 16 Hop rows passed, and this candidate's own Cursor CLI store-schema fix was confirmed on real data. It found a new Pi reader defect (pi:C3) and a Qwen Code version-compatibility block (host self-updated to 0.23.0, above the verified ceiling); both are addressed in v0.6.0-rc.4. Does not authorize stable v0.6.0. | | [v0.6.0-rc.2](https://reinstate.dev/changelog#v0-6-0-rc-2) | 2026-09-07 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Corrective candidate after v0.6.0-rc.1 tagged-artifact acceptance on native Windows x64 found 7 required-row failures (201 of 216 rows passed): fixes Cursor CLI session discovery, search, inspect, resume, and fork so CURSOR\_CONFIG\_DIR isolates every command path, not only doctor --agents, plus a conformance check that catches the same class of gap; computes Cline and Cursor message\_count from each vendor's own message-bearing store instead of hard-coding 0, and corrects Cursor size\_bytes; wires shell-completion candidates for push --agent and pull --agent; makes an OpenCode-sourced handoff deterministic across repeated dry runs by hashing only the session's own rows instead of the whole shared database; and adds committed Windows-shaped partial-final-record fixtures plus a pipeline-level truncation test for Claude Code, Codex, and Grok Build. No agent tier changes. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. Published and tagged: native Windows tagged-artifact acceptance ended device verdict FAIL (203 PASS / 5 PARTIAL / 2 FAIL / 5 NOT TESTED of 215 required rows, after a post-commit finding re-scored the real-data Cursor CLI rows); the Cursor CLI store-schema defect it found is fixed in v0.6.0-rc.3. Does not authorize stable v0.6.0. | | [v0.6.0-rc.1](https://reinstate.dev/changelog#v0-6-0-rc-1) | 2026-09-06 | Release candidate; stable remains v0.5.1 and this candidate does not by itself authorize promoting it. Carries Reinstate Hop as ordinary rein commands, unconditional on every install: rein login/whoami, an init --hop wizard with --link/--paste pairing, hop status/credentials, account init/recover/join/status, devices/approve/revoke, sync verify, sync migrate --to byo, and a background daemon. OpenCode reaches encrypted sync (T5) and Kimi Code CLI becomes a handoff source (T2). The hosted control plane itself is not deployed, so rein login against the default control-plane URL reports that in one sentence instead of hanging, the URL stays configurable for labs and self-hosters, and no pricing, billing, or sign-up ships. Also carries the interactive CLI experience from v0.5.2-rc.1 unchanged, with every --json document and non-TTY stream still byte-identical to v0.5.1. Acceptance for this candidate is native Windows x64 only; the Apple Silicon macOS run is deferred until that hardware returns and is not claimed here. Published and tagged: native Windows tagged-artifact acceptance ended at 201 of 216 required rows PASS, with every Hop and CLI-experience row passing; the 7 failing rows are fixed in v0.6.0-rc.2. Does not authorize stable v0.6.0. | | [v0.5.2-rc.1](https://reinstate.dev/changelog#v0-5-2-rc-1) | 2026-08-23 | Release candidate; stable remains v0.5.1 and the public installers still pin it. Bare rein opens an interactive session switcher with a readiness verdict per row, a handoff studio, a setup wizard, and a ctrl+k palette, while every --json document stays byte-identical and --plain or REINSTATE\_NO\_TUI restores the frozen output. OpenCode, Grok Build, and Qwen Code become handoff destinations, so rein handoff --to reaches five agents instead of two; OpenCode and Grok Build also gained verified native resume. The interactive surfaces have development verification on both platforms but no tagged-artifact acceptance, which is what this candidate exists to enable. | | [v0.5.1](https://reinstate.dev/changelog#v0-5-1) | 2026-08-21 | Patch release. Updates the pure-Go SQLite driver behind the session index and the OpenCode embedded store from 1.55.0 to 1.56.0. No product code changed. The storage rows were re-run on both platforms against the new driver rather than assumed inert: no write-ahead or shared-memory sidecar is created under an agent root, and an index written by the previous driver is read by this one and back again without losing a row. | | [v0.5.0](https://reinstate.dev/changelog#v0-5-0) | 2026-08-21 | Stable Phase 5 release. Universal agent coverage: a catalog of 18 agents, rein doctor --agents with a redacted AGENT-PROBE-V1 artifact, six T1 discover agents, three T2 handoff sources, and Claude Code and Codex as the only native resume and sync surfaces. Authorized by dual-platform tagged-artifact acceptance on v0.5.0-rc.6: Apple Silicon macOS PASS and native Windows x64 PASS across the full 150-row matrix. | | [v0.5.0-rc.6](https://reinstate.dev/changelog#v0-5-0-rc-6) | 2026-08-21 | Sixth Phase 5 candidate. Physical v0.5.0-rc.5 tagged-artifact acceptance failed one required row: the agent probe carried a raw 38-character Git object hash into its artifact, because the shape normalizer recognised only exactly 32, 40 and 64 characters and OpenCode keeps a Git object store under each snapshot. Those names are content hashes of the repository being worked in. Any hex run long enough to identify content is now collapsed. Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.5.0-rc.5](https://reinstate.dev/changelog#v0-5-0-rc-5) | 2026-08-21 | Fifth Phase 5 candidate. Carries eight fixes found by physical dual-platform acceptance: an index that never re-read a source after Reinstate itself changed, so every reader fix stayed invisible; Gemini project paths recorded in a different case than they are hashed in; an agent root override that was ignored when it named a missing path; incremental refresh; and Windows portability of the documentation tests. Raises the verified ranges to Claude Code 2.1.238 and Codex CLI 0.149.0 on dual-platform physical resume evidence. Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.5.0-rc.4](https://reinstate.dev/changelog#v0-5-0-rc-4) | 2026-08-20 | Fourth Phase 5 candidate. Physical rc.3 acceptance found the agent probe was not reproducible between runs, raw content hashes reached probe output, resume reported the wrong exit code for a T0 agent, an agent-filtered query scanned every source, and completion offered no agent keys. Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.5.0-rc.3](https://reinstate.dev/changelog#v0-5-0-rc-3) | 2026-08-20 | Third Phase 5 candidate. Restores Kimi, Copilot, and OpenCode session discovery after those vendor CLIs changed their on-disk formats, so per-agent project truth is correct again on both platforms. Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.5.0-rc.2](https://reinstate.dev/changelog#v0-5-0-rc-2) | 2026-08-19 | Second Phase 5 candidate after v0.5.0-rc.1 dual-platform tagged-artifact acceptance FAILED. Projection now pairs tool\_result with its tool\_call so Codex handoff dry-run capsules validate. Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.5.0-rc.1](https://reinstate.dev/changelog#v0-5-0-rc-1) | 2026-08-19 | First Phase 5 candidate: agent catalog, doctor --agents, six T1 discover agents, three T2 handoff sources. Dual-platform tagged-artifact acceptance FAILED (macOS 88/150, Windows 93/150). Does not authorize stable v0.5.0. Current stable remains v0.4.0. | | [v0.4.0](https://reinstate.dev/changelog#v0-4-0) | 2026-08-16 | Phase 4 stable: explicit structured handoff into a new Claude Code or Codex session after dual-platform v0.4.0-rc.11 tagged-artifact acceptance PASS (macOS 44/44, Windows 44/44). | | [v0.4.0-rc.11](https://reinstate.dev/changelog#v0-4-0-rc-11) | 2026-08-15 | Eleventh Phase 4 candidate after v0.4.0-rc.10 physical dual-platform acceptance FAILED (macOS 41/44 A1/A3/A7, Windows 40/44 A1/A2/A3/A5; dest first-reply, lineage-after-launch, dest folder-trust). Dual-platform tagged-artifact acceptance later PASS (macOS 44/44, Windows 44/44); promoted to stable v0.4.0. | | [v0.4.0-rc.10](https://reinstate.dev/changelog#v0-4-0-rc-10) | 2026-08-15 | Tenth Phase 4 candidate after v0.4.0-rc.9 physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44; dest-ack A4 PASS, A1/A2/A3/A5/A6/A7 FAIL; Windows CreateProcess truncated multi-line dest argv). Physical dual-platform acceptance FAILED: macOS 41/44 A1/A3/A7, Windows 40/44 A1/A2/A3/A5; remaining product defects dest first-reply, lineage-after-launch, dest folder-trust. | | [v0.4.0-rc.9](https://reinstate.dev/changelog#v0-4-0-rc-9) | 2026-08-15 | Ninth Phase 4 candidate after v0.4.0-rc.8 physical dual-platform acceptance FAILED (macOS 38/44, Windows 38/44; Windows inspect JSON agent.status=not\_installed despite layout\_recognized=true). Physical dual-platform acceptance FAILED: macOS 38/44, Windows 38/44; remaining product defect was Windows dest argv CR/LF truncation. | | [v0.4.0-rc.8](https://reinstate.dev/changelog#v0-4-0-rc-8) | 2026-08-15 | Eighth Phase 4 candidate after v0.4.0-rc.7 physical dual-platform acceptance FAILED (macOS 38/44, Windows 34/44; R1 off-PATH Inspect StatusNotInstalled before layout scan). Pins Go 1.25.13 for govulncheck. Physical dual-platform acceptance FAILED: macOS 38/44, Windows 38/44; remaining product defect was Windows inspect JSON not\_installed. | | [v0.4.0-rc.7](https://reinstate.dev/changelog#v0-4-0-rc-7) | 2026-08-15 | Seventh Phase 4 candidate after v0.4.0-rc.6 physical dual-platform acceptance FAILED (Windows WMI busy-check cascade; C8/R6 2.1.230 fail-open; R4 leftover Runtime). Physical dual-platform acceptance FAILED: macOS 38/44, Windows 34/44; remaining product defect was R1 off-PATH Inspect. | | [v0.4.0-rc.6](https://reinstate.dev/changelog#v0-4-0-rc-6) | 2026-08-14 | Sixth Phase 4 candidate after v0.4.0-rc.5 physical dual-platform acceptance FAILED (dest-ack/picker without a console; C4 remapped fixture/foreign workspaces onto any git cwd). Physical dual-platform acceptance FAILED: Windows Plan rows died on a ~305s WMI busy-check; macOS was 37 PASS / 7 FAIL. | | [v0.4.0-rc.5](https://reinstate.dev/changelog#v0-4-0-rc-5) | 2026-08-13 | Fifth Phase 4 candidate after v0.4.0-rc.4 physical dual-platform acceptance FAILED (Windows R4 hang 43s, F8 ~6s non-TTY delay, B6 summarized missing, C5 Windows os-roots exit 5). Physical dual-platform acceptance FAILED. | | [v0.4.0-rc.4](https://reinstate.dev/changelog#v0-4-0-rc-4) | 2026-08-13 | Fourth Phase 4 candidate after v0.4.0-rc.3 physical dual-platform acceptance FAILED (empty dest home UNTESTED blocking flagship A, hanging --version, Windows make verify, G3 list n=0, B6 missing summarized). Physical dual-platform acceptance FAILED. | | [v0.4.0-rc.3](https://reinstate.dev/changelog#v0-4-0-rc-3) | 2026-08-13 | Third Phase 4 candidate after v0.4.0-rc.2 physical dual-platform acceptance FAILED (wrong-repo cwd, non-TTY spawn, Grok-source busy-check, timed-out probe classified Runtime). Physical dual-platform acceptance FAILED. | | [v0.4.0-rc.2](https://reinstate.dev/changelog#v0-4-0-rc-2) | 2026-08-13 | Second Phase 4 candidate after v0.4.0-rc.1 physical acceptance FAILED: Claude source version probing, path tokenization, live changed-file reporting, probe-timeout classification, and prose-vs-path capsule validation are fixed. Physical dual-platform acceptance FAILED. | | [v0.4.0-rc.1](https://reinstate.dev/changelog#v0-4-0-rc-1) | 2026-08-12 | First Phase 4 candidate: explicit structured handoff of the same task into a new Claude Code or Codex session. Dual-platform tagged-artifact acceptance is pending. | | [v0.3.0](https://reinstate.dev/changelog#v0-3-0) | 2026-08-11 | Phase 3 stable: verified resume for Claude Code and Codex after dual-platform RC7 acceptance PASS. | | [v0.3.0-rc.7](https://reinstate.dev/changelog#v0-3-0-rc-7) | 2026-08-11 | Phase 3 candidate after RC6 dual FAIL: packages non-TTY fail-closed, Windows Ctrl+C safety, capability probe demotion, isolated agent homes, and expanded local Phase 3 smoke for retest. | | [v0.3.0-rc.6](https://reinstate.dev/changelog#v0-3-0-rc-6) | 2026-08-11 | Phase 3 candidate that widens Claude Code through 2.1.227 and Codex CLI through 0.147.0 after RC5 host-version acceptance failures. | | [v0.3.0-rc.5](https://reinstate.dev/changelog#v0-3-0-rc-5) | 2026-08-08 | Corrective Phase 3 candidate after RC4 stayed unpublished: portable PowerShell artifact verification with the Windows-first product fixes intact. | | [v0.3.0-rc.4](https://reinstate.dev/changelog#v0-3-0-rc-4) | 2026-08-08 | Windows-first Phase 3 candidate whose signed-tag workflow failed before publication during Ubuntu PowerShell artifact verification. | | [v0.3.0-rc.3](https://reinstate.dev/changelog#v0-3-0-rc-3) | 2026-08-07 | Corrective Phase 3 candidate after RC2 Windows FAIL; native Windows acceptance still failed on PowerShell 5.1 staging and human-output privacy. | | [v0.3.0-rc.2](https://reinstate.dev/changelog#v0-3-0-rc-2) | 2026-08-07 | Corrective Phase 3 candidate after RC1 Windows FAIL. Apple Silicon progress recorded; native Windows tagged-artifact acceptance failed (Codex trust and snapshot/PS gates). | | [v0.3.0-rc.1](https://reinstate.dev/changelog#v0-3-0-rc-1) | 2026-08-05 | First Phase 3 verified-resume candidate. Apple Silicon macOS tagged-artifact acceptance passed; native Windows x64 failed (not stable). | | [v0.2.0](https://reinstate.dev/changelog#v0-2-0) | 2026-08-05 | Stable Phase 2 local continuity on verified Apple Silicon macOS and native Windows x64; Intel macOS and Linux/WSL2 artifacts remain preview. | | [v0.2.0-rc.3](https://reinstate.dev/changelog#v0-2-0-rc-3) | 2026-08-02 | Package-manager distribution candidate with verified npm, JSR, Homebrew, Scoop, Chocolatey, WinGet, AUR, and native Linux payload generation. | | [v0.2.0-rc.2](https://reinstate.dev/changelog#v0-2-0-rc-2) | 2026-08-02 | Full release-artifact commit provenance and deterministic native-Windows verification gates. | | [v0.2.0-rc.1](https://reinstate.dev/changelog#v0-2-0-rc-1) | 2026-08-01 | Phase 2 local index, literal search, metadata inspect, switcher, and same-vendor resume/fork release candidate. | | [v0.1.0](https://reinstate.dev/changelog#v0-1-0) | 2026-07-30 | First stable release. Phase 1 two-device acceptance passed on v0.1.0-rc.8, whose product code this ships unchanged. | | [v0.1.0-rc.8](https://reinstate.dev/changelog#v0-1-0-rc-8) | 2026-07-29 | Session liveness detection that no longer depends on an open file handle. | | [v0.1.0-rc.7](https://reinstate.dev/changelog#v0-1-0-rc-7) | 2026-07-28 | Session-scoped restore safety that no longer blocks on unrelated running agents. | | [v0.1.0-rc.6](https://reinstate.dev/changelog#v0-1-0-rc-6) | 2026-07-27 | Canonical project mapping, exact restore checks, and remote-manifest validation. | | [v0.1.0-rc.5](https://reinstate.dev/changelog#v0-1-0-rc-5) | 2026-07-27 | Safer re-initialization, joined-profile checks, and bounded installer confirmation. | | [v0.1.0-rc.4](https://reinstate.dev/changelog#v0-1-0-rc-4) | 2026-07-26 | Destination-aware Claude paths and portable Codex structural paths. | | [v0.1.0-rc.3](https://reinstate.dev/changelog#v0-1-0-rc-3) | 2026-07-26 | Tested version ranges, fail-closed setup checks, and a dependency security patch. | | [v0.1.0-rc.2](https://reinstate.dev/changelog#v0-1-0-rc-2) | 2026-07-25 | Signed-tag verification correction. | | [v0.1.0-rc.1](https://reinstate.dev/changelog#v0-1-0-rc-1) | 2026-07-25 | Initial Phase 0 and Phase 1 release-candidate foundation. | ## What the first release candidate established RC1 introduced the Cobra CLI, versioned local state, device detection, diagnostics, verified installers, S3-compatible storage, age encryption, path mapping, manifests, push and pull, conflicts, Claude Code and Codex adapters, native keyring credentials, restore backups, and the synthetic compatibility-test foundation. It also established `rein` as the short alias for the `reinstate` binary. ## How to read pre-1.0 release notes Release candidates were published for testing before stable v0.1 certification, which v0.1.0 completed. Read every intermediate release note before replacing a binary because compatibility behavior, session artifact formats, setup validation, and release gates may still change. - Pin an explicit release in automated setup. - Verify checksums before installing. - Run `rein setup check` after agent or Reinstate upgrades. - Use pull dry-runs and maintain independent backups of important work. ## Release resources [All source tags](https://github.com/HarjjotSinghh/reinstate/tags) [Compatibility matrix](https://reinstate.dev/compatibility) [Install Reinstate](https://reinstate.dev/docs/getting-started) [Source and contributions](https://reinstate.dev/open-source) --- Source: https://reinstate.dev/changelog Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Factual comparisons # Compare Reinstate with Git and Session-Transfer Workflows > Compare Reinstate with manual session copying, remote desktop, and Git using sourced facts, explicit limitations, and current release evidence. Reinstate handles a narrow job: moving supported, vendor-native Claude Code and Codex session artifacts between devices through encrypted storage you control. These comparisons explain where that job overlaps with manual copying, remote desktop, and Git—and where those workflows solve a different problem. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Compare the workflows [### Reinstate vs. manual session copying Compare discovery, path handling, encryption, credential exclusions, backups, and conflict handling. Read the comparison →](https://reinstate.dev/compare/reinstate-vs-manual-session-copying)[### Reinstate vs. remote desktop Compare transferring session state with controlling the computer where that state already lives. Read the comparison →](https://reinstate.dev/compare/reinstate-vs-remote-desktop)[### Reinstate vs. Git Understand why source history and coding-agent conversation continuity are complementary layers. Read the comparison →](https://reinstate.dev/compare/reinstate-vs-git) ## Choose by the job you need done | Need | Workflow to evaluate | Reason | | --- | --- | --- | | Version and collaborate on repository content | Git | Git records repository objects and project history. | | Operate the exact environment on another computer | Remote desktop | The work continues on the host machine while you control it remotely. | | Copy any session format you understand | Manual copying | You control every included file and every transport decision. | | Resume a supported native session on another local machine | Reinstate | Reinstate automates supported discovery, path remapping, encryption, transfer, and native restore. | ## How to read these comparisons - **They compare workflows, not brands.** “Remote desktop” and “manual copying” cover many implementations, so claims stay narrow and conditional. - **Reinstate claims are release-specific.** Capability statements describe the current stable release and link to compatibility or architecture evidence. - **No score is a universal verdict.** The right choice depends on whether you need source control, remote control, arbitrary file transfer, or native session continuity. - **Complementary tools can be used together.** Reinstate does not replace Git, repository hosting, backups, or access to a remote development machine. Current scope: same-vendor session continuity. Reinstate restores Claude Code sessions to Claude Code and Codex sessions to Codex. It does not translate transcripts between agents, synchronize repository changes, or provide remote desktop access. ## Evidence and verification Sources below were reviewed on September 7, 2026. Reinstate claims describe v0.6.0-rc.6; external workflow claims are limited to what the linked primary sources document. - [Reinstate compatibility matrix](https://reinstate.dev/compatibility) Supported agents, operating systems, storage backends, tested versions, and release gates. - [Reinstate architecture](https://reinstate.dev/docs/architecture) The adapter, path-normalization, encryption, storage, and native-restore boundaries. - [Reinstate security model](https://reinstate.dev/docs/security-model) Credential exclusions, encryption, backup, conflict, and local-machine boundaries. ### Limits of this comparison - The comparisons do not benchmark speed, cost, reliability, or user satisfaction. - Remote desktop products and manually designed transfer systems vary; product-specific behavior must be checked with its vendor or operator. - Reinstate v0.5.1 is stable pre-1.0 software on its verified platforms, and its interfaces or storage formats may change before v1.0. ## Verify the product boundary [What is Reinstate?](https://reinstate.dev/about/reinstate) [Compatibility matrix](https://reinstate.dev/compatibility) [Security overview](https://reinstate.dev/security) [Getting started](https://reinstate.dev/docs/getting-started) --- Source: https://reinstate.dev/compare Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Workflow comparison # Reinstate vs. Git for Coding-Agent Session Continuity > Learn why Reinstate and Git are complementary: Git tracks repository history, while Reinstate transfers supported coding-agent session state. Git records repository content and history; Reinstate transfers supported coding-agent session state. Git can put the same code on another computer, but agent conversations normally live in vendor-specific local storage outside the repository. Use Git for the project and Reinstate for supported same-vendor session continuity. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Git has the project; Reinstate moves supported agent context Git's data model stores repository snapshots and history as blobs, trees, commits, and tags. That is the right foundation for versioning source code and collaborating on a project. Reinstate does not replace it. Claude Code and Codex keep their resumable session records in vendor-owned local layouts. Reinstate's adapters find selected records, normalize known structural paths, encrypt them, and restore them into the same vendor's native layout on another device. ## Responsibility comparison | Dimension | Reinstate v0.6.0-rc.6 | Git | | --- | --- | --- | | Primary job | Supported coding-agent session continuity across devices | Repository content, history, branching, merging, and exchange | | Default content scope | Selected vendor-native Claude Code and Codex session artifacts | Files deliberately added to the repository object database | | Repository source files | Not synchronized | Core responsibility | | Agent conversation state | Core Phase 1 responsibility for supported layouts | Not included unless a user deliberately adds those files | | Native agent resume | Restores the same vendor's session layout for its resume command | Not a Git operation | | Cross-device project paths | Remaps known structural paths using configured project IDs | Repository checkout paths are outside Git's object model | | Remote data protection | Session payload is encrypted locally with age before upload | Depends on repository contents, hosting, and the user's security design | | Credentials | Known agent authentication and credential paths are hard-excluded | Users must avoid adding secrets and configure repository exclusions appropriately | | Conflict model | Session revision checks, conflict records, forks, and restore backups | Repository branches and merge operations | | Recommended relationship | Use Git for code and Reinstate for supported agent sessions. | ## Could you commit session files to Git? Git can track any file you deliberately add. That does not make raw agent-session directories automatically portable or appropriate for a repository. You would still own file discovery, credential and sensitive-content review, path adaptation, vendor-layout restoration, binary or large-file behavior, and repository-access policy. Reinstate takes a narrower route: its adapters select supported artifacts, exclude known credential paths, transform only known structural fields, and place encrypted payloads in a separate storage workflow. Session transcripts can still contain secrets an agent printed or a user pasted, so encryption and access control remain necessary. ## A two-layer workflow 1. **Synchronize the repository with Git.** Commit and exchange the project state you want collaborators and devices to share. 2. **Prepare the destination project.** Check out the appropriate revision and install the compatible agent independently. 3. **Transfer the supported session with Reinstate.** Push on one device, pull with a dry-run on the other, and restore the native session. 4. **Resume with the same vendor.** Continue Claude Code in Claude Code or Codex in Codex against the prepared repository. Git and Reinstate are complementary. A session without the matching repository state may have stale assumptions; a repository without the session lacks the agent conversation. Keep both layers synchronized deliberately, and keep independent backups while Reinstate is pre-1.0. ## Evidence and verification Sources below were reviewed on September 7, 2026. Reinstate claims describe v0.6.0-rc.6; external workflow claims are limited to what the linked primary sources document. - [Git data model](https://git-scm.com/docs/gitdatamodel) Official Git documentation for blobs, trees, commits, tags, repository snapshots, and history. - [Git reference documentation](https://git-scm.com/docs/git) Official overview of the object database, index, working tree, and Git command families. - [Reinstate adapter documentation](https://reinstate.dev/docs/adapters) Native session discovery, portability fields, credential exclusions, and same-vendor resume. - [Reinstate security model](https://reinstate.dev/docs/security-model) Encryption, sensitive transcript boundaries, local backups, and conflict behavior. ### Limits of this comparison - Git can store raw session files when a user deliberately adds them; this page does not claim a technical prohibition. - Git hosting, repository encryption, secret scanning, and access controls vary and are outside this comparison. - Reinstate does not synchronize source code, branches, uncommitted changes, dependencies, or repository credentials. ## Use both layers deliberately [All comparisons](https://reinstate.dev/compare) [Why Git does not sync sessions](https://reinstate.dev/blog/why-git-does-not-sync-coding-agent-sessions) [Getting started](https://reinstate.dev/docs/getting-started) [Security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/compare/reinstate-vs-git Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Workflow comparison # Reinstate vs. Manual Coding-Agent Session Copying > Compare Reinstate with manually copying Claude Code or Codex session files across devices, including paths, encryption, credentials, and recovery. Manual copying can move any session files you can correctly identify, secure, adapt, and restore. Reinstate automates those steps for supported same-vendor Claude Code and Codex sessions, including structural path remapping, local encryption, credential exclusions, and safer restore behavior. It does not support every format or remove the need for independent backups. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## The practical difference A manual workflow puts file discovery, selection, transport security, cross-platform path changes, overwrite policy, and validation in your hands. That control is useful when you know an unsupported format or need a one-off transfer. Reinstate supplies a repeatable workflow for the session layouts and versions it explicitly supports. This page uses “manual copying” to mean a user-operated transfer of selected local session files. It does not assume a particular copy command, cloud drive, archive format, or security design. ## Capability comparison | Dimension | Reinstate v0.6.0-rc.6 | Manual session copying | | --- | --- | --- | | Format scope | Tested Claude Code and Codex session layouts only | Any format the operator can correctly identify and handle | | Discovery | Adapter discovers supported vendor-native session artifacts | Operator identifies every source file and relationship | | macOS ↔ Windows paths | Configured canonical project IDs expand to each device's local root | Operator inspects and updates structural paths when required | | Free-form transcript paths | Left unchanged; only known structural fields are remapped | Depends on the operator's chosen edits | | Transport payload | Encrypted locally with age before upload to user-owned S3-compatible storage | Depends entirely on the selected archive and transport | | Credentials | Known auth, credential, token, cache, and log paths are hard-excluded | Operator must decide what to exclude and verify the result | | Restore preview | `pull --dry-run` previews the planned restore | Available only if the operator builds a preview step | | Overwrite protection | Timestamped backups, atomic writes, and explicit conflict records | Depends on the copy tool and procedure | | Native resume | Restores to the same vendor's native layout for its own resume command | Works if the operator reproduces a valid native layout | | Independent backup | Still recommended, especially before v1.0 | Operator owns the complete backup and recovery design | ## When manual copying can fit - You need to move a session format Reinstate does not support. - You fully understand the vendor's current storage layout and portability constraints. - You want total control over selection, transport, transformation, and restore behavior. - The transfer is rare enough that maintaining a repeatable workflow is unnecessary. ## When Reinstate can fit - You regularly continue supported Claude Code or Codex work on another device. - Your project roots differ between macOS and Windows. - You want selected session artifacts encrypted before they reach remote storage. - You want adapter-aware discovery, a dry-run, backups, and explicit conflict handling. Automation narrows the supported surface. Reinstate does not claim that manual copying is impossible or universally unsafe. A careful operator can recreate some or all of these safeguards. The tradeoff is between manual flexibility and a tested, repeatable workflow for the formats Reinstate supports. ## Evidence and verification Sources below were reviewed on September 7, 2026. Reinstate claims describe v0.6.0-rc.6; external workflow claims are limited to what the linked primary sources document. - [Adapter documentation](https://reinstate.dev/docs/adapters) Supported native layouts, project-key handling, same-vendor resume, and hard exclusions. - [Getting started](https://reinstate.dev/docs/getting-started) Current push, dry-run, pull, restore, and native resume procedure. - [Security model](https://reinstate.dev/docs/security-model) age encryption, credential boundaries, timestamped backups, atomic writes, and conflict forks. - [Compatibility matrix](https://reinstate.dev/compatibility) Current tested agents, versions, operating systems, storage, and release limitations. ### Limits of this comparison - Manual copying is a user-defined workflow, so its security and reliability cannot be scored without inspecting the actual procedure. - Reinstate supports only documented Claude Code and Codex session layouts in Phase 1; it is not an arbitrary file synchronization tool. - Neither approach makes a Claude Code transcript natively resumable in Codex, or a Codex rollout natively resumable in Claude Code. ## Plan a supported transfer [All comparisons](https://reinstate.dev/compare) [Check compatibility](https://reinstate.dev/compatibility) [macOS and Windows use case](https://reinstate.dev/use-cases/macos-and-windows) [Troubleshooting](https://reinstate.dev/docs/troubleshooting) --- Source: https://reinstate.dev/compare/reinstate-vs-manual-session-copying Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Workflow comparison # Reinstate vs. Remote Desktop for Coding-Agent Work > Compare Reinstate session transfer with remote desktop access: execution location, host availability, native local resume, storage, and security scope. Remote desktop lets you control the machine where your environment and session already live. Reinstate instead transfers a supported, encrypted session artifact so the same agent vendor can resume it on another configured computer. Choose based on whether you need the original environment or local continuation on the destination. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Remote control and session transfer solve different problems With remote desktop, the agent, repository, tools, and session can remain on the host machine; another device displays and controls that environment. With Reinstate, the agent runs locally on the destination after Reinstate restores a supported native session there. Reinstate is not a screen-sharing, shell-hosting, or remote-execution service. Remote desktop behavior varies by product. Where this comparison mentions host power or connectivity requirements, it refers specifically to Microsoft's documented Remote Desktop PC workflow, not every remote-access product. ## Workflow comparison | Dimension | Reinstate v0.6.0-rc.6 | Remote desktop | | --- | --- | --- | | Primary job | Transfer supported coding-agent session state between devices | Interact with a remote computer and its existing environment | | Where the agent runs | Locally on the destination after restore | On the remote host in the conventional remote-desktop model | | What moves | Selected, encrypted vendor-native session artifacts | The interaction is transmitted; project and session state stay on the host | | Source host after transfer | Does not need to remain online after a completed push | Microsoft's PC workflow requires the host to be powered on, connected, and reachable | | Destination environment | Needs the project, compatible agent, and mapped local project root | Needs a compatible remote-access client; tooling stays on the host | | macOS ↔ Windows paths | Known structural paths are remapped through canonical project IDs | Usually unnecessary because the session remains in the host environment | | Remote storage | User supplies S3, R2, or compatible object storage for encrypted artifacts | Product-specific; not evaluated by this page | | Credentials | Agent credentials are excluded and must exist independently on the destination | Host access and credential behavior are product-specific | | Network use | Required for push/pull; not for later local agent execution | Required while controlling the remote host | | Repository and dependencies | Not synced; prepare them separately on the destination | Remain available in the host environment | ## When remote desktop can fit - You need the exact host operating system, files, credentials, services, or hardware. - You do not want to recreate the development environment on the device in front of you. - The host and network can remain available for the duration of your work. - Your chosen product meets your access-control, security, display, and latency needs. ## When Reinstate can fit - You want the supported agent and repository to run locally on the destination. - You may turn off or disconnect the source device after uploading the session. - You work across different local project roots, including macOS and Windows paths. - You want the transferable payload encrypted before it reaches your storage backend. You can use both. Remote access can cover work tied to a host environment, while Reinstate can move selected supported sessions that you want to continue locally. Reinstate does not copy your repository, dependencies, shell state, credentials, or running processes. ## Evidence and verification Sources below were reviewed on September 7, 2026. Reinstate claims describe v0.6.0-rc.6; external workflow claims are limited to what the linked primary sources document. - [Microsoft: Enable Remote Desktop on your PC](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access) Defines Microsoft Remote Desktop as connection to and control of a remote PC and documents host availability requirements. - [Microsoft: Remote Desktop clients FAQ](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-pc-connections-faq) Documents that a Windows remote PC cannot be off, asleep, or hibernating for connection. - [Reinstate architecture](https://reinstate.dev/docs/architecture) Documents local agent execution, adapter boundaries, portable paths, encrypted storage, and native restore. - [Reinstate compatibility matrix](https://reinstate.dev/compatibility) Current agents, operating systems, storage backends, and tested-version gates. ### Limits of this comparison - Remote desktop is a product category, not one implementation; this page does not compare pricing, protocols, encryption, account requirements, or administrative controls. - Host availability statements are scoped to the linked Microsoft Remote Desktop documentation and must not be generalized to every remote-access system. - Reinstate transfers supported session artifacts only; it does not reproduce the complete source environment or provide remote access. ## Choose the continuity boundary [All comparisons](https://reinstate.dev/compare) [Work and personal computers](https://reinstate.dev/use-cases/work-and-personal-computers) [Security overview](https://reinstate.dev/security) [Architecture](https://reinstate.dev/docs/architecture) --- Source: https://reinstate.dev/compare/reinstate-vs-remote-desktop Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Contact # Contact Reinstate: Support, Security Reports, and Maintainer > How to reach the Reinstate project: public GitHub issue forms for questions, bugs, and adapter requests; private security reporting; the maintainer; and expected response times. Reinstate is an open-source project maintained by Harjot Singh Rana. Support happens in public on GitHub so answers stay searchable; security reports and privacy requests go through a private channel. There is no sales team and no paid support tier. Reinstate Hop, the client for the optional hosted tier, ships in the CLI, but its control plane is not yet open, so there is no hosted account to create today. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Where to reach the project | Need | Channel | Target first response | | --- | --- | --- | | [Questions and setup help](https://github.com/HarjjotSinghh/reinstate/issues/new?template=question.yml) | Public question form on GitHub. Redact bucket names, paths, and anything from a session transcript before posting. | As capacity allows | | [Bug reports](https://github.com/HarjjotSinghh/reinstate/issues/new/choose) | GitHub bug report template. Include the Reinstate version, agent, operating system, and the exact command. | 5 business days on the latest stable release | | [Feature and adapter requests](https://github.com/HarjjotSinghh/reinstate/issues/new/choose) | Feature request and adapter request templates on GitHub. Roadmap discussion is welcome; search existing issues first. | As capacity allows | | [Security vulnerabilities](https://github.com/HarjjotSinghh/reinstate/security/advisories/new) | Private GitHub security advisory (preferred) or email security@harjot.co. Never post vulnerability details in a public issue. | Acknowledged within 72 hours; initial assessment within 7 days | | [Privacy requests](https://reinstate.dev/privacy) | Ask to access, correct, or delete a waitlist record from the address concerned, using the private security contact. | Handled with security reports | ## Maintainer - **Name:** [Harjot Singh Rana](https://harjot.co/) - **GitHub:** [@HarjjotSinghh](https://github.com/HarjjotSinghh) - **Project:** [github.com/HarjjotSinghh/reinstate](https://github.com/HarjjotSinghh/reinstate) - **License:** [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0) - **Security contact:** security@harjot.co - **Website:** [reinstate.dev](https://reinstate.dev/) ## Before you write - Check the [troubleshooting guide](https://reinstate.dev/docs/troubleshooting) and the[FAQ](https://reinstate.dev/docs/faq); most setup, path-mapping, conflict, and restore questions are answered there. - Run `rein doctor` and include its output. Never paste an encryption passphrase, bucket credentials, or session transcript content. - Reinstate does not provide support for Claude Code, Codex, or other agents themselves, for cloud-storage billing, or for debugging your own application code. Use the vendor's channels for those. ## Early access and updates Install from the [homepage install section](https://reinstate.dev/#install), and follow the[changelog](https://reinstate.dev/changelog) and its [RSS feed](https://reinstate.dev/changelog/rss.xml) for release notices. The early-access waitlist is reachable programmatically at[/api/v1/waitlist](https://reinstate.dev/api/v1/waitlist). Programmatic contact for agents is documented under[developer resources](https://reinstate.dev/developers). --- Source: https://reinstate.dev/contact Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- # Reinstate Hop: Sign-In, Devices, and the Locker > See how Reinstate Hop - **Status:** Current release - **Maintained by:** [Harjot Singh Rana](https://harjot.co/) - **Updated:** September 5, 2026 Reinstate Hop is the optional hosted tier: a **locker** (a storage bucket provisioned for exactly one account) plus a console. Every capability lives in the CLI; Hop only gates storage and the console. > **Status.** The hosted control plane this client talks to by default, `https://hop.reinstate.dev`, is not open yet. Nothing here is behind a build tag or a flag — the client ships anyway, and the protocol and journeys below are public and testable today against a control plane you run yourself or point the client at (see [Choosing the control plane](https://reinstate.dev/docs/hop#choosing-the-control-plane)). No price, trial, or sign-up is attached to any of this, and Hop ships in the `v0.6.0-rc.6` release candidate, not yet a stable claim — stable remains `v0.5.1`, where Hop does not exist. Every session object Reinstate writes to the locker is ciphertext, with one documented exception: `keyring.v1.json` holds no usable key, but it does give up the account’s profile id, every enrolled device’s id and public key, and one entry per key generation with the time it started. The full object format and what it is worth to an observer are in the [object format](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/hop/object-format.md) and [threat model](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/hop/threat-model.md) references. ## Commands ```text rein login [--email ADDRESS] [--no-browser] [--json] rein whoami [--json] rein init --hop [--project ID=PATH]... [--force] rein hop status [--json] rein hop credentials [--json] [--export] rein account init [--json] rein account join rein account recover [--json] rein account status [--json] rein devices [--json] rein devices approve [--request ID] rein devices revoke rein sync verify [--json] [--post=false] rein sync migrate --to byo [--endpoint URL --bucket NAME] [--switch] [--forget-hop] rein daemon run [--pull-every DURATION] [--debounce DURATION] rein daemon install|start|stop|uninstall rein daemon status [--json] ``` ## Your first push Four commands take a machine from nothing to ciphertext in the locker: ```bash rein login # GitHub in the browser, or --email you@example.com rein init --hop # profile for the locker; provisions it rein account init # root key on this device; recovery code shown once rein push --agent claude --session SESSION_ID # or --all: credentials minted, ciphertext lands rein hop status # bucket, location, usage, limits, first push time rein sync verify # the verification report, any time ``` `rein login` stores a device token in the OS keyring only; the control plane now knows this device, but the locker does not exist yet. `rein init --hop` provisions the locker without writing an endpoint, bucket, or key to `config.toml`. `rein account init` generates a **root key** on this device, writes the **keyring** with the first minted credential, and shows the **recovery code** exactly once — write it down, because the operator cannot recover the locker for you. `rein push` (optionally with `--all`, so neither Reinstate nor a coding agent selects every discovered session on your behalf by default) then encrypts the selected sessions under the root key and uploads them. ### Recovering a wiped machine ```bash rein login # a new device token rein init --hop # the profile again; the locker already exists rein account recover # enter the recovery code; this device joins the keyring rein pull --agent claude --session SESSION_ID # or --all: sessions decrypt into each agent's own layout rein resume claude: # verified resume, as before ``` Install and run each agent once before `rein pull`; Reinstate restores into the vendor’s own layout and never invents it. A second machine can instead run `rein login`, `rein init --hop`, and `rein account join`, which shows a short code approved from an enrolled device with `rein devices approve`. ## Adding and revoking devices Pairing needs nothing typed on the new device except the sign-in: ```bash rein login && rein init --hop && rein account join # shows a short code, waits ``` On an already-enrolled device, `rein devices approve` takes that code, appends the new device’s wrap of the root key to the keyring, and relays the root key sealed so only the code’s holder can open it. A wrong code fails closed with nothing written; an expired request is refused before anything is written. The control plane never sees the code itself, only protocol metadata; the full derivation (Argon2id plus HKDF-bound AEAD, versioned for upgrades) is in [docs/hop.md, “Adding a device”](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/hop.md#adding-a-device-pairing). Revoking a lost or retired device is one command from any other enrolled device: ```bash rein devices # find its id or name rein devices revoke desktop # asks for the recovery code ``` Revocation starts a new **key generation**: the revoking device wraps a fresh root key for every remaining device and under the recovery code, then tells the control plane to refuse the revoked device’s token from then on. Earlier objects stay readable by every generation that can unwrap them; the revoked device keeps what it already pulled but cannot open anything sealed under the new generation. The Console can *request* a revocation, but only an enrolled device holding the recovery code can *perform* one — the control plane never holds the root key or the recovery code. ## The locker `rein init --hop` writes a profile whose storage is the account’s locker. The profile id is the account id and the device id the enrolled device id, so every device signed in to the same account shares one profile. No endpoint, bucket, region, or key is stored locally: on every push and pull the client asks the control plane for credentials bound to exactly that bucket, valid for at most an hour, then speaks the S3 API to the locker directly — the control plane never sees an object. A BYO profile never consults the control plane at all. The locker is created in the location the first device asked for at sign-in (`REINSTATE_HOP_LOCATION`, else the machine’s time zone; `apac` by default and for India). Later devices’ hints do not move an existing locker. ### Limits What the control plane is built to enforce; which of these the hosted service will actually offer, and on what terms, is not published — this documents the protocol, not an offer. | Plan | Storage | Devices | Credential mints per hour | | --- | --- | --- | --- | | Hop | 5 GB | 5 | 60 | | Hop Plus | 25 GB | 10 | 120 | ## Verifying the claim (`rein sync verify`) The claim: every session object in the locker is ciphertext sealed by your devices, your devices can open it, and your account’s credentials reach your locker and nothing else. `rein sync verify` checks this in four steps and prints a report written for a non-expert, each step scored PASS, FAIL, or NOT APPLICABLE: 1. **List the locker** with this device’s push credentials. 2. **Fetch an object and check it is ciphertext** — the index and the most recently updated snapshot. 3. **Decrypt it locally** with the key held on this device and check the payload checksum. Nothing leaves the machine; on a Hop locker the root key is never exported, because a command that wrote it out would expose every object the account has ever written. 4. **Prove isolation**: the same credentials must be refused, as access denied, against a reference locker the control plane names. The step fails only on something that contradicts the claim (the reference answered, a redirect was followed, a plaintext endpoint was used); every other outcome — no reference advertised, the control plane unreachable, a credential rotated mid-check — is reported “not applicable,” not a pass. The report ends `OUTCOME: PASS`, `FAIL`, `NOT VERIFIED` (no answer from the control plane or storage endpoint), or `NOT YET VERIFIABLE` (nothing pushed yet). Exit code `7` on any failed step, `0` when every step passed or did not apply, `1` when a required endpoint could not be reached at all. On a Hop profile, only the step **results** — never object contents, session ids, or project paths — are posted to the control plane for the account console; `--post=false` keeps them local. BYO storage runs steps 1–3 and reports step 4 as not applicable. The first successful push from a new device runs the same checks automatically. ## The daemon `rein daemon` is a resident per-device process that keeps a device’s sessions synced without anyone running `push` and `pull` by hand, and it behaves identically on BYO storage and on Hop — no telemetry, nothing sent that `push` and `pull` do not already send. ```text rein daemon run [--pull-every DUR] [--debounce DUR] [--poll] [--verbose] rein daemon install # register at login, and start it now rein daemon start|stop # control the registered daemon rein daemon uninstall # stop it and remove the login registration rein daemon status [--json] ``` `rein daemon install` registers with the platform’s own supervisor: a launchd user agent on macOS, a systemd `--user` unit on Linux, and a Task Scheduler task with a logon trigger on Windows. The loop watches every detected agent’s session directory and pushes after a change (debounced, coalesced, and pushed at least every 30s regardless), pulls on a schedule (default every 30s), and pulls once more before a resume when its last pull is older than 15s. On Hop only, it also polls for pending device-pairing requests and surfaces each as an OS notification and a status-file entry; approval itself stays interactive and the daemon never sees the pairing code. `rein daemon install` needs the root-key model (`rein account init`, which also works on BYO storage); a passphrase-model home can run `rein daemon run` under a supervisor that supplies `REINSTATE_PASSPHRASE_FD` instead. ## Choosing the control plane The production control plane is `https://hop.reinstate.dev`. Point the client at a staging or self-hosted instance instead with, in order of precedence: 1. `REINSTATE_HOP_URL=http://127.0.0.1:8080` 2. `[hop] url = "..."` in `config.toml` When the configured control plane cannot be reached at all — no DNS answer, connection refused, a failed TLS handshake — `rein login` and `rein whoami` print one sentence naming the URL and the cause and pointing at this page, instead of a raw network error. A control plane that *answers* (a rejected token, a quota refusal) is reported the way it always was. ## Protocol The client is open and the protocol is public; the control plane’s source is private. The control plane never receives a root key, a recovery code, a passphrase, or session content — sign-in is a device-authorization style flow (`POST /v1/login/sessions`, poll, claim), and every other Hop journey above follows the same rule: what crosses the wire is metadata, tokens, and ciphertext, never a key. The full request and response shapes are in [docs/hop.md, “Protocol”](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/hop.md#protocol). ## Leaving Hop Leaving is one command to a bucket you own, available at any time, including a read-only period the control plane may apply to a lapsed account: ```bash export REINSTATE_S3_ACCESS_KEY_ID=... REINSTATE_S3_SECRET_ACCESS_KEY=... rein sync migrate --to byo --endpoint https://.r2.cloudflarestorage.com --bucket my-sessions ``` It reads every snapshot and the manifest from the locker, opens them with the root key held on this device, re-seals them under a new passphrase, and writes them to the bucket under a fresh profile — nothing derived from the root key reaches the destination. The locker is only read, never deleted or emptied, so the command works on a lapsed, read-only account. An interrupted run resumes from where it left off without writing anything twice. Afterwards it offers to switch this device to the bucket and to forget the device’s Hop sign-in; both are optional and reversible. Other devices join with `rein init --profile-id ` and the passphrase. ## What this does not do yet - Sign out a device from itself (revoke it from another device instead). - Billing, pricing, a trial, or a self-service sign-up: this page documents the protocol, not an offer. - Deploying the hosted control plane to production — the client and protocol ship ahead of that, per [ADR 0005](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/adr/0005-v0.6.0-scope-and-windows-first-acceptance.md). ## Related pages - [Reinstate security and encryption model](https://reinstate.dev/docs/security-model) - [Configure storage for encrypted Reinstate sessions](https://reinstate.dev/docs/storage) - [Reinstate CLI reference](https://reinstate.dev/docs/cli-reference) - [Reinstate roadmap](https://reinstate.dev/roadmap) - [Changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/docs/hop Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-05. --- Terminology # Reinstate Terminology: Session Sync and Continuity Glossary > Define Reinstate profiles, snapshots, encrypted manifests, canonical project IDs, structural paths, native resume, portable handoffs, and compatibility states. Reinstate uses precise terms for the identity, encryption, path-mapping, and compatibility boundaries of coding-agent session continuity. This glossary defines the stable v0.5.1 implementation and labels later roadmap concepts so a profile is not mistaken for an account, or native resume for cross-agent translation. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Current sync objects - **Profile:** A sync identity shared by deliberately configured devices. Its non-secret`profile_id` selects one isolated remote storage prefix; it is not a hosted Reinstate account and does not contain storage credentials. - **Snapshot:** One immutable, encrypted capture of a selected agent session. A snapshot has a UUID, authenticated metadata, one adapter archive, a parent revision when one exists, and a content hash checked before restore. - **Encrypted manifest:** The age-encrypted remote index named `manifest.age`. Its decrypted v1 JSON maps each `agent:session` key to the current immutable snapshot and advances through conditional writes to detect conflicts. - **Device:** One independently configured Reinstate environment with its own device ID and local path mappings. Native Windows and WSL2 are separate devices even when they run on one physical computer. ## Path and resume terms - **Canonical project ID:** A stable, non-secret project identity such as `github.com/acme/app`. Every device maps that same ID to its own absolute checkout path; the ID is not itself a filesystem path. - **Structural path:** A path stored in an adapter-recognized field that participates in session or project structure, such as `cwd`, `filePath`, or`workingDirectory`. Reinstate does not rewrite path-shaped prose in prompts or responses. - **Portable path token:** A normalized placeholder—currently `$${HOME}` or`$${REPO:}`—that a configured destination expands through its own local paths. - **Native resume:** Continuing a restored session with the agent vendor that created it. In Phase 1, Claude Code resumes Claude Code sessions and Codex resumes Codex sessions. The lower-level path-mapping package also contains a `$${WORK:}`primitive. Reinstate configuration and released adapters do not populate work aliases, so it is not a current CLI feature. ## Structured handoff term Portable handoff is not native resume. A portable handoff is an explicit, lossy checkpoint for continuing work in a different agent. It may carry goals, decisions, constraints, changed files, and validation state, but it will not silently translate one vendor's native transcript into another vendor's session format. Portable handoffs are available in Reinstate as structured handoff into a new Claude Code or Codex session. ## Compatibility states | State | Meaning | Mutation behavior | | --- | --- | --- | | `SUPPORTED` | The installed stable version and recognized layout are inside the tested range. | Export and restore may proceed after the other safety checks pass. | | `UNTESTED` | The installation or layout is recognizable but outside current evidence. | Discovery may remain read-only; Phase 1 CLI mutations fail closed. | | `UNSUPPORTED` | The environment, version, layout, or agent is known to be incompatible. | Export and restore stop. | | `NOT_INSTALLED` | No local installation or expected session root was found. | No session mutation is attempted. | ## Current versus planned Reinstate implements encrypted same-vendor session sync for the current[tested Claude Code and Codex ranges](https://reinstate.dev/compatibility/agent-version-history). Universal session search, verified environment repair, portable handoffs, and universal non-secret agent configuration remain later roadmap phases. See the[status-separated roadmap](https://reinstate.dev/roadmap) before treating a future term as a current command. ## Use the definitions [Path-mapping visualizer](https://reinstate.dev/tools/path-mapping-visualizer) [Encrypted snapshot format v1](https://reinstate.dev/research/encrypted-snapshot-format-v1) [Compatibility matrix](https://reinstate.dev/compatibility) [What is Reinstate?](https://reinstate.dev/about/reinstate) [Architecture](https://reinstate.dev/docs/architecture) --- Source: https://reinstate.dev/glossary Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Practical guide # Move a Coding-Agent Session from Mac to Windows > Move one encrypted Claude Code or Codex session from macOS to native Windows with Reinstate path remapping, dry-runs, backups, and native resume. To move a coding-agent session from Mac to Windows with Reinstate, map one canonical project ID to the Mac and Windows checkout paths, push one selected Claude Code or Codex session from the Mac, join the same encrypted storage profile on native Windows, preview the pull, restore it, and resume it with the same vendor. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** September 6, 2026 - **Reviewed:** September 6, 2026 - **Reading time:** 17 minutes BEFORE YOU START ## Prerequisites - One native macOS computer and one native 64-bit Windows 11 computer you are authorized to configure - Reinstate (stable v0.5.1, or the installer's v0.6.0-rc.6 candidate) plus a tested Claude Code or Codex CLI version on both computers - The same Git project checked out normally on both computers, even if its absolute paths differ - A private S3-compatible profile, its non-secret coordinates, and credentials for both OS keyrings - One harmless source session ID and a long encryption passphrase stored outside Reinstate ## Steps at a glance Allow about 45 minutes after the prerequisites are ready. Network speed, storage configuration, or agent setup can extend that estimate. 1. [Verify the two native environments](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows#verify-native-environments) Confirm the Reinstate binary, same-vendor agent version, native operating system, and separate absolute project path on each computer before configuring synchronization. 2. [Initialize and verify the Mac profile](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows#initialize-mac-profile) Initialize the first device with one canonical project ID mapped to the Mac checkout, enter storage credentials privately, record its profile UUID, and run setup and self-tests. 3. [Preview and push one selected session](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows#push-selected-session) List metadata, choose exactly one harmless Claude Code or Codex session, inspect the non-mutating push plan, push it, and verify the encrypted remote revision. 4. [Join the profile on native Windows](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows#join-windows-profile) Initialize native Windows with the first device profile UUID and the same project ID mapped to the Windows checkout, then verify storage, crypto, and adapter checks. 5. [Preview, pull, and resume on Windows](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows#pull-and-resume) Close the destination agent, preview the exact restore and backup paths, pull the selected session, verify its native destination, and resume it through the same vendor CLI. This visible sequence is also published as truthful `HowTo` structured data. Valid structured data can help machines understand the page, but it does not guarantee a rich result. Google [retired How-to rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) in 2023; the markup remains a Schema.org description for systems that consume it. ## What this guide proves—and what it does not This is an operator workflow for moving one supported, vendor-native session from macOS to **native Windows 11** through Reinstate (stable `v0.5.1`, or the installer’s `v0.6.0-rc.6` candidate, whose tagged-artifact acceptance is pending on native Windows x64 with macOS deferred). It uses the same commands and stop conditions as the repository’s [Phase 1 Mac/Windows acceptance runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md), but completing it on personal devices is not release certification. Reinstate transfers an age-encrypted snapshot and known structural project paths. Git remains responsible for source code and working-tree state. Claude Code or Codex CLI remains responsible for native resume. | Concern | macOS source | Reinstate | Windows destination | | --- | --- | --- | --- | | Repository checkout | Existing Mac path | Maps it to a canonical project ID | Existing Windows path | | Session selection | Human chooses one ID | Discovers and snapshots that ID | Restores the same vendor ID | | Encryption | Passphrase entered locally | Encrypts before upload | Decrypts after download | | Credentials | Stored in macOS Keychain | Stores only a credential reference in config | Stored in Windows Credential Manager | | Resume | Source vendor writes the session | Does not execute the agent | Same vendor resumes natively | ## Key points - Use one stable project ID on both devices even though paths such as `/Users/me/Code/app` and `C:\src\app` differ. - Use **native Windows PowerShell** for this workflow. WSL2 is a separate Linux Reinstate device with different path semantics; WSL1 is unsupported. - Choose exactly one `claude` or `codex` session and preview both transfer directions with `--dry-run`. - Resume remains **same-vendor**: Claude Code to Claude Code, or Codex CLI to Codex CLI. Reinstate does not convert one vendor’s transcript into the other vendor’s native format. - Credentials, vendor authentication, API keys, OAuth material, `.env` files, Git state, MCP servers, skills, plugins, and hooks do not move with the session. - Keep independent backups. The encrypted remote profile is a continuity artifact, not a replacement for repository backups or a tested retention plan. - Stable physical two-device acceptance passed on Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 remain installer-compatible, preview and unverified. Do not describe a personal success there as stable platform certification. ## Before you begin Use a harmless session in a disposable or non-sensitive repository first. Confirm that moving its contents to the selected bucket and Windows computer is permitted by employer, client, data-residency, and device policies. Configure a private provider bucket before this guide. Use either the [Amazon S3 storage guide](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage) or the [Cloudflare R2 storage guide](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage). Never paste the storage secret, encryption passphrase, transcript, or downloaded snapshot into a coding-agent prompt, shell argument, commit, screenshot, or test report. ### Platform and release qualifications | Environment | Current qualification | | --- | --- | | macOS native arm64 | Stable and physically verified; a real second device is still required for your own transfer evidence. | | macOS native amd64 | Installer-compatible, preview, and unverified. | | Windows 11 native amd64 | Stable and physically verified. | | WSL2 amd64 | Installer-compatible, preview, and unverified; it is not native Windows. | | Linux native | Installer-compatible, preview, and unverified. | | WSL1 | Unsupported. | Current Reinstate source evidence recognizes Claude Code `2.1.219`–`2.1.220` and Codex CLI `0.133.0`–`0.146.0`. A result outside those inclusive ranges is `UNTESTED`; `rein setup check` exits with compatibility code `5` and mutating push or pull is blocked. ### Native Windows and WSL are different devices Do not point native Windows and WSL at one shared agent-state directory or one Reinstate home: | Property | Native Windows | WSL2 | | --- | --- | --- | | Shell | PowerShell | Linux shell | | Default Reinstate home | `%USERPROFILE%\.reinstate` | `~/.reinstate` inside WSL | | Paths | `C:\src\app` | `/home/me/app` or `/mnt/c/src/app` | | Phase 1 role in this guide | Destination | Out of scope | If the agent runs inside WSL, follow a separately configured Linux/WSL workflow; do not label it native Windows evidence. ## Command placeholders and parameters | Placeholder or flag | Meaning | | --- | --- | | `AGENT` | Replace with exactly `claude` or `codex`, and use the same value on both devices. | | `SESSION_ID` | The exact harmless source ID returned by `rein list --agent AGENT`. | | `PROFILE_ID` | The non-secret UUID printed by first-device `rein init`; copy it exactly to Windows. | | `PROJECT_ID` | A stable ID such as `github.com/acme/app`, identical on both devices. | | `MAC_PROJECT` | The absolute macOS checkout path, such as `/Users/me/Code/app`. | | `$WindowsProject` | A PowerShell variable containing the absolute native Windows checkout path. | | `STORAGE_ENDPOINT` | The S3-compatible service endpoint, without the bucket name. | | `STORAGE_REGION` | The provider signing Region; use `auto` for Cloudflare R2. | | `STORAGE_BUCKET` | The private bucket name only. | | `--profile-id PROFILE_ID` | Joins the existing encrypted remote profile instead of generating an unrelated one. | | `--session SESSION_ID` | Limits transfer to the one selected session. | | `--dry-run` | Reads, authenticates, validates, and plans without writing a remote snapshot or local session. | ## 1\. Verify the two native environments Install Reinstate on the Mac: ```sh curl -fsSL https://reinstate.dev/install.sh | sh rein version --json sw_vers uname -m ``` Install Reinstate from **native Windows PowerShell**, not a WSL shell: ```powershell irm https://reinstate.dev/install.ps1 | iex rein version --json Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber [Environment]::Is64BitOperatingSystem ``` Run `claude --version` or `codex --version` on both computers for the one vendor being moved. Clone or update the repository through Git, then record the two absolute checkout paths. Ensure the Windows path is a native path and not a WSL mount. Do not transfer a session while either checkout is on an unexpected branch, commit, or unreviewed dirty working tree. Reinstate maps structural paths; it does not synchronize Git state or prove environment equivalence. **Expected result:** both `rein version --json` commands report `0.4.0`, the Mac and 64-bit native Windows environments are identified separately, the same agent vendor is installed in a recognized range, and the same repository exists at two recorded absolute paths. ## 2\. Initialize and verify the Mac profile Replace every placeholder, then run this from a private Mac terminal: ```sh rein init \ --endpoint STORAGE_ENDPOINT \ --region STORAGE_REGION \ --bucket STORAGE_BUCKET \ --project "PROJECT_ID=MAC_PROJECT" ``` Enter the storage access-key ID and secret access key only through the two hidden prompts. Initialization does not request or store the encryption passphrase. Reinstate creates a profile UUID, writes and deletes a two-byte storage probe, stores the credential in the OS keyring, and saves `config.toml` plus `state.json` only after the probe succeeds. Record only the printed non-secret `profile_id`, then run: ```sh rein setup check rein doctor --self-test ``` Stop if the selected adapter is not `SUPPORTED`, the self-test fails, or the project mapping does not resolve to the intended Mac checkout. Do not use an unsafe compatibility override; Reinstate has none. **Expected result:** init prints `initialized reinstate home (config.toml + state.json)` and `profile_id=`, setup and self-test exit `0`, and the temporary storage probe is gone. No persistent `manifest.age` exists until the first successful push. ## 3\. Preview and push one selected session Close the Mac agent cleanly and choose one harmless session: ```sh rein list --agent AGENT rein push --agent AGENT --session SESSION_ID --dry-run rein push --agent AGENT --session SESSION_ID rein status ``` Enter the long encryption passphrase only at Reinstate’s hidden prompt and store it in a password manager. You will need the exact same passphrase on Windows. Do not use `--all` for the first transfer. The dry-run must identify one snapshot without mutation. The real push encrypts the snapshot locally, writes the encrypted snapshot and manifest beneath `profiles/PROFILE_ID/`, and updates local synchronization state. **Expected result:** dry-run begins with `would push 1 snapshot(s)` and `dry_run=true`; the real command reports `pushed 1 snapshot(s)` and `dry_run=false`; status reports one remote revision; and the private bucket contains `manifest.age` plus an opaque `snapshots/.age`, not a plaintext transcript or credential file. ## 4\. Join the profile on native Windows In native Windows PowerShell, set a local variable to the real checkout: ```powershell $WindowsProject = "C:\absolute\path\to\project" ``` Initialize the second device with the exact first-device profile UUID: ```powershell rein init ` --profile-id PROFILE_ID ` --endpoint STORAGE_ENDPOINT ` --region STORAGE_REGION ` --bucket STORAGE_BUCKET ` --project "PROJECT_ID=$WindowsProject" ``` Enter the same storage credential through hidden prompts. Additional-device init requires the existing encrypted `manifest.age` before it saves local configuration; a wrong profile ID, endpoint, Region, bucket, prefix, or credential fails closed. Then validate the native destination: ```powershell rein setup check rein doctor --self-test rein status ``` `rein status` asks for the encryption passphrase. A deliberately wrong phrase must produce a decryption/authentication failure without restoring a session, changing an agent file, or creating a backup. Retry with the correct phrase. **Expected result:** second-device init reuses `PROFILE_ID`, setup and self-test exit `0`, status with the correct passphrase reports the selected remote session, and the project mapping resolves `PROJECT_ID` to the intended native Windows path without creating any agent session file yet. ## 5\. Preview, pull, and resume on Windows Close every process for the selected agent. Preview the exact destination and backup root: ```powershell rein pull --agent AGENT --session SESSION_ID --dry-run rein pull --agent AGENT --session SESSION_ID rein list --agent AGENT Get-ChildItem -Recurse ` (Join-Path $env:USERPROFILE ".reinstate\backups") | Select-Object -First 20 FullName ``` The dry-run should say `would pull`, name the native vendor destination, and show the backup root without mutation. The real pull validates and decrypts the complete artifact before writing, backs up an existing destination when one exists, writes through a private temporary sibling, and atomically renames the restored file. Resume through the same native vendor: ```powershell claude --resume SESSION_ID ``` or: ```powershell codex resume SESSION_ID ``` Verify visually that this is the intended prior session and that it opens from the mapped Windows project. Do not copy transcript content into public evidence. **Expected result:** dry-run reports `would pull 1 snapshot(s)` with `dry_run=true`; the real command reports `pulled 1 snapshot(s)` with `dry_run=false`; the exact ID is discoverable at its native Windows path; an existing target has a timestamped backup; and the same-vendor CLI resumes it without a structural path error. ## How path remapping works The two local paths map to one portable identity: | Device | Local configuration | Portable structural form | | --- | --- | --- | | Mac | `PROJECT_ID=/Users/me/Code/app` | `${REPO:PROJECT_ID}/...` | | Windows | `PROJECT_ID=C:\src\app` | `${REPO:PROJECT_ID}/...` | The Claude Code adapter recomputes the destination project-directory key from the Windows root. The Codex adapter rewrites the known structural `session_meta.cwd` field and preserves Codex’s native date-partitioned rollout layout. Reinstate does not blindly replace path-shaped text inside prompts, responses, shell output, or unknown vendor fields. Path remapping also does not install runtimes, recreate environment variables, move uncommitted code, align Git branches, copy agent authentication, or synchronize MCP servers and skills. ## Visible evidence to retain Record a private, redacted result containing: - OS versions and architectures; - Reinstate and agent versions; - the non-secret profile UUID and session ID; - canonical project ID plus redacted source and destination paths; - command exit codes and `would push`, `pushed`, `would pull`, and `pulled` counts; - remote object names and a boolean that selected plaintext markers were absent from a privately downloaded `.age` object; - whether an existing target received a timestamped backup; and - whether the vendor-native resume opened the intended session. Never retain the passphrase, storage secret, transcript text, downloaded snapshot, or unredacted sensitive paths as evidence. ## Failure modes and common errors ### What does pre-init `config missing` (exit `3`) mean? **Meaning:** The Reinstate home is intentionally unconfigured. **Safe recovery:** Run the reviewed init command; do not treat this expected pre-init failure as a pass. ### What should I do after compatibility exit `5` or `UNTESTED`? **Meaning:** The agent version or layout lacks release evidence. **Safe recovery:** Stop mutation and use the [compatibility page](https://reinstate.dev/compatibility) to choose a recognized version. ### Why does Windows report `remote profile manifest not found`? **Meaning:** Windows used the wrong profile or storage coordinates, or the Mac has not pushed yet. **Safe recovery:** Confirm the Mac push, then copy the exact profile UUID, endpoint, Region, bucket, and prefix. Never create a substitute empty profile. ### What should I do after a decryption or authentication failure? **Meaning:** The passphrase is wrong or ciphertext is damaged. **Safe recovery:** Stop, verify the passphrase privately, preserve remote and local copies, and retry without changing session files. ### Why does pull report `remote session not found` (exit `2`)? **Meaning:** `AGENT` or `SESSION_ID` does not match the selected remote entry. **Safe recovery:** Recheck Mac metadata and `rein status`; do not broaden the pull to `--all`. ### What should I do after safety exit `7`? **Meaning:** The destination agent appears active and an existing target could be overwritten. **Safe recovery:** Close the same-vendor agent completely and rerun the dry-run; do not bypass the refusal. ### What should I do after conflict exit `6`? **Meaning:** The Windows-local and remote copies diverged. **Safe recovery:** Preserve both, then inspect `rein conflicts list` and `rein conflicts show CONFLICT_ID`; use `--keep-both` when neither branch may be lost. ### Why does resume open from the wrong project? **Meaning:** The canonical ID or Windows mapping is wrong. **Safe recovery:** Stop the agent, preserve the restored file and backup, correct configuration through a reviewed re-init, and pull again only after previewing the destination. ## Safe rollback and undo Reinstate does not provide a general `rein undo` or remote-session delete command. 1. A push or pull `--dry-run` mutates neither remote session state nor local vendor files. 2. A failed first-device init does not save config or state after a failed storage probe. 3. A failed additional-device init does not save config when the existing remote manifest cannot be verified. 4. A wrong-passphrase pull fails before restore and creates no backup. 5. If a real pull replaced an existing target, stop the agent and preserve both the restored file and the timestamped copy under `%USERPROFILE%\.reinstate\backups\` before deciding which one to keep. 6. If local and remote state diverged, do not delete conflict metadata. Inspect it and resolve explicitly with `--keep-local`, `--keep-remote`, or `--keep-both`. 7. Remote cleanup is a provider operation. Stop all participating devices, retain needed independent backups, verify the exact `profiles/PROFILE_ID/` target, and revoke the dedicated credential after approved deletion. Never delete only `manifest.age` while leaving snapshots behind. A second device requires that encrypted manifest and will fail closed if it disappears. ## Verification checklist - [ ] Both machines report Reinstate, native OS identity, and a recognized version of the same agent vendor. - [ ] The repository exists on both machines, and one canonical project ID maps to the two reviewed absolute paths. - [ ] Mac setup and self-test pass; the remote profile did not exist before the first successful selected-session push. - [ ] Push and pull dry-runs each select exactly `AGENT:SESSION_ID` and show no mutation. - [ ] The bucket contains only encrypted `manifest.age` and `.age` snapshot objects under the recorded profile prefix; credentials are absent. - [ ] Windows second-device init reuses the exact Mac profile UUID and verifies the existing manifest before saving config. - [ ] The pull reports the intended native destination and backup root, and an existing target is backed up before replacement. - [ ] Claude Code or Codex resumes its own session ID from the mapped Windows project without a structural path error. - [ ] No claim says an unverified platform passed merely because this personal workflow succeeded. ## Current limitations - Reinstate is explicit push/pull synchronization, not background automatic sync. - It moves complete immutable snapshots rather than deltas and has no remote retention or garbage-collection policy. - Native resume is same-vendor only. Portable handoffs between vendors are a later phase. - Path mapping covers known structural fields, not prose, tool output, or arbitrary strings that resemble paths. - Git state, build tools, shells, environment variables, agent authentication, MCP servers, skills, plugins, hooks, and settings remain device-local. - WSL2 is a separate installer-compatible environment with its own Linux paths and home; it is not the native Windows destination in this guide. - Intel macOS and Linux/WSL2 remain preview and unverified. This guide is operational documentation, not physical acceptance evidence for them. - Reinstate’s encryption protects remote confidentiality, but it cannot protect a compromised endpoint or recover a lost passphrase. ## Mac-to-Windows session FAQ ### Does the Mac need to stay online after the push? No. After the selected push succeeds, native Windows downloads from your S3-compatible bucket. The Mac can be offline, but Windows still needs network access to the bucket and the same passphrase. ### Can I use WSL instead of native Windows? Not for the workflow described here. WSL2 can be configured as a separate Linux Reinstate device with its own paths, home, agent installation, and acceptance status. WSL1 and shared native/WSL agent-state folders are unsupported. ### Can I move a Claude Code session into Codex? No. Reinstate restores Claude Code state for Claude Code and Codex state for Codex CLI. It does not silently reconstruct one vendor’s native transcript format for another vendor. ### What if the checkout paths are different? That is the intended case. Map the same canonical `PROJECT_ID` to the Mac path on the source and the Windows path on the destination. Reinstate normalizes known structural fields during snapshot creation and expands them through the destination mapping during restore. ### Why did pull refuse while the agent was open? When an existing destination may be replaced, Reinstate checks whether that vendor process is active. Safety exit `7` protects the live agent file. Close the agent fully, rerun the dry-run, confirm the destination and backup root, and then pull. ### Is the encrypted bucket a complete backup? No. It is a user-owned continuity store for supported session artifacts. Maintain independent backups of repositories and any session history your policy requires, preserve restore-tested copies, and remember that losing the passphrase makes remote ciphertext unrecoverable by design. CONTINUE READING ## Related Reinstate resources [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Codex CLI integration](https://reinstate.dev/integrations/codex) [Desktop and laptop continuity](https://reinstate.dev/use-cases/desktop-and-laptop) [macOS and Windows use case](https://reinstate.dev/use-cases/macos-and-windows) [Compatibility and tested versions](https://reinstate.dev/compatibility) [Security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-06. --- Practical guide # How to Sync Claude Code Sessions Across Devices > Set up encrypted Claude Code session sync between two computers with Reinstate, including project path mapping, dry runs, restore, and native resume. To sync a Claude Code session across devices, install Reinstate on both computers, map the same canonical project ID to each local repository path, push one explicit Claude session from the source, dry-run and pull it on the destination, then resume it with Claude Code. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** July 27, 2026 - **Reviewed:** July 27, 2026 - **Reading time:** 12 minutes BEFORE YOU START ## Prerequisites - Claude Code installed on the source and destination devices - An S3-compatible bucket and its endpoint and credentials - The same long encryption passphrase available privately on both devices ## Steps at a glance Allow about 30 minutes after the prerequisites are ready. Network speed, storage configuration, or agent setup can extend that estimate. 1. [Install and check the source device](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices#install-source) Install the pinned Reinstate release, confirm its version, and run the read-only setup check before creating local configuration. 2. [Map the source repository](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices#configure-source) Initialize Reinstate with one stable project ID mapped to the source repository's absolute path, then save the non-secret profile UUID. 3. [Dry-run and push one Claude session](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices#push-session) List Claude Code sessions, select one exact session ID, inspect a non-mutating push plan, and upload only that encrypted session snapshot. 4. [Join the destination to the profile](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices#configure-destination) Install Reinstate on the destination and reuse the source profile UUID, storage settings, passphrase, and project ID with the destination path. 5. [Dry-run, pull, and resume natively](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices#pull-and-resume) Inspect the destination restore plan, close Claude Code when replacement is required, pull the session, and resume the exact ID with Claude Code. This visible sequence is also published as truthful `HowTo` structured data. Valid structured data can help machines understand the page, but it does not guarantee a rich result. Google [retired How-to rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) in 2023; the markup remains a Schema.org description for systems that consume it. ## What this workflow does This workflow moves one supported Claude Code session through storage you control. Reinstate discovers the vendor-native session, rewrites only known structural paths into portable project tokens, encrypts the snapshot locally, and uploads ciphertext. On the second device it validates, decrypts, remaps, backs up when necessary, and restores the session into Claude Code’s native project layout. This is **Claude Code to Claude Code** continuity. Reinstate Phase 1 does not translate a Claude transcript into Codex or any other agent format. The current public installer pins candidate `v0.6.0-rc.6`, whose tagged-artifact acceptance is pending on native Windows x64 (Apple Silicon macOS is deferred until that hardware returns); Intel macOS and Linux/WSL2 remain preview and unverified. Stable is `v0.5.1`. Check the [compatibility page](https://reinstate.dev/compatibility) before using another platform or a newer Claude Code version. ## Key points - Reinstate restores **Claude Code sessions into Claude Code**. It does not translate transcripts into Codex. - Use the same non-secret `profile_id` and canonical project ID on both devices, while mapping each device’s real local path separately. - Select one `SESSION_ID` and run both push and pull with `--dry-run` before either mutating command. - Snapshots and manifests are encrypted locally; storage credentials stay in the OS keyring, and the passphrase is not stored. - The installer-pinned `v0.6.0-rc.6` candidate’s tagged-artifact acceptance is pending on native Windows x64, with macOS deferred; stable `v0.5.1` remains dual-platform verified. This guide is not acceptance evidence for any other environment. ## Before you begin You need: - Claude Code installed on both devices; - a Cloudflare R2, Amazon S3, or compatible bucket you control; - the service endpoint, bucket name, access-key ID, and secret access key; and - one long encryption passphrase you can enter through a hidden prompt on both devices. Keep the bucket name separate from the service endpoint. Reinstate does not need your Anthropic credentials, and those credentials must never be pasted into a coding-agent conversation. Choose one stable project ID before setup. The examples use `local/my-project`; replace it with a value you will reuse exactly on every device. ### Platform and version qualifications | Environment | Installer path | Current qualification | | --- | --- | --- | | macOS native arm64 | POSIX installer | Stable and physically verified. | | macOS native amd64 | POSIX installer | Preview and unverified; do not infer certification from installer success. | | Windows 11 native amd64 | PowerShell installer | Stable and physically verified. | | Linux native | POSIX installer | Preview and unverified. | | WSL2 amd64 | POSIX installer | Preview and unverified. WSL1 is unsupported. | The repository currently records Claude Code `2.1.219`–`2.1.220` as the tested stable range. `rein setup check` is authoritative for the installed version: `UNTESTED` and `UNSUPPORTED` block transfer. These facts describe committed evidence, not completed physical Reinstate acceptance on every platform. ## Command placeholders and parameters | Value or flag | Meaning | | --- | --- | | `local/my-project` | A stable, non-secret project ID reused on every device. It is not a filesystem path. | | `/absolute/path/to/my-project` | The source device’s real absolute checkout path. Replace it, including on Windows. | | `DEVICE_A_PROFILE_UUID` | The exact non-secret `profile_id` printed by the first successful `rein init`. | | `SESSION_ID` | The exact Claude session identifier selected from `rein list --agent claude`. | | `--project PROJECT_ID=ABSOLUTE_PATH` | Creates one canonical project mapping. The ID is shared; the absolute path is device-specific. | | `--profile-id UUID` | Joins an additional device to the first device’s existing encrypted sync profile. | | `--agent claude` | Restricts discovery or transfer to the Claude Code adapter. | | `--session SESSION_ID` | Restricts transfer to one session. It is safer than selecting every session with `--all`. | | `--dry-run` | Authenticates, validates, and prints the plan without uploading or restoring the selected session. | | `--json` | Requests machine-readable output; this guide uses it only for the version check. | ## 1\. Install and verify Reinstate on the source On macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` On native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` If your policy prohibits executing a downloaded script directly, use the download-and-inspect variants in the [getting-started documentation](https://reinstate.dev/docs/getting-started) before running it. Verify the installed binary and the local environment: ```sh rein version --json rein setup check ``` **Expected result:** `rein version --json` returns a JSON object whose version is `v0.6.0-rc.6` for the currently pinned installer (stable remains `v0.5.1`). Before initialization, `rein setup check` exits with code `3` and reports `config missing`. That one pre-init failure is expected; a platform, keyring, or Claude Code compatibility failure is a separate blocker that must be resolved. ## 2\. Configure the source project path Map the canonical project ID to the source device’s real absolute repository path: ```sh rein init \ --project local/my-project=/absolute/path/to/my-project ``` `rein init` prompts for the storage endpoint, bucket, credentials, and related settings. Credential input is hidden and stored through the operating system keyring. The encryption passphrase is not stored. Save the printed `profile_id`. It is not a secret. The second device must reuse that exact UUID to join the same encrypted sync set. Validate the configuration: ```sh rein setup check rein doctor --self-test rein list --agent claude ``` **Expected result:** successful initialization prints that `config.toml` and `state.json` were created, followed by `profile_id= (use this exact ID on every device)`. Afterward, when configuration and every installed-agent compatibility check pass, `rein setup check` and `rein doctor --self-test` exit `0`. The list command prints each discovered Claude session as agent, session ID, and project ID; an empty list means there is not yet a discoverable Claude session in the mapped project. The `--project` value has the form `PROJECT_ID=ABSOLUTE_PATH`. The left side is portable and identical on both devices; the right side is local to this device. Do not put storage credentials or a passphrase in that value. ## 3\. Push one Claude Code session Create or resume a harmless Claude Code session in the mapped repository, then list the discoverable sessions: ```sh rein list --agent claude ``` Copy the intended session ID. Preview the upload before mutating remote state: ```sh rein push --agent claude --session SESSION_ID --dry-run ``` Review the selected agent, session, project, and action. If they are correct, push that one session: ```sh rein push --agent claude --session SESSION_ID ``` **Expected result:** the dry run includes `would push ... snapshot(s)` and `dry_run=true`; the counts depend on whether the session is unchanged. The mutating command reports `pushed ... snapshot(s)` and `dry_run=false`. A successful push does not prove the other device can resume the session; complete the destination verification below. Use an explicit session ID for the first transfer. `--all` exists, but neither Reinstate nor a setup agent should select every session without your deliberate choice. ## 4\. Configure the destination with the same identity Install Reinstate on the second device, then map the same project ID to that device’s actual repository path: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project local/my-project=/different/absolute/path ``` Enter the same endpoint, bucket, storage credentials, and encryption passphrase. Reinstate verifies that the existing encrypted remote manifest belongs to the supplied profile before it saves local configuration. The paths may be different. For example, the project might be `C:\src\my-project` on Windows and `/Users/you/src/my-project` on macOS. The shared `local/my-project` identifier is the portable identity Reinstate uses to compute the correct destination layout. Validate without restoring: ```sh rein setup check rein doctor --self-test rein status rein pull --agent claude --session SESSION_ID --dry-run ``` Stop if compatibility is `UNTESTED` or `UNSUPPORTED`, the session is not associated with the expected project, or the dry-run destination is wrong. **Expected result:** initialization verifies and joins the existing encrypted manifest instead of creating a different sync set. `rein status` reports the remote revision and session count. The pull preview reports `would pull ... snapshot(s), dry_run=true` and prints the selected `claude:SESSION_ID`, destination path, and backup root. The destination must be derived from this device’s mapped repository, not copied from the source. ## 5\. Pull and resume in Claude Code Close Claude Code before a pull that will replace an existing local copy of the same session. Then restore: ```sh rein pull --agent claude --session SESSION_ID rein list --agent claude claude --resume SESSION_ID ``` Reinstate checks the planned Claude project directory after restore. Finding the same session ID somewhere else under Claude Code’s project storage is not accepted as successful restoration. **Expected result:** the pull reports `pulled ... snapshot(s), dry_run=false` and the resolved destination. The list command then includes the exact session ID, and Claude Code opens that session when given `claude --resume SESSION_ID`. Claude Code’s own screen text varies by version, so the durable success condition is the exact resumed session and mapped project, not a particular banner. ## How path remapping preserves native resume Claude Code groups sessions beneath a project directory derived from the device’s absolute project path. A raw copy from one operating system can land under a directory key that does not match the destination checkout. Reinstate associates the source session with the configured project ID. During restore it resolves that ID through the destination device’s `local_root` and recomputes Claude Code’s destination project key. This preserves same-vendor native resume without rewriting path-like text in ordinary conversation prose. ## Security checks for this transfer - Remote manifests and snapshots are encrypted before upload. - Storage credentials stay in the OS keyring; they are not session content. - The encryption passphrase is entered through a hidden prompt and is not stored by Reinstate. - Auth files, OAuth material, credential files, caches, and logs are excluded. - Pull validates before mutation and backs up an existing target when needed. - Divergent session histories create conflict records instead of a silent overwrite. A coding-agent transcript can contain a secret that a person or tool printed into the conversation. Encryption protects the uploaded artifact from the storage provider, but it does not make a leaked production credential safe. Keep secrets out of agent chats and read the full [security model](https://reinstate.dev/docs/security-model). ## Failure modes and common errors ### What does `config missing` (exit `3`) mean? **Meaning:** Local Reinstate configuration does not exist. This is expected only before first-device initialization. **Safe next action:** Run `rein init` with the intended project mapping; do not create config files by hand. ### What should I do after compatibility exit `5` or `UNTESTED`? **Meaning:** The installed Claude layout or version lacks release evidence. **Safe next action:** Stop writes, check the [compatibility matrix](https://reinstate.dev/compatibility), and use a documented supported version. ### Why does Reinstate report `no matching local sessions found` (exit `2`)? **Meaning:** The selected ID or adapter is not discoverable on the source. **Safe next action:** Run `rein list --agent claude` from the mapped project and copy the exact ID. ### Why does the destination report `remote profile manifest not found` (exit `4`)? **Meaning:** The destination profile, bucket, prefix, or endpoint does not identify the first device’s manifest. **Safe next action:** Recheck the copied `profile_id`, bucket, prefix, and service endpoint. Do not create an empty manifest. ### What should I do after a wrong-passphrase or authentication failure (exit `4`)? **Meaning:** Reinstate cannot decrypt or authenticate the remote state. **Safe next action:** Wait for the hidden prompt and retry with the original passphrase; never put it in a flag, environment value, or chat. ### Why does pull report `remote session not found` (exit `2`)? **Meaning:** The selected session was not pushed to this remote profile. **Safe next action:** Confirm `rein status`, the profile identity, and the exact source push result. ### What should I do after conflict exit `6`? **Meaning:** Local and remote histories diverged. **Safe next action:** Preserve both histories and the conflict record; inspect them with `rein conflicts` before choosing a resolution. ### What should I do after safety exit `7` while pulling? **Meaning:** Claude Code may still be writing the target session. **Safe next action:** Close every Claude Code process and rerun the exact scoped dry run before the pull. ### Why can pull succeed while native resume misses the session? **Meaning:** The path mapping or destination project key is wrong. **Safe next action:** Confirm the destination `local_root`, rerun the scoped dry run, and follow the [troubleshooting guide](https://reinstate.dev/docs/troubleshooting). ## Safe rollback and undo Reinstate does not provide a general `rein undo` or per-session remote delete command. Use these recovery boundaries instead: 1. Prefer `--dry-run`: it does not upload or restore the selected session, so there is nothing to undo. 2. If initialization used the wrong values, stop before a push. A later `rein init --force` backs up existing initialization state before replacement, but review `rein init --help` and re-enter secrets privately. 3. A push creates encrypted remote state. Do not delete `manifest.age` or an individual storage object manually; that can leave the profile inconsistent. Stop syncing and preserve the bucket while you determine the correct cleanup procedure. 4. Before replacing an existing session, pull plans name the backup root and a mutating pull backs up the target when applicable. Close Claude Code, preserve that backup, and do not copy files over the live session until you have identified the authoritative copy. 5. A conflict is a refusal, not a partial success. Keep the conflict record and use `rein conflicts list`, `rein conflicts show `, and an explicit resolution only after reviewing which side contains the needed work. ## Verification checklist The transfer is complete only when all of these are true: 1. `rein setup check` succeeds on both devices. 2. The source push targets one intended Claude Code session. 3. The destination pull dry-run shows the expected local project. 4. The mutating pull completes without a compatibility or conflict refusal. 5. `rein list --agent claude` finds the restored session on the destination. 6. `claude --resume SESSION_ID` opens the same Claude Code context. 7. No transcript text, credential, or passphrase was printed merely to prove success. For release qualification rather than personal evaluation, use the full [MacBook and Windows Phase 1 acceptance runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md). ## If the session does not resume Check the following in order: 1. Confirm both devices use the same `profile_id`, bucket, prefix, and canonical project ID. 2. Confirm each device maps that project ID to its own absolute local path. 3. Run `rein setup check` and resolve any Claude Code compatibility block. 4. Run `rein status` and the pull dry-run again. 5. Do not bypass a conflict or overwrite refusal until you understand which copy contains the work you need. 6. Follow the [troubleshooting guide](https://reinstate.dev/docs/troubleshooting) and preserve the generated backups. ## Claude Code sync FAQ ### Can Reinstate resume this Claude session in Codex? No. Reinstate Phase 1 restores a Claude Code session for native Claude Code resume. Cross-agent work requires an explicit portable handoff in a later phase; Reinstate does not silently translate transcripts. ### Do both computers need the same repository path? No. Both devices reuse the same canonical project ID, while each maps that ID to its own absolute checkout path. That mapping is the mechanism that supports different Windows and macOS paths. ### Does the destination need Anthropic credentials from the source? No. Authenticate Claude Code normally on the destination. Reinstate neither requests nor syncs Anthropic credentials, auth files, OS keyring contents, or OAuth material. ### Is Linux or WSL2 a certified Phase 1 resume target? No. The POSIX installer works on Linux and WSL2, and WSL2 has a documented smoke-test path, but neither is a certified Phase 1 agent-resume target in the current committed evidence. WSL1 is unsupported. ### Does a successful personal transfer mea Reinstate passed release acceptance? No. It proves only the devices, versions, storage, and session you tested. Release qualification requires the committed acceptance runbook and recorded, sanitized evidence for every required matrix row. CONTINUE READING ## Related Reinstate resources [Claude Code integration details](https://reinstate.dev/integrations/claude-code) [Getting started documentation](https://reinstate.dev/docs/getting-started) [Compatibility and tested versions](https://reinstate.dev/compatibility) [Security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/guides/sync-claude-code-sessions-across-devices Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-07-27. --- Practical guide # How to Sync Codex Sessions Across Devices > Set up encrypted Codex CLI session sync between two computers with Reinstate, including project mapping, dry runs, safe restore, and native resume. To sync a Codex CLI session across devices, install Reinstate on both computers, assign the repository one canonical project ID, push one explicit Codex session, dry-run and pull it on the destination, then continue it with the native codex resume command. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** July 27, 2026 - **Reviewed:** July 27, 2026 - **Reading time:** 12 minutes BEFORE YOU START ## Prerequisites - Codex CLI installed on the source and destination devices - An S3-compatible bucket and its endpoint and credentials - The same long encryption passphrase available privately on both devices ## Steps at a glance Allow about 30 minutes after the prerequisites are ready. Network speed, storage configuration, or agent setup can extend that estimate. 1. [Install and check the source device](https://reinstate.dev/guides/sync-codex-sessions-across-devices#install-source) Install the pinned Reinstate release, confirm its version, and run the read-only setup check before creating local configuration. 2. [Map the source repository](https://reinstate.dev/guides/sync-codex-sessions-across-devices#configure-source) Initialize Reinstate with one stable project ID mapped to the source repository's absolute path, then save the non-secret profile UUID. 3. [Dry-run and push one Codex session](https://reinstate.dev/guides/sync-codex-sessions-across-devices#push-session) List Codex sessions, select one exact session ID, inspect a non-mutating push plan, and upload only that encrypted native rollout snapshot. 4. [Join the destination to the profile](https://reinstate.dev/guides/sync-codex-sessions-across-devices#configure-destination) Install Reinstate on the destination and reuse the source profile UUID, storage settings, passphrase, and project ID with the destination path. 5. [Dry-run, pull, and resume natively](https://reinstate.dev/guides/sync-codex-sessions-across-devices#pull-and-resume) Inspect the destination restore plan, close Codex when replacement is required, pull the session, and resume the exact ID with Codex CLI. This visible sequence is also published as truthful `HowTo` structured data. Valid structured data can help machines understand the page, but it does not guarantee a rich result. Google [retired How-to rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) in 2023; the markup remains a Schema.org description for systems that consume it. ## What this workflow does This workflow transfers one supported Codex CLI session through object storage you control. Reinstate discovers the native rollout, normalizes the structural project working directory through a canonical project token, encrypts the snapshot locally, and uploads ciphertext. It reverses that mapping on the destination before restoring the rollout to Codex’s native date-partitioned session layout. This is **Codex to Codex** same-vendor continuity. Phase 1 does not turn a Codex rollout into a Claude Code transcript, and it does not silently reconstruct a session for another coding agent. The current public installer pins candidate `v0.6.0-rc.6`, whose tagged-artifact acceptance is pending on native Windows x64 (Apple Silicon macOS is deferred until that hardware returns); Intel macOS and Linux/WSL2 remain preview and unverified. Stable is `v0.5.1`. Confirm the platform and Codex CLI range on the [compatibility page](https://reinstate.dev/compatibility) before transferring real work. ## Key points - Reinstate restores **Codex sessions into Codex CLI**. It does not translate rollouts into Claude Code transcripts. - Use the same non-secret `profile_id` and canonical project ID on both devices, while mapping each device’s real local path separately. - Select one `SESSION_ID` and run both push and pull with `--dry-run` before either mutating command. - Snapshots and manifests are encrypted locally; storage credentials stay in the OS keyring, and the passphrase is not stored. - The installer-pinned `v0.6.0-rc.6` candidate’s tagged-artifact acceptance is pending on native Windows x64, with macOS deferred; stable `v0.5.1` remains dual-platform verified. This guide is not acceptance evidence for any other environment. ## Before you begin Prepare: - Codex CLI installed on both devices; - a Cloudflare R2, Amazon S3, or compatible bucket you control; - the service endpoint, bucket name, access-key ID, and secret access key; and - one long encryption passphrase available through private entry on both devices. Do not append the bucket name to the service endpoint. Reinstate does not need your OpenAI account credentials. Keep all credentials and the encryption passphrase out of prompts, shell history, screenshots, and issue reports. The examples use `local/my-project` as the canonical project ID. Choose your own stable identifier and reuse it exactly on each device. ### Platform and version qualifications | Environment | Installer path | Current qualification | | --- | --- | --- | | macOS native arm64 | POSIX installer | Stable and physically verified. | | macOS native amd64 | POSIX installer | Preview and unverified; do not infer certification from installer success. | | Windows 11 native amd64 | PowerShell installer | Stable and physically verified. | | Linux native | POSIX installer | Preview and unverified. | | WSL2 amd64 | POSIX installer | Preview and unverified. WSL1 is unsupported. | The repository currently records Codex CLI `0.133.0`–`0.146.0` as the tested stable range. `rein setup check` is authoritative for the installed version: `UNTESTED` and `UNSUPPORTED` block transfer. These facts describe committed evidence, not completed physical Reinstate acceptance on every platform. ## Command placeholders and parameters | Value or flag | Meaning | | --- | --- | | `local/my-project` | A stable, non-secret project ID reused on every device. It is not a filesystem path. | | `/absolute/path/to/my-project` | The source device’s real absolute checkout path. Replace it, including on Windows. | | `DEVICE_A_PROFILE_UUID` | The exact non-secret `profile_id` printed by the first successful `rein init`. | | `SESSION_ID` | The exact Codex session identifier selected from `rein list --agent codex`. | | `--project PROJECT_ID=ABSOLUTE_PATH` | Creates one canonical project mapping. The ID is shared; the absolute path is device-specific. | | `--profile-id UUID` | Joins an additional device to the first device’s existing encrypted sync profile. | | `--agent codex` | Restricts discovery or transfer to the Codex adapter. | | `--session SESSION_ID` | Restricts transfer to one session. It is safer than selecting every session with `--all`. | | `--dry-run` | Authenticates, validates, and prints the plan without uploading or restoring the selected session. | | `--json` | Requests machine-readable output; this guide uses it only for the version check. | ## 1\. Install and check the source device On macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` On native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` If your policy prohibits executing a downloaded script directly, use the download-and-inspect variants in the [getting-started documentation](https://reinstate.dev/docs/getting-started) before running it. Check the binary and local compatibility: ```sh rein version --json rein setup check ``` **Expected result:** `rein version --json` returns a JSON object whose version is `v0.6.0-rc.6` for the currently pinned installer (stable remains `v0.5.1`). Before initialization, `rein setup check` exits with code `3` and reports `config missing`. That one pre-init failure is expected; a platform, keyring, or Codex compatibility failure is a separate blocker that must be resolved. ## 2\. Give the repository a portable identity Configure the source device with a canonical project ID and its actual absolute path: ```sh rein init \ --project local/my-project=/absolute/path/to/my-project ``` Follow the hidden prompts for the storage configuration and credentials. Storage keys are placed in the supported operating-system keyring. Reinstate does not store the encryption passphrase. Save the printed `profile_id`. This non-secret UUID identifies the remote sync set and must be reused by every additional device. Verify the result: ```sh rein setup check rein doctor --self-test rein list --agent codex ``` **Expected result:** successful initialization prints that `config.toml` and `state.json` were created, followed by `profile_id= (use this exact ID on every device)`. Afterward, when configuration and every installed-agent compatibility check pass, `rein setup check` and `rein doctor --self-test` exit `0`. The list command prints each discovered Codex session as agent, session ID, and project ID; an empty list means there is not yet a discoverable Codex session in the mapped project. The `--project` value has the form `PROJECT_ID=ABSOLUTE_PATH`. The left side is portable and identical on both devices; the right side is local to this device. Do not put storage credentials or a passphrase in that value. ## 3\. Select and push one Codex session Create or resume a harmless Codex session in the mapped repository. List the sessions Reinstate can discover: ```sh rein list --agent codex ``` Copy the exact intended session ID. Preview the operation: ```sh rein push --agent codex --session SESSION_ID --dry-run ``` If the agent, session, and project are correct, push that session: ```sh rein push --agent codex --session SESSION_ID ``` **Expected result:** the dry run includes `would push ... snapshot(s)` and `dry_run=true`; the counts depend on whether the session is unchanged. The mutating command reports `pushed ... snapshot(s)` and `dry_run=false`. A successful push does not prove the other device can resume the session; complete the destination verification below. Start with one explicit session. The broader `--all` option must be a conscious human choice, not an automatic selection by an installer or coding agent. ## 4\. Join the same profile from the destination Install Reinstate on the destination, then reuse the source profile UUID and canonical project ID: ```sh rein init \ --profile-id DEVICE_A_PROFILE_UUID \ --project local/my-project=/different/absolute/path ``` Enter the same endpoint, bucket, storage credentials, and encryption passphrase. Reinstate requires the encrypted remote manifest for an additional device; it fails without creating a new local profile if that manifest is missing. Different local paths are expected. A checkout might live at `C:\work\my-project` on Windows and `/Users/you/work/my-project` on macOS. `local/my-project` connects those paths without making either machine’s absolute path the portable session identity. Run read-only checks: ```sh rein setup check rein doctor --self-test rein status rein pull --agent codex --session SESSION_ID --dry-run ``` Do not continue if Codex compatibility is not `SUPPORTED` or the planned destination project is wrong. **Expected result:** initialization verifies and joins the existing encrypted manifest instead of creating a different sync set. `rein status` reports the remote revision and session count. The pull preview reports `would pull ... snapshot(s), dry_run=true` and prints the selected `codex:SESSION_ID`, destination path, and backup root. The destination must be derived from this device’s mapped repository, not copied from the source. ## 5\. Pull and resume with Codex CLI Close Codex before replacing an existing local copy of the selected session. Then restore and verify discovery: ```sh rein pull --agent codex --session SESSION_ID rein list --agent codex codex resume SESSION_ID ``` The final command is Codex CLI’s native resume path. Reinstate prepares the vendor-native session; it does not execute or replace the Codex agent loop. **Expected result:** the pull reports `pulled ... snapshot(s), dry_run=false` and the resolved destination. The list command then includes the exact session ID, and Codex CLI opens that rollout when given `codex resume SESSION_ID`. Codex’s own screen text varies by version, so the durable success condition is the exact resumed session and mapped project, not a particular banner. ## Why Codex working-directory remapping matters Codex rollouts contain structural session metadata, including the source working directory. That path is normally different after a repository moves from Windows to macOS or between two user accounts. For mapped projects, Reinstate resolves the source working directory to the configured project ID during discovery. Export replaces that structural root with a `${REPO:}` token. Restore expands the token through the destination device’s configured path while preserving the native date-partitioned rollout layout. Reinstate rewrites allow-listed structural fields. It does not treat path-looking prose in ordinary conversation text as a filesystem destination. ## Security and restore boundaries - Session snapshots and manifests are encrypted locally with age passphrase encryption before they reach the bucket. - Object storage receives ciphertext and opaque object keys. - Storage credentials remain in the operating-system keyring. - The encryption passphrase is entered through a hidden prompt and is not stored. - Codex auth data, API credentials, `.env` files, caches, and logs are excluded. - A pull validates before mutation and preserves an existing target through backup behavior when applicable. - Divergent histories are not silently overwritten. Session transcripts can still contain secrets that were typed or printed during the conversation. Encryption protects remote storage, but it cannot undo disclosure inside the transcript or protect a compromised local machine. Review the [security model](https://reinstate.dev/docs/security-model) before syncing sensitive work. ## Failure modes and common errors ### What does `config missing` (exit `3`) mean? **Meaning:** Local Reinstate configuration does not exist. This is expected only before first-device initialization. **Safe next action:** Run `rein init` with the intended project mapping; do not create config files by hand. ### What should I do after compatibility exit `5` or `UNTESTED`? **Meaning:** The installed Codex layout or version lacks release evidence. **Safe next action:** Stop writes, check the [compatibility matrix](https://reinstate.dev/compatibility), and use a documented supported version. ### Why does Reinstate report `no matching local sessions found` (exit `2`)? **Meaning:** The selected ID or adapter is not discoverable on the source. **Safe next action:** Run `rein list --agent codex` from the mapped project and copy the exact ID. ### Why does the destination report `remote profile manifest not found` (exit `4`)? **Meaning:** The destination profile, bucket, prefix, or endpoint does not identify the first device’s manifest. **Safe next action:** Recheck the copied `profile_id`, bucket, prefix, and service endpoint. Do not create an empty manifest. ### What should I do after a wrong-passphrase or authentication failure (exit `4`)? **Meaning:** Reinstate cannot decrypt or authenticate the remote state. **Safe next action:** Wait for the hidden prompt and retry with the original passphrase; never put it in a flag, environment value, or chat. ### Why does pull report `remote session not found` (exit `2`)? **Meaning:** The selected session was not pushed to this remote profile. **Safe next action:** Confirm `rein status`, the profile identity, and the exact source push result. ### What should I do after conflict exit `6`? **Meaning:** Local and remote histories diverged. **Safe next action:** Preserve both histories and the conflict record; inspect them with `rein conflicts` before choosing a resolution. ### What should I do after safety exit `7` while pulling? **Meaning:** Codex may still be writing the target rollout. **Safe next action:** Close every Codex process and rerun the exact scoped dry run before the pull. ### Why can pull succeed while native resume misses the session? **Meaning:** The path mapping, date partition, or destination working directory is wrong. **Safe next action:** Confirm the destination mapping, rerun the scoped dry run, and follow the [troubleshooting guide](https://reinstate.dev/docs/troubleshooting). ## Safe rollback and undo Reinstate does not provide a general `rein undo` or per-session remote delete command. Use these recovery boundaries instead: 1. Prefer `--dry-run`: it does not upload or restore the selected session, so there is nothing to undo. 2. If initialization used the wrong values, stop before a push. A later `rein init --force` backs up existing initialization state before replacement, but review `rein init --help` and re-enter secrets privately. 3. A push creates encrypted remote state. Do not delete `manifest.age` or an individual storage object manually; that can leave the profile inconsistent. Stop syncing and preserve the bucket while you determine the correct cleanup procedure. 4. Before replacing an existing rollout, pull plans name the backup root and a mutating pull backs up the target when applicable. Close Codex, preserve that backup, and do not copy files over the live rollout until you have identified the authoritative copy. 5. A conflict is a refusal, not a partial success. Keep the conflict record and use `rein conflicts list`, `rein conflicts show `, and an explicit resolution only after reviewing which side contains the needed work. ## Verification checklist Treat the handoff as verified only when: 1. Both devices pass `rein setup check`. 2. The source push names one intended Codex session. 3. The destination dry-run resolves the expected repository mapping. 4. The pull finishes without a compatibility, active-session, or conflict refusal. 5. `rein list --agent codex` discovers the restored session locally. 6. `codex resume SESSION_ID` opens the expected native Codex context. 7. Verification did not print transcript contents, storage credentials, or the passphrase. Use the repository’s [Phase 1 MacBook and Windows acceptance runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md) when certifying a release rather than evaluating a personal setup. ## If resume fails Work through these checks: 1. Confirm both devices share the same `profile_id`, bucket, prefix, and canonical project ID. 2. Confirm the destination maps that project ID to the real local repository path. 3. Check that the installed Codex CLI version is inside the currently supported stable range. 4. Run `rein status` and repeat the pull dry-run. 5. Preserve any conflict record or backup until you know which session copy is authoritative. 6. Continue with the [troubleshooting documentation](https://reinstate.dev/docs/troubleshooting). ## Codex session sync FAQ ### Can Reinstate resume this Codex rollout in Claude Code? No. Reinstate Phase 1 restores a Codex rollout for native Codex CLI resume. Cross-agent work requires an explicit portable handoff in a later phase; Reinstate does not silently translate transcripts. ### Do both computers need the same repository path? No. Both devices reuse the same canonical project ID, while each maps that ID to its own absolute checkout path. Reinstate expands the portable project token to the destination path while preserving Codex’s native date partition. ### Does the destination need OpenAI credentials from the source? No. Authenticate Codex normally on the destination. Reinstate neither requests nor syncs OpenAI credentials, Codex auth data, OS keyring contents, or API keys. ### Is Linux or WSL2 a certified Phase 1 resume target? No. The POSIX installer works on Linux and WSL2, and WSL2 has a documented smoke-test path, but neither is a certified Phase 1 agent-resume target in the current committed evidence. WSL1 is unsupported. ### Does a successful personal transfer mea Reinstate passed release acceptance? No. It proves only the devices, versions, storage, and session you tested. Release qualification requires the committed acceptance runbook and recorded, sanitized evidence for every required matrix row. CONTINUE READING ## Related Reinstate resources [Codex integration details](https://reinstate.dev/integrations/codex) [Getting started documentation](https://reinstate.dev/docs/getting-started) [Compatibility and tested versions](https://reinstate.dev/compatibility) [Security model](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/guides/sync-codex-sessions-across-devices Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-07-27. --- Practical guide # Use Cloudflare R2 for Encrypted Coding-Agent Session Storage > Configure a private Cloudflare R2 bucket and bucket-scoped S3 credentials for Reinstate, then verify encrypted Claude Code or Codex storage. To use Cloudflare R2 with Reinstate, create a private R2 bucket, issue an Object Read & Write S3 API token scoped to that bucket, initialize Reinstate with the account or jurisdiction endpoint and region auto, then dry-run and push one selected session. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** September 5, 2026 - **Reviewed:** September 5, 2026 - **Reading time:** 14 minutes BEFORE YOU START ## Prerequisites - A Cloudflare account with R2 enabled and authority to create a bucket and R2 API token - Reinstate (the installer's v0.6.0-rc.6 candidate; stable is v0.5.1) on a compatible device with Claude Code or Codex CLI - A harmless session in a repository whose absolute local path you know - A long encryption passphrase that will be entered privately and is not stored ## Steps at a glance Allow about 30 minutes after the prerequisites are ready. Network speed, storage configuration, or agent setup can extend that estimate. 1. [Create a private R2 bucket](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage#create-private-bucket) Create one R2 bucket, choose its location or jurisdiction deliberately, leave public development URL and custom-domain access disabled, and record its name. 2. [Create bucket-scoped S3 credentials](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage#create-scoped-credentials) Generate an R2 S3 API token with Object Read & Write permission for only the selected bucket, then store its access-key pair outside chat and source control. 3. [Install and check Reinstate](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage#install-and-check) Install the pinned Reinstate release, verify its version, and run the read-only setup check before writing local configuration. 4. [Initialize Reinstate with the R2 endpoint](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage#initialize-reinstate) Pass the account or jurisdiction-specific R2 S3 endpoint, region auto, bucket name, and project mapping to init, then enter credentials through hidden prompts. 5. [Dry-run, push, and verify ciphertext storage](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage#push-and-verify) Select one harmless Claude Code or Codex session, inspect a non-mutating push plan, push it, and verify only encrypted objects under the generated profile prefix. This visible sequence is also published as truthful `HowTo` structured data. Valid structured data can help machines understand the page, but it does not guarantee a rich result. Google [retired How-to rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) in 2023; the markup remains a Schema.org description for systems that consume it. ## What this guide configures This guide connects Reinstate — the installer’s `v0.6.0-rc.6` candidate; stable is `v0.5.1` — to an existing Cloudflare R2 bucket through R2’s S3-compatible API. Cloudflare owns the account, bucket, location, API token, public-access switches, retention, and billing. Reinstate owns the local project mapping, encrypted profile manifest, encrypted session snapshots, and same-vendor restore workflow. | Responsibility | Cloudflare R2 | Reinstate | | --- | --- | --- | | Create the bucket | Yes | No | | Generate and revoke the R2 API token | Yes | No | | Keep public URL and custom-domain access disabled | Yes | No | | Test object write and delete access | Receives S3 API calls | `rein init` runs the probe | | Encrypt session content before upload | No | Yes, locally with the passphrase | | Choose the session and project | No | Yes | | Empty or delete the R2 bucket | Yes | No | `rein init` does not create an R2 bucket or token. It expects them to exist, writes and deletes a two-byte probe beneath the new profile prefix, and saves local configuration only after that probe succeeds. The first persistent `manifest.age` appears after the first successful push, not after first-device initialization. ## Key points - R2 buckets are private by default. Keep the public development URL and custom-domain access disabled because Reinstate uses authenticated S3 API requests. - Use the R2 S3 endpoint from the token confirmation or account overview: `https://ACCOUNT_ID.r2.cloudflarestorage.com`. Keep the bucket name separate and use `--region auto`. - EU or FedRAMP jurisdiction buckets require the matching `https://ACCOUNT_ID.JURISDICTION.r2.cloudflarestorage.com` endpoint. - Choose **Object Read & Write** and apply the token to the specific bucket. Read-only access cannot complete Reinstate’s write-and-delete initialization probe. - Reinstate encrypts the manifest and snapshots before R2 receives them. Cloudflare’s encryption at rest is an additional provider control. - Session resume remains **same-vendor**: Claude Code to Claude Code and Codex CLI to Codex CLI. - Stable Reinstate `v0.5.1` passed dual-platform tagged-artifact acceptance on Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 are preview and unverified. This guide is not itself acceptance evidence. ## Before you begin Use a dedicated R2 bucket for the first evaluation when practical. Cloudflare can scope an Object Read & Write token to one or more complete buckets, not to a generated Reinstate profile prefix through the dashboard flow. A dedicated bucket therefore gives the evaluation token a smaller and easier-to-audit scope. An R2 account ID and bucket name are not authentication secrets, but they can still expose organizational identifiers. Redact them from public logs and screenshots. Never paste the access-key ID, secret access key, encryption passphrase, transcript, or downloaded snapshot into a coding-agent prompt. ### Platform and release qualifications | Environment | Installer path | Current qualification | | --- | --- | --- | | macOS native arm64 | POSIX installer | Stable and physically verified. | | macOS native amd64 | POSIX installer | Preview and unverified. | | Windows 11 native amd64 | PowerShell installer | Stable and physically verified. | | Linux native | POSIX installer | Preview and unverified. | | WSL2 amd64 | POSIX installer | Preview and unverified. WSL1 is unsupported. | Storage access does not override agent compatibility. `rein setup check` must report `SUPPORTED` for the installed agent before a push or pull. ## Command placeholders and parameters | Value or flag | Meaning | | --- | --- | | `ACCOUNT_ID` | The non-secret Cloudflare account ID shown in R2 account details. Replace it in the endpoint. | | `JURISDICTION` | Use only for a jurisdiction bucket, currently `eu` or `fedramp`; omit the segment for a default bucket. | | `https://ACCOUNT_ID.r2.cloudflarestorage.com` | The default R2 S3 API service endpoint. It does not include the bucket name. | | `YOUR_PRIVATE_BUCKET` | The R2 bucket name only. Do not append it to the endpoint. | | `local/my-project` | A stable, non-secret project ID reused on every Reinstate device. | | `/absolute/path/to/my-project` | The current device’s real absolute repository path. | | `AGENT` | Replace with exactly `claude` or `codex`. | | `SESSION_ID` | Copy the exact intended ID from `rein list --agent AGENT`. | | `--region auto` | Uses the signing Region required by the R2 S3-compatible API. | | `--session SESSION_ID` | Selects one session instead of every discovered session. | | `--dry-run` | Authenticates, validates, and reports the plan without uploading the selected session. | ## 1\. Create a private R2 bucket In the Cloudflare dashboard: 1. Open R2 object storage and create a bucket. 2. Choose Automatic location, a location hint, or a jurisdiction according to your data-location requirements. 3. Choose the intended default storage class. 4. Leave the public development URL disabled. 5. Do not connect a custom domain. 6. Record the bucket name and whether it uses the default, `eu`, or `fedramp` jurisdiction. Cloudflare’s official [R2 bucket guide](https://developers.cloudflare.com/r2/buckets/create-buckets/) documents creation and states that buckets are not public by default. Public access requires a separate action described in the [public-bucket documentation](https://developers.cloudflare.com/r2/buckets/public-buckets/); Reinstate does not need it. Location hints are best-effort, while jurisdiction selection controls the required endpoint and cannot later be changed. Review the [R2 data-location guide](https://developers.cloudflare.com/r2/reference/data-location/) before choosing. Do not add a bucket lock to the evaluation prefix. R2 lock rules can prevent deletion and overwrite, while Reinstate’s init probe must be deleted and the encrypted manifest changes as sessions are pushed. Review [R2 bucket-lock behavior](https://developers.cloudflare.com/r2/buckets/bucket-locks/) before combining retention with a live sync profile. **Expected result:** the R2 dashboard shows one private bucket with public development URL access disallowed and no custom domain. You have recorded only the non-secret bucket name, account ID, and jurisdiction needed to choose the S3 API endpoint. ## 2\. Create bucket-scoped S3 credentials From R2 Overview, open API Tokens and create an account or user token: 1. Choose **Object Read & Write**. 2. Choose **Apply to specific buckets only**. 3. Select only the evaluation bucket. 4. Create the token. 5. Copy the generated Access Key ID, Secret Access Key, and S3 endpoint into a password manager. The secret is not shown again. Cloudflare documents this exact provider flow in [Get started with the R2 S3 API](https://developers.cloudflare.com/r2/get-started/s3/) and explains account-token, user-token, bucket scope, and permission behavior in the [R2 authentication reference](https://developers.cloudflare.com/r2/api/tokens/). Object Read & Write is the least built-in permission that covers the read, list, write, and delete behavior needed by the current Reinstate backend. Reinstate accepts the generated access-key ID and secret access key. It does not accept an additional session-token field, so do not substitute R2 temporary credentials that require one. Do not use a general Cloudflare API bearer token; Reinstate talks to the S3-compatible API. **Expected result:** the token is limited to Object Read & Write on the one selected bucket. It cannot administer unrelated buckets, public access, custom domains, lifecycle, or the rest of the Cloudflare account. You have stored both generated credential values privately and have the matching S3 API endpoint. ## 3\. Install and check Reinstate On macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` On native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` If policy requires inspection first, use the download-and-review variants in the [getting-started documentation](https://reinstate.dev/docs/getting-started). ```sh rein version --json rein setup check ``` **Expected result:** the pinned installer reports `v0.6.0-rc.6`, the current release candidate; stable remains `v0.5.1`. Before initialization, `rein setup check` exits with code `3` and reports `config missing`. Resolve a platform, keyring, or installed-agent compatibility failure separately; working R2 credentials cannot make an unsupported agent layout safe. ## 4\. Initialize Reinstate with the R2 endpoint For a default R2 bucket, replace every placeholder before running: ```sh rein init \ --endpoint https://ACCOUNT_ID.r2.cloudflarestorage.com \ --region auto \ --bucket YOUR_PRIVATE_BUCKET \ --project local/my-project=/absolute/path/to/my-project ``` For a jurisdiction bucket, insert `eu` or `fedramp` between the account ID and `r2` exactly as Cloudflare shows: ```text https://ACCOUNT_ID.JURISDICTION.r2.cloudflarestorage.com ``` The endpoint is the R2 S3 service endpoint, not a public `r2.dev` URL, custom domain, or bucket path. The first hidden prompt accepts the generated Access Key ID; the second accepts its Secret Access Key. Do not put either value in this command, an environment variable, shell history, or a coding-agent conversation. During initialization, Reinstate: 1. generates a non-secret `profile_id`; 2. derives the default `profiles/` prefix; 3. sends a conditional two-byte probe object; 4. deletes that probe; 5. stores the R2 credential reference in config and the credential values in the operating-system keyring; and 6. writes local `config.toml` and `state.json` only after the remote probe succeeds. Cloudflare’s current [S3 compatibility table](https://developers.cloudflare.com/r2/api/s3/api/) lists the `PutObject`, `GetObject`, `HeadObject`, `DeleteObject`, and `ListObjectsV2` operations used by Reinstate and requires Region `auto`. Then validate: ```sh rein setup check rein doctor --self-test ``` **Expected result:** initialization prints `initialized reinstate home (config.toml + state.json)`, a `profile_id=`, and a keyring credential reference. Both checks exit `0` when every installed-agent compatibility check also passes. The R2 bucket has no persistent manifest yet; the temporary probe was removed. ## 5\. Dry-run, push, and verify ciphertext storage Use a harmless test session and replace `AGENT` with `claude` or `codex`: ```sh rein list --agent AGENT rein push --agent AGENT --session SESSION_ID --dry-run rein push --agent AGENT --session SESSION_ID rein status ``` Enter the encryption passphrase through Reinstate’s hidden prompt. It is separate from the R2 secret access key and is not stored by Reinstate. Do not use `--all` unless you deliberately intend to sync every discovered session. **Expected result:** the preview reports `would push ... snapshot(s)` with `dry_run=true`. The mutating command reports `pushed ... snapshot(s)` with `dry_run=false`, and status reports a remote revision. In the R2 dashboard, the exact generated prefix contains: ```text profiles//manifest.age profiles//snapshots/.age ``` There should be no plaintext transcript, auth file, `.env` file, access key, or passphrase object. A `.age` filename alone is not cryptographic proof; the committed [Phase 1 acceptance runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md) defines the controlled ciphertext inspection used for release qualification. This personal check does not claim physical Reinstate acceptance. ## Security boundaries - Reinstate encrypts the session locally before upload. Cloudflare still sees the account, bucket, object sizes, request timing, and encrypted object keys. - Cloudflare documents automatic encryption at rest and TLS-protected transfer for R2. Those provider controls are defense in depth, not a replacement for Reinstate’s client-side encryption. See the official [R2 data-security reference](https://developers.cloudflare.com/r2/reference/data-security/). - Compromise of the bucket alone should not reveal transcript plaintext without the Reinstate passphrase, but an attacker with write or delete access can still remove, replace, or roll back ciphertext. Encryption is not availability protection. - Do not enable a public development URL or custom domain for session storage. A private S3 endpoint with scoped credentials is the intended access path. - Known auth files, OAuth material, credential stores, `.env` files, caches, and logs are excluded. A secret typed into a transcript is still transcript content and must be rotated if exposed. ## Failure modes and common errors ### Why does initialization report `storage probe put failed` (exit `4`)? **Likely cause:** Wrong endpoint, bucket, credential, jurisdiction, or a read-only token. **Safe next action:** Compare the token confirmation endpoint and selected bucket; require Object Read & Write on that bucket only. ### Why does initialization report `storage probe cleanup failed` (exit `4`)? **Likely cause:** Delete is denied or a bucket lock covers the generated probe prefix. **Safe next action:** Preserve the error, remove the stray probe through approved R2 tooling, and fix the token or lock before retrying. ### What causes `SignatureDoesNotMatch` or an authorization failure? **Likely cause:** The account ID, jurisdiction endpoint, access-key pair, or Region is wrong. **Safe next action:** Use the exact R2 S3 endpoint, `--region auto`, and the credential generated for the selected bucket. ### Why is `config missing` (exit `3`) after failed init? **Likely cause:** Reinstate intentionally did not save local config because the remote probe failed. **Safe next action:** Fix R2 first and rerun the same reviewed `rein init`. ### What should I do after compatibility exit `5` or `UNTESTED`? **Likely cause:** The installed coding-agent version or layout lacks release evidence. **Safe next action:** Stop transfer and check the [compatibility matrix](https://reinstate.dev/compatibility). ### Why does Reinstate report `no matching local sessions found` (exit `2`)? **Likely cause:** `AGENT` or `SESSION_ID` does not identify a discoverable local session. **Safe next action:** Run `rein list --agent claude` or `rein list --agent codex` and select one exact ID. ### Why is `remote profile manifest not found` on another device? **Likely cause:** Profile UUID, bucket, prefix, endpoint, or jurisdiction differs from the first device. **Safe next action:** Reuse every non-secret storage coordinate and the exact first-device `profile_id`; do not create an empty manifest. ### What should I do after conflict exit `6`? **Likely cause:** The local and remote copies diverged after sync. **Safe next action:** Preserve the conflict record and both histories; resolve explicitly instead of deleting R2 objects. ## Safe rollback and undo Reinstate does not provide a general `rein undo` or remote-session delete command. 1. A push `--dry-run` creates no session object, so it needs no rollback. 2. A failed storage probe does not save `config.toml` or `state.json`, although Reinstate may already have created its local home directories. 3. A successful first-device init has saved local configuration and the credential in the OS keyring, but its temporary R2 probe has been deleted. 4. If the configuration is wrong, stop before pushing. `rein init --force` backs up local config and state before replacement; it does not delete remote objects or revoke the R2 token. 5. After a push, never delete only `manifest.age`. Stop every device, record the exact profile UUID, preserve needed backups, then remove the complete `profiles//` tree through approved R2 tooling only when its loss is acceptable. 6. Revoke the dedicated R2 API token after cleanup. Deleting local Reinstate data does not revoke the token or delete R2 objects. Cloudflare documents that emptying or deleting a bucket is irreversible and that a bucket must be empty before deletion. Review the official [R2 deletion procedure](https://developers.cloudflare.com/r2/buckets/delete-buckets/) before any cleanup. Do not apply a short lifecycle rule as a casual undo: new objects uploaded while the rule is active are also subject to expiration. ## Verification checklist - [ ] The selected R2 bucket is private: its `r2.dev` development URL is disabled and no custom domain exposes the session objects. - [ ] The dedicated API token has Object Read & Write access only to the reviewed bucket, and its S3 endpoint matches the intended standard, European Union, or FedRAMP jurisdiction. - [ ] Reinstate uses that exact endpoint with `--region auto`, and `rein setup check` plus `rein doctor --self-test` complete without a compatibility, keyring, filesystem, or crypto failure. - [ ] The reviewed `rein push --agent AGENT --session SESSION_ID --dry-run` selects exactly one intended session and reports no mutation. - [ ] The real push succeeds, `rein status` reports the expected remote revision, and the bucket contains only age-encrypted `manifest.age` and `snapshots/*.age` objects beneath the generated profile prefix. - [ ] No command output, shell history, commit, log, or screenshot contains the access-key secret or passphrase, and no physical two-device acceptance is claimed until the relevant release scenario has passed. ## Current limitations - Reinstate does not create or delete R2 buckets, API tokens, public-access settings, custom domains, lifecycle rules, storage classes, or bucket locks. - Reinstate accepts the access-key pair generated for an R2 API token but no additional session-token field. - Dashboard token scope is bucket-level. Reinstate generates the first profile UUID during initialization, so the token cannot be pre-scoped to that exact profile through this provider flow. - Lifecycle expiration or an Infrequent Access policy can affect availability and cost. Reinstate does not coordinate R2 lifecycle or storage-class transitions. - R2’s S3 compatibility evolves. This guide depends only on the current Put/Get/Head/Delete/List and conditional-write behavior used by Reinstate. - Phase 1 transfers full immutable session snapshots; delta transfer, retention controls, and remote garbage collection remain later work. - Current native resume is same-vendor only. Stable physical verification is limited to Apple Silicon macOS and native Windows x64. ## Cloudflare R2 storage FAQ ### Does the R2 bucket need a public URL or custom domain? No. Leave the public development URL disabled and do not connect a custom domain. Reinstate authenticates directly to the private S3 API endpoint with the bucket-scoped credential. ### Which R2 token permission does Reinstate need? Use Object Read & Write and apply it only to the selected bucket. Read-only cannot write snapshots or delete the initialization probe. Admin Read & Write is broader than this workflow requires. ### Why is the R2 Region `auto`? Cloudflare’s S3 compatibility documentation specifies `auto` as the R2 Region. The endpoint, not an AWS Region string, identifies the Cloudflare account and any `eu` or `fedramp` jurisdiction. ### Can several Reinstate profiles share one R2 bucket? Yes. The default keyspace is `profiles//`, so profiles have separate object prefixes. A dedicated bucket is still simpler for token scope and cleanup because the provider token is bucket-scoped, not profile-prefix-scoped in this setup. ### What happens if the R2 bucket is compromised? An attacker who has only bucket contents should receive age-encrypted manifests and snapshots, not plaintext session data. An attacker with object permissions can still delete or replace ciphertext, observe metadata, and deny sync. Revoke the exposed R2 token, preserve local copies, and follow the [security model](https://reinstate.dev/docs/security-model). ### How do I add the second computer? Finish one successful push first so `manifest.age` exists. On the second computer, run `rein init --profile-id DEVICE_A_PROFILE_UUID` with the same endpoint, `auto` Region, bucket, token scope, passphrase, and canonical project ID but that computer’s own absolute path. Then follow the agent-specific Claude Code or Codex guide for the pull and native resume. CONTINUE READING ## Related Reinstate resources [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Codex CLI integration](https://reinstate.dev/integrations/codex) [Amazon S3 storage guide](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage) [Getting started documentation](https://reinstate.dev/docs/getting-started) [Security model](https://reinstate.dev/docs/security-model) [Compatibility and tested versions](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-05. --- Practical guide # Use Amazon S3 for Encrypted Coding-Agent Session Storage > Configure a private Amazon S3 bucket and least-privilege credentials for Reinstate, then verify encrypted Claude Code or Codex session storage. To use Amazon S3 with Reinstate, create a private general purpose bucket, grant a dedicated non-root credential access only to the Reinstate object prefix, initialize Reinstate with the matching regional S3 endpoint and Region, then dry-run and push one selected session. - **By:** [Harjot Singh Rana](https://harjot.co/) - **Published:** July 27, 2026 - **Updated:** September 5, 2026 - **Reviewed:** September 5, 2026 - **Reading time:** 15 minutes BEFORE YOU START ## Prerequisites - An AWS account and authority to create a private S3 bucket, IAM policy, and access key - Reinstate (the installer's v0.6.0-rc.6 candidate; stable is v0.5.1) on a compatible device with Claude Code or Codex CLI - A harmless session in a repository whose absolute local path you know - A long encryption passphrase that will be entered privately and is not stored ## Steps at a glance Allow about 35 minutes after the prerequisites are ready. Network speed, storage configuration, or agent setup can extend that estimate. 1. [Create a private S3 bucket](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage#create-private-bucket) Create a general purpose bucket in one AWS Region, keep all Block Public Access settings enabled, and record the bucket name and Region separately. 2. [Grant only the required S3 permissions](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage#create-scoped-credentials) Attach a prefix-limited policy to a dedicated non-root IAM principal and create the access-key pair that Reinstate can store in the operating-system keyring. 3. [Install and check Reinstate](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage#install-and-check) Install the pinned Reinstate release, verify its version, and run the read-only setup check before writing local configuration. 4. [Initialize Reinstate with the S3 endpoint](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage#initialize-reinstate) Pass the regional S3 service endpoint, matching AWS Region, bucket name, and project mapping to init, then enter both credential values through hidden prompts. 5. [Dry-run, push, and verify ciphertext storage](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage#push-and-verify) Select one harmless Claude Code or Codex session, inspect a non-mutating push plan, push it, and verify only encrypted objects under the generated profile prefix. This visible sequence is also published as truthful `HowTo` structured data. Valid structured data can help machines understand the page, but it does not guarantee a rich result. Google [retired How-to rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) in 2023; the markup remains a Schema.org description for systems that consume it. ## What this guide configures This guide connects Reinstate — the installer’s `v0.6.0-rc.6` candidate; stable is `v0.5.1` — to an existing Amazon S3 bucket. Amazon Web Services owns the bucket, Region, IAM identity, access key, public access settings, retention, and billing. Reinstate owns the local project mapping, encrypted profile manifest, encrypted session snapshots, and same-vendor restore workflow. | Responsibility | Amazon S3 or IAM | Reinstate | | --- | --- | --- | | Create the bucket | Yes | No | | Create and revoke credentials | Yes | No | | Keep the bucket private | Yes | No | | Test object write and delete access | Receives API calls | `rein init` runs the probe | | Encrypt session content before upload | No | Yes, locally with the passphrase | | Choose the session and project | No | Yes | | Delete the provider bucket | Yes | No | `rein init` does not create a bucket or IAM principal. It expects those provider resources to exist, writes and deletes a two-byte probe under the new profile prefix, and saves local configuration only after that probe succeeds. The first persistent `manifest.age` is created by the first successful push, not by first-device initialization. ## Key points - Use a private general purpose bucket and keep Amazon S3 Block Public Access enabled. Reinstate does not need a website endpoint or public object access. - The S3 service endpoint and bucket are separate inputs. For a normal Region, use `https://s3.AWS_REGION.amazonaws.com`, then pass the same Region through `--region`. - Reinstate requires `ListBucket`, `GetObject`, `PutObject`, and `DeleteObject` capability for its generated `profiles//` object tree. - Reinstate encrypts the manifest and snapshots before S3 receives them. S3’s default server-side encryption is an additional provider control, not a replacement for Reinstate’s passphrase. - Reinstate accepts an access-key ID and secret-access-key pair but no AWS session token. This is a current limitation because AWS recommends temporary credentials where possible. - Session resume remains **same-vendor**: Claude Code to Claude Code and Codex CLI to Codex CLI. - Stable Reinstate `v0.5.1` passed dual-platform tagged-artifact acceptance on Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 are preview and unverified. This guide is not itself acceptance evidence. ## Before you begin Use a dedicated bucket for the first evaluation when practical. A dedicated bucket makes IAM scope, cleanup, cost attribution, and accidental public-access review easier than sharing an unrelated production bucket. Amazon S3 bucket names are not secrets, but they can reveal organization or project names. Use placeholders in tickets, screenshots, analytics, and coding agent prompts. Never paste an access-key ID, secret access key, passphrase, real transcript, or downloaded snapshot into a prompt. ### Platform and release qualifications | Environment | Installer path | Current qualification | | --- | --- | --- | | macOS native arm64 | POSIX installer | Stable and physically verified. | | macOS native amd64 | POSIX installer | Preview and unverified. | | Windows 11 native amd64 | PowerShell installer | Stable and physically verified. | | Linux native | POSIX installer | Preview and unverified. | | WSL2 amd64 | POSIX installer | Preview and unverified. WSL1 is unsupported. | Storage access does not override agent compatibility. `rein setup check` must report `SUPPORTED` for the installed agent before a push or pull. ## Command placeholders and parameters | Value or flag | Meaning | | --- | --- | | `AWS_REGION` | The bucket’s immutable AWS Region, such as `us-east-1`; use the real value from the bucket properties. | | `https://s3.AWS_REGION.amazonaws.com` | The regional S3 REST service endpoint. Replace `AWS_REGION`; do not use an S3 website endpoint. | | `YOUR_PRIVATE_BUCKET` | The bucket name only. Do not append it to the endpoint URL. | | `local/my-project` | A stable, non-secret project ID reused on every Reinstate device. | | `/absolute/path/to/my-project` | The current device’s real absolute repository path. | | `AGENT` | Replace with exactly `claude` or `codex`. | | `SESSION_ID` | Copy the exact intended ID from `rein list --agent AGENT`. | | `--region AWS_REGION` | Sets the AWS signing Region; it must match the bucket and endpoint. | | `--session SESSION_ID` | Selects one session instead of every discovered session. | | `--dry-run` | Authenticates, validates, and reports the plan without uploading the selected session. | ## 1\. Create a private S3 bucket In the Amazon S3 console: 1. Create a **general purpose bucket**. 2. Choose the Region where the encrypted session objects should live. 3. Keep Object Ownership at the default bucket-owner-enforced setting with ACLs disabled. 4. Keep all four Block Public Access settings enabled. 5. Do not enable static website hosting. 6. Record the bucket name and Region separately. AWS documents that bucket name, owner, and Region cannot be changed after creation, and recommends leaving Block Public Access enabled unless a workload explicitly requires public access. Reinstate does not require it. Review the official [S3 bucket creation guide](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html), [Block Public Access guidance](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html), and [regional endpoint table](https://docs.aws.amazon.com/general/latest/gr/s3.html) before choosing the Region. Do not add an Object Lock retention rule to the evaluation prefix. Reinstate’s initialization probe must delete its temporary object, and later sync operations update the encrypted manifest. AWS documents that Object Lock can prevent deletion or overwrite during retention in the [S3 Object Lock guide](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html). **Expected result:** the S3 console shows one private general purpose bucket in the intended Region, all Block Public Access controls enabled, ACLs disabled, and no website endpoint. You have recorded only the non-secret bucket name, Region, and regional REST endpoint. ## 2\. Grant only the required S3 permissions Reinstate uses these S3 operations: | Reinstate behavior | S3 API behavior | Required IAM action | | --- | --- | --- | | List the profile object tree | `ListObjectsV2` | `s3:ListBucket` | | Read a manifest or snapshot | `GetObject` or `HeadObject` | `s3:GetObject` | | Write the probe, manifest, or snapshot | `PutObject` | `s3:PutObject` | | Remove the initialization probe | `DeleteObject` | `s3:DeleteObject` | AWS’s [S3 API permission mapping](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-policy-actions.html) confirms the bucket-level and object-level actions. The following identity policy is a starting point for a dedicated bucket. Replace the placeholder in both ARNs; it contains no credential: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "ListReinstateProfiles", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::REPLACE_WITH_BUCKET_NAME", "Condition": { "StringLike": { "s3:prefix": ["profiles/*"] } } }, { "Sid": "ManageReinstateProfileObjects", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::REPLACE_WITH_BUCKET_NAME/profiles/*" } ] } ``` Attach the reviewed policy to a dedicated non-root IAM principal. Reinstate does not accept the session token that accompanies AWS STS temporary credentials, so it cannot yet follow AWS’s preferred temporary-credential path. If your organization permits this evaluation, create a long-term access-key pair for that dedicated least-privilege principal, rotate it according to policy, and never create or use root access keys. Read AWS’s [IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) and [access-key security guidance](https://docs.aws.amazon.com/IAM/latest/UserGuide/securing_access-keys.html) before proceeding. **Expected result:** the dedicated credential can list only the permitted `profiles/` keyspace and can get, put, and delete objects there. It cannot change bucket policy, public access, lifecycle, website configuration, or unrelated buckets. Keep the access-key ID and secret access key in a password manager until the hidden Reinstate prompts appear. ## 3\. Install and check Reinstate On macOS, Linux, or WSL2: ```sh curl -fsSL https://reinstate.dev/install.sh | sh ``` On native Windows PowerShell: ```powershell irm https://reinstate.dev/install.ps1 | iex ``` If policy requires inspection first, use the download-and-review variants in the [getting-started documentation](https://reinstate.dev/docs/getting-started). ```sh rein version --json rein setup check ``` **Expected result:** the pinned installer reports `v0.6.0-rc.6`, the current release candidate; stable remains `v0.5.1`. Before initialization, `rein setup check` exits with code `3` and reports `config missing`. Resolve a platform, keyring, or installed-agent compatibility failure separately; a working S3 bucket cannot make an unsupported agent layout safe. ## 4\. Initialize Reinstate with the S3 endpoint Replace every placeholder before running: ```sh rein init \ --endpoint https://s3.AWS_REGION.amazonaws.com \ --region AWS_REGION \ --bucket YOUR_PRIVATE_BUCKET \ --project local/my-project=/absolute/path/to/my-project ``` The endpoint is the regional REST service endpoint, not the bucket URL and not an `s3-website` endpoint. The bucket stays in `--bucket`. The first hidden prompt accepts the dedicated access-key ID; the second accepts its secret access key. Do not put either value in this command, an environment variable, shell history, or a coding-agent conversation. During initialization, Reinstate: 1. generates a non-secret `profile_id`; 2. derives the default `profiles/` prefix; 3. sends a conditional two-byte probe object; 4. deletes that probe; 5. stores the S3 credential reference in config and the credential values in the operating-system keyring; and 6. writes local `config.toml` and `state.json` only after the remote probe succeeds. Then validate: ```sh rein setup check rein doctor --self-test ``` **Expected result:** initialization prints `initialized reinstate home (config.toml + state.json)`, a `profile_id=`, and a keyring credential reference. Both checks exit `0` when every installed-agent compatibility check also passes. The S3 bucket has no persistent manifest yet; the temporary probe was removed. ## 5\. Dry-run, push, and verify ciphertext storage Use a harmless test session and replace `AGENT` with `claude` or `codex`: ```sh rein list --agent AGENT rein push --agent AGENT --session SESSION_ID --dry-run rein push --agent AGENT --session SESSION_ID rein status ``` Enter the encryption passphrase through Reinstate’s hidden prompt. It is separate from the S3 secret access key and is not stored by Reinstate. Do not use `--all` unless you deliberately intend to sync every discovered session. **Expected result:** the preview reports `would push ... snapshot(s)` with `dry_run=true`. The mutating command reports `pushed ... snapshot(s)` with `dry_run=false`, and status reports a remote revision. In the S3 console, the exact generated prefix contains: ```text profiles//manifest.age profiles//snapshots/.age ``` There should be no plaintext transcript, auth file, `.env` file, access key, or passphrase object. A `.age` filename alone is not cryptographic proof; the committed [Phase 1 acceptance runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md) defines the controlled ciphertext inspection used for release qualification. This personal check does not claim physical Reinstate acceptance. ## Security boundaries - Reinstate encrypts the session locally before upload. Amazon S3 still sees the AWS account, bucket, object sizes, request timing, and encrypted object keys. - Amazon S3 applies default server-side encryption to new uploads. That provider-side layer is useful defense in depth but does not replace Reinstate’s client-side age encryption. See AWS’s [default encryption documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html). - Reinstate does not request provider-side encryption headers. A bucket default such as SSE-S3 applies normally; a policy that requires request-specific SSE-KMS headers can reject the probe or upload. A KMS-default bucket also needs the organization’s KMS permissions in addition to the example S3 policy. - Compromise of the bucket alone should not reveal transcript plaintext without the Reinstate passphrase, but an attacker with write or delete access can still remove, replace, or roll back ciphertext. Encryption is not availability protection. - Known auth files, OAuth material, credential stores, `.env` files, caches, and logs are excluded. A secret typed into a transcript is still transcript content and must be rotated if exposed. ## Failure modes and common errors ### Why does initialization report `storage probe put failed` (exit `4`)? **Likely cause:** Wrong endpoint, Region, bucket, credential, or missing `s3:PutObject`. **Safe next action:** Compare the bucket Region with both `--region` and the official regional endpoint; review the scoped policy. ### Why does initialization report `storage probe cleanup failed` (exit `4`)? **Likely cause:** Missing `s3:DeleteObject`, Object Lock, retention, or a deny policy blocked probe removal. **Safe next action:** Preserve the error, remove the stray probe through approved provider tooling, and fix delete access or retention before retrying. ### What causes `SignatureDoesNotMatch` or an authorization failure? **Likely cause:** Endpoint and signing Region differ, the key pair is wrong, or policy denies the request. **Safe next action:** Do not broaden to administrator access; correct the exact Region, endpoint, credential, and prefix policy. ### Why is `config missing` (exit `3`) after failed init? **Likely cause:** Reinstate intentionally did not save local config because the remote probe failed. **Safe next action:** Fix S3 first and rerun the same reviewed `rein init`. ### What should I do after compatibility exit `5` or `UNTESTED`? **Likely cause:** The installed coding-agent version or layout lacks release evidence. **Safe next action:** Stop transfer and check the [compatibility matrix](https://reinstate.dev/compatibility). ### Why does Reinstate report `no matching local sessions found` (exit `2`)? **Likely cause:** `AGENT` or `SESSION_ID` does not identify a discoverable local session. **Safe next action:** Run `rein list --agent claude` or `rein list --agent codex` and select one exact ID. ### Why is `remote profile manifest not found` on another device? **Likely cause:** Profile UUID, bucket, prefix, endpoint, or Region differs from the first device. **Safe next action:** Reuse every non-secret storage coordinate and the exact first-device `profile_id`; do not create an empty manifest. ### What should I do after conflict exit `6`? **Likely cause:** The local and remote copies diverged after sync. **Safe next action:** Preserve the conflict record and both histories; resolve explicitly instead of deleting S3 objects. ## Safe rollback and undo Reinstate does not provide a general `rein undo` or remote-session delete command. 1. A push `--dry-run` creates no session object, so it needs no rollback. 2. A failed storage probe does not save `config.toml` or `state.json`, although Reinstate may already have created its local home directories. 3. A successful first-device init has saved local configuration and the credential in the OS keyring, but its temporary S3 probe has been deleted. 4. If the configuration is wrong, stop before pushing. `rein init --force` backs up local config and state before replacement; it does not delete remote objects or revoke AWS credentials. 5. After a push, never delete only `manifest.age`. Stop every device, record the exact profile UUID, preserve needed backups, then remove the complete `profiles//` tree through approved S3 tooling only when its loss is acceptable. 6. Revoke or rotate the dedicated access key after cleanup. Deleting local Reinstate data does not revoke the IAM key or delete S3 objects. If S3 Versioning is enabled, an ordinary delete can leave noncurrent object versions and a delete marker. AWS documents the separate [version-aware deletion process](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html). Permanent deletion is irreversible. ## Verification checklist - [ ] The target is a private, general purpose S3 bucket in the intended Region; Block Public Access remains enabled and static website hosting is not in use. - [ ] The dedicated IAM principal is limited to `s3:ListBucket`, `s3:GetObject`, `s3:PutObject`, and `s3:DeleteObject` for the reviewed bucket and `profiles/` keyspace. - [ ] `rein setup check` and `rein doctor --self-test` complete without a compatibility, keyring, filesystem, or crypto failure. - [ ] The reviewed `rein push --agent AGENT --session SESSION_ID --dry-run` selects exactly one intended session and reports no mutation. - [ ] The real push succeeds, `rein status` reports the expected remote revision, and the bucket contains only age-encrypted `manifest.age` and `snapshots/*.age` objects beneath the generated profile prefix. - [ ] No command output, shell history, commit, log, or screenshot contains the access-key secret or passphrase, and no physical two-device acceptance is claimed until the relevant release scenario has passed. ## Current limitations - Reinstate accepts an access-key ID and secret access key, but not the session token required for AWS STS temporary credentials. - Reinstate does not create or delete S3 buckets, IAM identities, policies, KMS keys, lifecycle rules, versioning configuration, or Object Lock rules. - The example IAM policy assumes the default `profiles/` layout and a bucket whose default encryption does not require extra request headers. - Glacier or other archival lifecycle transitions can make a current snapshot unavailable to an ordinary pull. Reinstate does not coordinate provider lifecycle restoration. - Phase 1 transfers full immutable session snapshots; delta transfer, retention controls, and remote garbage collection remain later work. - Current native resume is same-vendor only. Stable physical verification is limited to Apple Silicon macOS and native Windows x64. ## Amazon S3 storage FAQ ### Does the S3 bucket need to be public? No. Keep Block Public Access enabled and ACLs disabled. Reinstate uses signed S3 API requests with the dedicated credential; it does not need a public URL, static website endpoint, CORS rule, or custom domain. ### Can Reinstate use AWS IAM Identity Center or an assumed role? Not directly in Reinstate. Temporary AWS credentials include a session token, while the current S3 backend accepts only an access-key ID and secret access key. This limitation is why the guide narrowly scopes and calls for rotation of any long-term evaluation key. ### Can I require SSE-KMS on the bucket? A bucket default can apply SSE-KMS, but the IAM principal also needs the relevant KMS permissions. Reinstate does not send request-specific SSE headers, so a bucket policy that requires such a header can reject initialization. Test with a harmless profile and follow your organization’s KMS policy. ### Can several Reinstate profiles share one S3 bucket? Yes. The default keyspace is `profiles//`, so profiles have separate object prefixes. A dedicated bucket is still simpler for least-privilege review and cleanup because a first-device profile UUID is generated during initialization. ### What happens if the bucket is compromised? An attacker who has only bucket contents should receive age-encrypted manifests and snapshots, not plaintext session data. An attacker with object permissions can still delete or replace ciphertext, observe metadata, and deny sync. Rotate exposed AWS credentials, preserve local copies, and follow the [security model](https://reinstate.dev/docs/security-model). ### How do I add the second computer? Finish one successful push first so `manifest.age` exists. On the second computer, run `rein init --profile-id DEVICE_A_PROFILE_UUID` with the same endpoint, Region, bucket, credential scope, passphrase, and canonical project ID but that computer’s own absolute path. Then follow the agent-specific Claude Code or Codex guide for the pull and native resume. CONTINUE READING ## Related Reinstate resources [Claude Code integration](https://reinstate.dev/integrations/claude-code) [Codex CLI integration](https://reinstate.dev/integrations/codex) [Cloudflare R2 storage guide](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage) [Getting started documentation](https://reinstate.dev/docs/getting-started) [Security model](https://reinstate.dev/docs/security-model) [Compatibility and tested versions](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-05. --- Integration · Claude Code · T5 # Sync Claude Code Sessions Across Devices | Reinstate > Reinstate encrypts and syncs supported Claude Code sessions across configured macOS and Windows project paths for native Claude Code resume. Claude Code is T5: encrypted same-vendor session sync plus T3 native resume. Reinstate remaps configured project paths and restores sessions to Claude Code’s native project layout. It does not convert Claude transcripts into another agent’s format. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Claude Code support at a glance - **Tier:** T5 Encrypted sync - **Session direction:** Claude Code → Claude Code - **Tested stable range:** `2.1.219`–`2.1.238` - **Primary platforms:** macOS and native Windows - **Remote storage:** Your S3-compatible or Cloudflare R2 bucket The tested range above is the current source policy. Stable v0.5.1 accepts Claude Code`2.1.219`–`2.1.238` after dual-platform tagged-artifact acceptance PASS on Apple Silicon macOS and native Windows x64. Intel macOS and WSL2 are optional and unverified. Versions outside the stated range are `UNTESTED` and writes are blocked. ## How Claude Code session sync works Claude Code groups local sessions under a directory key derived from the device's absolute project path. Copying that directory unchanged from Windows to macOS is insufficient because the same repository normally lives at a different absolute path. 1. During setup, map a stable project ID to the local project root on each device. 2. On push, Reinstate associates discovered Claude sessions with that canonical project ID and encrypts the portable artifact locally. 3. On pull, Reinstate resolves the destination device's project root and recomputes Claude Code's exact directory key for that path. 4. Reinstate verifies the restored session at the planned destination. A matching session ID elsewhere in Claude's project tree is not accepted as success. Why project mapping is first-class A repository might live at `C:\src\app` on Windows and`/Users/you/src/app` on macOS. Reinstate uses the shared project ID—not either machine's path—as portable identity. ## What Reinstate does and does not sync The adapter selects resumable Claude Code session artifacts. Reinstate excludes authentication files, OAuth or keychain material, tokens, caches, logs, and regenerable dependencies. Encrypted remote artifacts are stored in your bucket; the passphrase is not stored. A transcript can still contain a secret that a person or tool printed into the conversation. Encryption reduces cloud-storage exposure, but you remain responsible for keeping production secrets out of agent chats. Read the complete [security overview](https://reinstate.dev/security). ## Current limitations - Claude Code sessions can be resumed only by Claude Code in Phase 1. - Unmapped projects are excluded when canonical project mappings are configured. - Untested or unsupported Claude Code layouts fail closed for push and pull. - Credentials, MCP servers, skills, plugins, hooks, and agent settings are not synced. - WSL1 is unsupported; native Windows and WSL2 are separate Reinstate devices. - Reinstate does not protect data on an already-compromised local machine. ## Start with Claude Code Install the stable release, run `rein init`, and give the same project a stable ID on both devices. Use `rein push` on the source and a dry-run before`rein pull` on the destination. The step-by-step guide includes the exact commands and passphrase safety rules. ## Claude Code resources [Install Reinstate](https://reinstate.dev/docs/installation) [Complete Claude Code guide](https://reinstate.dev/guides/sync-claude-code-sessions-across-devices) [Claude Code troubleshooting](https://reinstate.dev/docs/troubleshooting#why-does-claude---resume-not-see-a-pulled-session) [macOS and Windows workflow](https://reinstate.dev/use-cases/macos-and-windows) [Exact compatibility states](https://reinstate.dev/compatibility) [Adapter internals](https://reinstate.dev/docs/adapters) [Compare with manual copying](https://reinstate.dev/compare/reinstate-vs-manual-session-copying) [Release changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/integrations/claude-code Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Cline · T1 # Cline as a T1 Discover Agent | Reinstate > Cline is T1: Reinstate can list, search, and inspect local sessions. Native resume, handoff, and encrypted sync are not supported. Cline is T1: a read-only local index. Reinstate does not launch Cline as a native resume target, does not use it as a handoff source or destination, and does not sync Cline sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Cline support at a glance - **Tier:** T1 Discover - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T1 means `rein sessions --agent cline`, search, and inspect work against local Cline sessions. Resume and fork stay refused. ## What T1 includes - Read-only discovery, search, and inspect of local `sessions/*/*.json` metadata. - Fail-closed behavior on an unrecognized session JSON shape. - `*.messages.json` and `db/sessions.db` are not parsed. ## What T1 excludes - No `rein resume` / `rein fork` of a Cline session. - No structured handoff from or to Cline. - No `rein push` / `rein pull` of Cline sessions. - No write into Cline’s session store. Native resume is same-vendor, and Cline is not a T3 agent. ## Evidence Dual-platform probes live under `docs/testing/results/agent-probes`. Fixtures live under `testdata/sessionindex/cline`. There is no T3 device report. See the[Cline storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cline.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/cline Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · OpenAI Codex CLI · T5 # Sync Codex CLI Sessions Across Devices | Reinstate > Reinstate encrypts and syncs supported OpenAI Codex CLI sessions across configured macOS and Windows project paths for native Codex resume. Codex CLI is T5: encrypted same-vendor session sync plus T3 native resume. Reinstate rewrites the structural working directory for the destination project and preserves Codex’s native date-partitioned rollout layout. Codex-to-Codex only. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Codex CLI support at a glance - **Tier:** T5 Encrypted sync - **Session direction:** Codex CLI → Codex CLI - **Tested stable range:** `0.133.0`–`0.149.0` - **Primary platforms:** macOS and native Windows - **Remote storage:** Your S3-compatible or Cloudflare R2 bucket Stable v0.5.1 accepts Codex CLI `0.133.0`–`0.149.0`; the ceiling moved to `0.149.0` on dual-platform physical resume evidence. Dual-platform tagged-artifact acceptance PASS covers Apple Silicon macOS and native Windows x64. Intel macOS and WSL2 are optional and unverified. A version outside the range is `UNTESTED`; Reinstate permits read-only discovery but refuses export and restore. ## How Codex session sync works Codex stores the source working directory in each rollout's structural`session_meta.cwd`. That path identifies the local checkout, so it cannot be copied literally when the destination machine uses a different root. 1. Configure a canonical project ID and the actual local project root on each device. 2. During discovery, Reinstate resolves `session_meta.cwd` to that project ID and excludes rollouts outside mapped roots. 3. Export replaces the resolved source root with a portable`$${REPO:}` token, then encrypts the artifact locally. 4. Restore expands the token through the destination device's project mapping while preserving Codex's native date-partitioned rollout structure. Structural paths are portable; transcript prose is not rewritten. Reinstate changes known path fields needed for native resume. It deliberately leaves free-form prompts, responses, and unknown fields alone rather than modifying the meaning of the conversation. ## Security boundary Reinstate reads local Codex session files and does not call OpenAI APIs or require OpenAI account credentials. Authentication files, API keys, OAuth tokens, credential stores, caches, and regenerable dependencies are excluded from sync. Storage credentials stay in the operating system keyring. Session content is encrypted locally with age passphrase encryption before upload. Because a transcript may contain sensitive text produced during a coding task, read the[security model and threat boundaries](https://reinstate.dev/security) before using real sessions. ## Current limitations - Codex rollouts can be resumed only by Codex in Phase 1. - Rollouts outside configured canonical project roots are not exported. - Untested or unsupported Codex versions cannot be pushed or pulled. - Credentials, MCP servers, skills, plugins, hooks, and agent settings are not synced. - WSL1 is unsupported; native Windows and WSL2 are separate Reinstate devices. - Reinstate is independent of OpenAI and is not an official Codex product. ## Start with Codex Install the stable release and configure the same canonical project ID on each machine. Push the selected session on the source, inspect`rein pull --agent codex --session SESSION_ID --dry-run` on the destination, then restore that scoped session and use Codex's native resume command. ## Codex resources [Install Reinstate](https://reinstate.dev/docs/installation) [Complete Codex guide](https://reinstate.dev/guides/sync-codex-sessions-across-devices) [Codex troubleshooting](https://reinstate.dev/docs/troubleshooting#why-is-a-large-codex-session-slow-to-sync) [macOS and Windows workflow](https://reinstate.dev/use-cases/macos-and-windows) [Exact compatibility states](https://reinstate.dev/compatibility) [Adapter internals](https://reinstate.dev/docs/adapters) [Compare with manual copying](https://reinstate.dev/compare/reinstate-vs-manual-session-copying) [Release changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/integrations/codex Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · GitHub Copilot CLI · T1 # GitHub Copilot CLI as a T1 Discover Agent | Reinstate > GitHub Copilot CLI is T1: Reinstate can list, search, and inspect local sessions. Native resume, handoff, and encrypted sync are not supported. GitHub Copilot CLI is T1: a read-only local index. Reinstate does not launch Copilot as a native resume target, does not use it as a handoff source or destination, and does not sync Copilot sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## GitHub Copilot CLI support at a glance - **Tier:** T1 Discover - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T1 means `rein sessions --agent copilot`, search, and inspect work against local GitHub Copilot CLI sessions. Resume and fork stay refused. ## What T1 includes - Read-only discovery, search, and inspect of local `session-state/*/events.jsonl` logs. - Fail-closed behavior on an unrecognized first-record shape. - SQLite sidecars (`session.db`, `session-store.db`) are not parsed. ## What T1 excludes - No `rein resume` / `rein fork` of a Copilot session. - No structured handoff from or to GitHub Copilot CLI. - No `rein push` / `rein pull` of Copilot sessions. - No write into Copilot’s session store. - Not the retired `gh copilot` extension, and not editor Copilot chat. Native resume is same-vendor, and GitHub Copilot CLI is not a T3 agent. ## Evidence Dual-platform probes live under `docs/testing/results/agent-probes`. Fixtures live under `testdata/sessionindex/copilot`. There is no T3 device report. See the[Copilot storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/copilot.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/copilot Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Cursor CLI · T1 # Cursor CLI as a T1 Discover Agent | Reinstate > Cursor CLI is T1: Reinstate can list, search, and inspect local sessions. Native resume, handoff, and encrypted sync are not supported. Cursor CLI is T1: a read-only local index of terminal-agent chats. Reinstate does not launch Cursor as a native resume target, does not use it as a handoff source or destination, and does not sync Cursor sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Cursor CLI support at a glance - **Tier:** T1 Discover - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T1 means `rein sessions --agent cursor`, search, and inspect work against local Cursor CLI sessions. Resume and fork stay refused. The in-editor Cursor agent is a different product and is not this key. ## What T1 includes - Read-only discovery, search, and inspect of local Cursor CLI `meta.json` chats. - Fail-closed behavior on an unrecognized `meta.json` shape. - Editor `projects/` trees are not indexed. ## What T1 excludes - No `rein resume` / `rein fork` of a Cursor session. - No structured handoff from or to Cursor CLI. - No `rein push` / `rein pull` of Cursor sessions. - No write into Cursor’s session store. - No indexing of the in-editor agent under `~/.cursor/projects`. Native resume is same-vendor, and Cursor CLI is not a T3 agent. ## Evidence Dual-platform probes live under `docs/testing/results/agent-probes`. Fixtures live under `testdata/sessionindex/cursor`. There is no T3 version probe and no T3 device report. See the[Cursor storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/cursor.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/cursor Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Gemini CLI · T2 # Gemini CLI as a T2 Handoff Source | Reinstate > Gemini CLI is a T2 handoff source: Reinstate can read local sessions and build a portable capsule. Native resume and encrypted sync are not supported. Gemini CLI is T2: a handoff source and a read-only local index. Reinstate does not launch Gemini, does not write Gemini session files, and does not sync Gemini sessions. T-050 left Gemini at T2. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Gemini CLI support at a glance - **Tier:** T2 Handoff source - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T2 means `rein handoff --from gemini` can build a portable capsule from a local Gemini CLI thread. T3 verified resume needs a fail-closed version range and dual-platform physical resume journeys. Those are not committed, so Gemini stays T2. ## What T2 includes - T1 read-only discovery, search, and inspect of local Gemini CLI sessions. - T2 structured handoff from Gemini CLI into a new Claude Code or Codex session. - Fail-closed behavior on an unrecognized layout (exit code `5`). ## What T2 excludes - No `rein resume` / `rein fork` of a Gemini session. - No `rein handoff --to gemini` destination. - No `rein push` / `rein pull` of Gemini sessions. - No write into Gemini’s session store. Native resume is same-vendor, and Gemini is not a T3 agent. A handoff starts a *new* Claude Code or Codex session. It does not reconstruct Gemini history or translate the vendor transcript. ## Evidence Committed fixtures live under `testdata/sessionindex/gemini` and`testdata/handoff/gemini`. A Windows physical path exists; there is no dual-platform T3 resume report. See the[Gemini storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Structured handoff](https://reinstate.dev/docs/handoff) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/gemini Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Grok Build · T4 # Grok Build as a T4 Handoff Destination | Reinstate > Grok Build is T4: Reinstate reads local sessions, hands off from and into Grok, and launches grok --resume against the vendor session. Encrypted sync is not supported. Grok Build is T4: a read-only local index, a handoff source, a handoff destination, and same-vendor native resume through the vendor's own CLI. A handoff into Grok starts a new session and is never a cross-agent resume. Reinstate does not sync Grok sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Grok Build support at a glance - **Tier:** T4 Handoff destination - **Storage family:** F1 home tree - **Verified version range:** 1.0.5 – 1.0.13 - **Encrypted sync (T5):** Not supported T4 means `rein handoff --to grok` starts a *new* Grok session with `grok --session-id `, on top of the T3`rein resume grok:` and the T2`rein handoff --from grok`. Grok Build is not a T5 sync agent. ## What T4 includes - T1 read-only discovery, search, and inspect of local Grok Build sessions. - T2 structured handoff from Grok Build into a new Claude Code or Codex session. - T3 same-vendor `rein resume` and `rein fork`, the latter through`grok --resume --fork-session`. - T4 structured handoff *into* Grok Build. That starts a new session and is never a cross-agent resume: Reinstate does not reconstruct source history in Grok. - A bounded `grok --version` probe with a fail-closed range of 1.0.5 – 1.0.13. - Fail-closed behavior on an unrecognized layout or version (exit code `5`). ## What T4 excludes - No `rein push` / `rein pull` of Grok sessions. - No write into Grok's session store. - No resume of a session whose recorded id is not a UUID. `grok --resume` also accepts a session *title*, and titles are neither unique nor stable, so such a session stays read-only rather than being addressed by name. Native resume is same-vendor: it launches Grok's own CLI against Grok's own session. A handoff starts a *new* destination session in either direction. It does not reconstruct vendor history or translate a transcript between vendors. Grok Build has documented repository-content upload behaviour, so a handoff from or into it always runs capsule redaction, always prints that warning, and refuses`--no-redact` with exit `2`. ## Evidence Committed fixtures live under `testdata/sessionindex/grok` and`testdata/handoff/grok`, and the version range was measured from the real binary. The resume journeys T3 rests on and the destination journey T4 rests on are both recorded, on macOS and on native Windows. See the[Grok storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Structured handoff](https://reinstate.dev/docs/handoff) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/grok Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Kimi Code CLI · T2 # Kimi Code CLI as a T2 Handoff Source | Reinstate > Kimi Code CLI is a T2 handoff source: Reinstate can read local sessions and build a portable capsule. Native resume and encrypted sync are not supported. Kimi Code CLI is T2: a handoff source and a read-only local index. Reinstate does not launch Kimi as a native resume target and does not sync Kimi sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Kimi Code CLI support at a glance - **Tier:** T2 Handoff source - **Release:** Merged, not yet a stable claim (stable `v0.5.1` predates this tier) - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T2 means `rein handoff --from kimi` can build a portable capsule. Kimi Code CLI is not a T3 resume agent and not a T5 sync agent. ## What T2 includes - T1 read-only discovery, search, and inspect of local Kimi Code CLI sessions. - T2 structured handoff from Kimi Code CLI into a new Claude Code or Codex session. - Fail-closed behavior on an unrecognized layout (exit code `5`). - Unknown `wire.jsonl` records stay referenced, with no payload body. ## What T2 excludes - No `rein resume` / `rein fork` of a Kimi session. - No `rein handoff --to kimi` destination. - No `rein push` / `rein pull` of Kimi sessions. - No write into Kimi’s session store. Native resume is same-vendor, and Kimi Code CLI is not a T3 agent. A handoff starts a *new* Claude Code or Codex session. It does not reconstruct Kimi history or translate the vendor transcript. Kimi's T2 handoff source is merged and ships in the current tree, but it has not reached a certified stable release: stable remains `v0.5.1`, where Kimi Code CLI predates this tier. See the [release boundary](https://reinstate.dev/roadmap) and the[changelog](https://reinstate.dev/changelog). ## Evidence Dual-platform probes live under `docs/testing/results/agent-probes`. Fixtures live under `testdata/sessionindex/kimi` and`testdata/handoff/kimi`. There is no T3 version probe and no T3 device report. See the[Kimi storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/kimi.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Structured handoff](https://reinstate.dev/docs/handoff) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/kimi Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · OpenCode · T5 (v0.6.0-rc.6 candidate) # Sync OpenCode Sessions Across Devices | Reinstate > Reinstate encrypts and syncs OpenCode sessions across devices, natively resumes and forks them, and hands off into or out of OpenCode as a structured checkpoint. OpenCode reaches T5 in the v0.6.0-rc.6 release candidate: encrypted same-vendor session sync, on top of T3 native resume and fork, T4 structured handoff destination, and T2 handoff source. This is not yet a stable claim; stable remains v0.5.1, where OpenCode is T2 only. Reinstate extracts a portable document from OpenCode's embedded SQLite store and reassembles it in the destination's own store. OpenCode-to-OpenCode sync only. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## OpenCode support at a glance - **Tier:** T5 Encrypted sync - **Release:** `v0.6.0-rc.6` candidate (stable remains `v0.5.1`) - **Session direction:** OpenCode → OpenCode - **Storage family:** F3 embedded SQLite session store - **Tested version:** `1.18.21`–`1.18.29` - **Remote storage:** Your S3-compatible or Cloudflare R2 bucket OpenCode is the first embedded-SQLite agent to reach encrypted sync, alongside Claude Code and Codex CLI. T5 sits on top of the lower tiers: T1 read-only local discovery, T2`rein handoff --from opencode`, T3 `rein resume` / `rein fork`, and T4 `rein handoff --to opencode`. A version outside the tested range is`UNTESTED`; Reinstate permits read-only discovery but refuses export, restore, and launch. T5 is new in the `v0.6.0-rc.6` candidate, not yet a stable claim. OpenCode's T5 encrypted sync, T4 handoff destination, and T3 native resume and fork all ship with the `v0.6.0-rc.6` release candidate. Stable remains`v0.5.1`, where OpenCode is T2 only, until a native Windows tagged-artifact run promotes this candidate. See the [release boundary](https://reinstate.dev/roadmap) and the[changelog](https://reinstate.dev/changelog). ## How OpenCode session sync works OpenCode keeps every session in one embedded SQLite database rather than one file per session, so the synced unit is a portable, deterministic JSON document extracted from the`session`, `project`, `message`, and `part`tables, with every absolute path normalized to a `$${HOME}` /`$${REPO:}` token. The `credential`, `account`,`control_account`, and `account_state` tables are never opened. 1. Export reads the session's rows through the embedded store, tokenizes every known path, and writes a single portable document as one tar entry. 2. Restore writes that document back into the destination's own `opencode.db`through a checkpointed working copy, fingerprint-guarded and backed up, then an atomic rename so a concurrent vendor write cannot corrupt the store. 3. Native resume and fork call OpenCode's own continuation flags —`opencode --session ` and `opencode --session --fork`— against the restored session, since OpenCode has no separate `resume` or`fork` verb. 4. A handoff into or out of OpenCode starts a *new* session through a bounded bootstrap and a private, inspectable projection; it is never a cross-agent resume. Structural paths are portable; transcript prose is not rewritten. Reinstate changes known path fields needed for native resume and leaves free-form prompts, responses, and unknown fields alone. A session row OpenCode recorded without a working directory stays read-only, because OpenCode is always launched into a directory. ## Security boundary Reinstate reads the local OpenCode store and does not call a hosted OpenCode API or require OpenCode account credentials. The `credential`, `account`,`control_account`, and `account_state` tables are excluded from every export, and a round-trip test fails if a credential value appears in one. Storage credentials stay in the operating system keyring. Session content is encrypted locally before upload. Because a transcript may contain sensitive text produced during a coding task, read the[security model and threat boundaries](https://reinstate.dev/security) before syncing real sessions. ## Current limitations - OpenCode assigns its own session id; a handoff into OpenCode reconciles that id after launch rather than pinning it, and is never a cross-agent resume. - Close OpenCode before pulling into a live store; a write in the residual window between the pre-rename fingerprint check and the rename is not detected. - A version outside the tested range cannot be pushed, pulled, or launched. - Credentials, MCP servers, skills, plugins, hooks, and agent settings are not synced. - Reinstate is independent of the OpenCode maintainers and is not an official OpenCode product. ## Evidence Committed fixtures live under `testdata/adapters/opencode`,`testdata/sessionindex/opencode`, and `testdata/handoff/opencode`. Per [ADR 0005](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/adr/0005-v0.6.0-scope-and-windows-first-acceptance.md), this `v0.6.0-rc.6` candidate's tagged-artifact acceptance for OpenCode's new T5 tier is native Windows x64 only; Apple Silicon macOS is deferred until that hardware returns, and no document here claims macOS verification for this candidate. See the[OpenCode storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md), the [compatibility record](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/compatibility.md), and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Structured handoff](https://reinstate.dev/docs/handoff) [Adapter documentation](https://reinstate.dev/docs/adapters) [Release changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/integrations/opencode Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Pi · T1 # Pi as a T1 Discover Agent | Reinstate > Pi is T1: Reinstate can list, search, and inspect local sessions. Native resume, handoff, and encrypted sync are not supported. Pi is T1: a read-only local index. Reinstate does not launch Pi as a native resume target, does not use it as a handoff source or destination, and does not sync Pi sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Pi support at a glance - **Tier:** T1 Discover - **Storage family:** F1 home tree - **Native resume (T3):** Not supported - **Encrypted sync (T5):** Not supported T1 means `rein sessions --agent pi`, search, and inspect work against local Pi sessions. Resume and fork stay refused. ## What T1 includes - Read-only discovery, search, and inspect of local Pi sessions. - Fail-closed behavior on an unrecognized JSONL first-record shape. - Fail-closed version pin `0.73.1` (identity, not a resume claim). ## What T1 excludes - No `rein resume` / `rein fork` of a Pi session. - No structured handoff from or to Pi. - No `rein push` / `rein pull` of Pi sessions. - No write into Pi’s session store. Native resume is same-vendor, and Pi is not a T3 agent. ## Evidence Dual-platform probes live under `docs/testing/results/agent-probes`. Fixtures live under `testdata/sessionindex/pi`. There is no T3 device report. See the[Pi storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/pi Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Integration · Qwen Code · T4 # Qwen Code as a T4 Handoff Destination | Reinstate > Qwen Code is T4: Reinstate reads local sessions, hands off from and into Qwen, and launches qwen --resume against the vendor session. Encrypted sync is not supported. Qwen Code is T4: a read-only local index, a handoff source, a handoff destination, and same-vendor native resume through the vendor's own CLI. A handoff into Qwen starts a new session and is never a cross-agent resume. Reinstate does not sync Qwen sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Qwen Code support at a glance - **Tier:** T4 Handoff destination - **Storage family:** F1 home tree - **Verified version range:** 0.21.12 – 0.23.0 - **Encrypted sync (T5):** Not supported T4 means `rein handoff --to qwen` starts a *new* Qwen Code session with `qwen --session-id `, on top of the T3`rein resume qwen:` (`qwen --resume `) and the T2`rein handoff --from qwen`. Qwen Code is not a T5 sync agent. ## What T4 includes - T1 read-only discovery, search, and inspect of local Qwen Code sessions. - T2 structured handoff from Qwen Code into a new Claude Code or Codex session. - T3 same-vendor `rein resume` (`qwen --resume `) and`rein fork` (`qwen --resume --fork-session`). - T4 structured handoff *into* Qwen Code via `qwen --session-id `. That starts a new session and is never a cross-agent resume: Reinstate does not reconstruct source history in Qwen. - A bounded `qwen --version` probe with a fail-closed range of 0.21.12 – 0.23.0. - Fail-closed behavior on an unrecognized layout or version (exit code `5`). ## What T4 excludes - No `rein push` / `rein pull` of Qwen sessions. - No write into Qwen Code's session store. - No resume of an id Qwen does not recognize: an unknown `--resume` id exits`1` with the vendor's own "No saved session found" message rather than opening a picker. Native resume is same-vendor: it launches Qwen's own CLI (`qwen --resume`) against Qwen's own session. A handoff starts a *new* destination session in either direction. It does not reconstruct vendor history or translate a transcript between vendors. Qwen Code ships a managed self-updater, so one machine can answer `--version`differently depending on which install root is in scope; the verified range spans the bundled and the self-updated build observed on this host. A newer self-update outside that range reports `UNTESTED` rather than being assumed compatible. ## Evidence Committed fixtures live under `testdata/sessionindex/qwen` and`testdata/handoff/qwen`, and the version range was measured from the real binary. The resume journeys T3 rests on and the destination journey T4 rests on are both recorded, on macOS and on native Windows (2026-08-22). See the[Qwen storage page](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md)and the [tier matrix](https://reinstate.dev/compatibility). ## Related [All integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Structured handoff](https://reinstate.dev/docs/handoff) [Adapter documentation](https://reinstate.dev/docs/adapters) --- Source: https://reinstate.dev/integrations/qwen Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Open source # Reinstate Is Open Source Under Apache-2.0 > Review, use, and contribute to Reinstate, an Apache-2.0 Go project for encrypted coding-agent session continuity with user-owned storage. Reinstate is fully open source under the Apache License 2.0. Its Go source, tests, security model, release automation, roadmap, and issue tracker are public, so developers can inspect the continuity layer that handles their sensitive coding-agent sessions. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Project facts - **License:** [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0) - **Language:** Go - **Repository:** [GitHub](https://github.com/HarjjotSinghh/reinstate) - **CLI:** `rein` or `reinstate` - **Maintainer:** [Harjot Singh Rana](https://harjot.co/) - **Contribution status:** Issues and pull requests welcome ## Why a continuity layer should be inspectable Coding-agent transcripts can contain source code, design decisions, internal paths, and sensitive terminal output. Reinstate sits between those local files and remote object storage. Publishing the implementation lets users verify what adapters select, which paths are excluded, where encryption happens, and how restores avoid overwriting local history. Open source makes independent review possible; it does not prove the absence of vulnerabilities. Reinstate has not claimed a formal third-party audit, so use the documented threat model and your own risk assessment for sensitive work. ## Where to inspect the implementation | Repository area | Responsibility | | --- | --- | | `cmd/reinstate` | CLI entry point | | `internal/adapter` | Claude Code and Codex local session discovery and restore adapters | | `internal/crypto` | age encryption and secret-input handling | | `internal/pathmap` | Portable Windows ↔ macOS structural path rewriting | | `internal/sync` | Push, pull, manifests, artifacts, and conflicts | | `testdata` | Deterministic synthetic fixtures rather than real transcripts | | `docs` | Architecture, security, compatibility, product boundaries, and runbooks | ## Build and test locally The project targets Go 1.25.12 or newer. Clone the repository, then use the maintained Make targets: - `make build` creates `bin/reinstate` and the short `rein` alias. - `make test` runs the test suite. - `make vet` runs Go's static checks. - `make verify` runs the broader local verification gate. Unit tests do not depend on live networks without fakes, and committed session fixtures must remain deterministic, synthetic, and secret-scanned. ## How to contribute 1. Read the roadmap and product strategy so a proposal fits the continuity-layer boundary. 2. Open or join an issue before a large change; small, reviewable pull requests are preferred. 3. Add table-driven tests for Go behavior and avoid live network dependencies in unit tests. 4. Update user documentation and the unreleased changelog when a change affects the CLI or web experience. 5. Never commit real transcripts, API keys, passphrases, session credentials, or private compatibility evidence. Start with the repository's[contribution guide](https://github.com/HarjjotSinghh/reinstate/blob/main/CONTRIBUTING.md) and [open issues](https://github.com/HarjjotSinghh/reinstate/issues). ## What Apache-2.0 means here Apache-2.0 permits use, modification, and distribution under its conditions and includes an express patent-license grant. The repository's[LICENSE](https://github.com/HarjjotSinghh/reinstate/blob/main/LICENSE) file is the authoritative legal text; this page is a project overview, not legal advice. ## Project resources [Source repository](https://github.com/HarjjotSinghh/reinstate) [About Reinstate](https://reinstate.dev/about/reinstate) [Product roadmap](https://reinstate.dev/roadmap) [Research and evidence](https://reinstate.dev/research) [Encrypted snapshot format v1](https://reinstate.dev/research/encrypted-snapshot-format-v1) [Terminology glossary](https://reinstate.dev/glossary) [Security overview](https://reinstate.dev/security) [Changelog](https://reinstate.dev/changelog) --- Source: https://reinstate.dev/open-source Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Privacy # Reinstate website privacy notice > How the Reinstate website handles waitlist email addresses, optional analytics, server logs, and privacy requests. Reinstate does not receive coding-agent sessions, source code, storage credentials, or encryption passphrases through this website. The site collects an email address only when someone submits the waitlist form, and analytics loads only when the operator explicitly configures it. Last updated: July 27, 2026 ## What this notice covers This notice covers visits to [reinstate.dev](https://reinstate.dev/) and information submitted through its waitlist. It does not change the local-first data flow of the Reinstate CLI. The CLI encrypts supported session data on the developer's device and sends ciphertext to storage that the developer configures and controls. ## Waitlist information If you join the waitlist, the site processes the email address you provide, a submission timestamp, and the source label `web`. The information is used to manage early access and send relevant project or release updates. It is not sold. Depending on the production configuration, waitlist records are stored in a managed libSQL/Turso database or a private GitHub Gist. The site may use Resend to notify the maintainer of a new signup. These services process information under their own terms and privacy practices. ## Optional site analytics No analytics script is emitted unless a Plausible script URL is configured at build time. When enabled, the site can record page views and events from a fixed, reviewed taxonomy: command copies, getting-started entry, integration and storage-guide views, security-document views, repository and release-download clicks, RSS subscriptions, issue-report and contribution links, and successful waitlist submissions. Plausible's automatic capture of outbound links and file downloads is deliberately left off, because it would transmit destination addresses as event properties. Clicks that leave the site are instead reported through the reviewed taxonomy above, as a controlled event name and a controlled label, without the address. Event properties contain only a controlled event name, the current path without its query string, a controlled placement label, and—when they can be resolved—a controlled referral channel label and a controlled campaign identifier. Reinstate's event code does not send form values, email addresses, coding-agent content, source code, repository names, bucket names, credentials, passphrases, or link query parameters. The deployed Plausible service can still process ordinary request information according to its configuration and privacy policy. The referral channel label is chosen from a fixed, reviewed list and describes where a visit came from, not who made it. Two independent lists are used: AI answer engines (ChatGPT, Perplexity, Microsoft Copilot, Google Gemini, and Google AI features) and marketing channels (X, LinkedIn, Dev.to, Hacker News, GitHub, newsletters, and paid placements on X or Meta). A referrer that matches neither list produces no label at all. The campaign identifier exists so that a marketing test can tell its own variants apart. It is not read through from the address bar: an incoming `utm_content` value is compared against a fixed allowlist of campaign identifiers held in the site's source code, and only an exact match is recorded. Any other value is discarded and nothing is transmitted. Adding a campaign identifier requires a reviewed change to that list. ## Infrastructure logs Hosting, content-delivery, security, and email providers may create routine operational logs when they serve a request or prevent abuse. Those records can include request time, requested URL, user agent, IP-derived network information, response status, and diagnostic data. They are used for availability, security, and troubleshooting—not to inspect coding-agent work. ## Retention and deletion Waitlist records are kept while they are needed for early-access and project communications, legal obligations, or abuse prevention. Operational-log retention is controlled by the configured providers. You may ask to access, correct, or delete a waitlist record by contacting the maintainer privately at the email address in the project's [security policy](https://github.com/HarjjotSinghh/reinstate/security/policy) from the address concerned. ## Verify the implementation The website and CLI are open source. You can inspect the[website implementation](https://github.com/HarjjotSinghh/reinstate/tree/main/website), review the [security overview](https://reinstate.dev/security), and report a vulnerability through the project's [security policy](https://github.com/HarjjotSinghh/reinstate/security/policy). ## Changes to this notice Material changes will update the date above and the public repository history. Analytics or data-processing configuration should not be enabled in production without reviewing this notice for accuracy. --- Source: https://reinstate.dev/privacy Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Primary-source evidence # Reinstate Research and Compatibility Evidence > Inspect Reinstate adapter tests, compatibility data, acceptance methodology, security architecture, synthetic fixtures, and the evidence required before benchmark claims. Reinstate publishes source, deterministic synthetic tests, compatibility records, architecture, acceptance methodology, and sanitized physical reports so current claims can be checked. It does not yet publish restoration benchmarks; those require reproducible cross-platform measurements. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Evidence levels | Level | What it can support | What it cannot support alone | | --- | --- | --- | | Released code and unit tests | Implemented contracts, parsing, exclusions, transformations, and failure behavior | Real-device compatibility or production reliability | | Deterministic synthetic fixtures | Repeatable adapter, path-mapping, encryption, and restore regression checks | Distribution claims about private user sessions | | Physical acceptance result | The exact recorded release, agent versions, devices, directions, and criteria | Every untested version, platform, device, or workload | | Production field data | The measured population and date window when methodology and denominators are shown | Universal guarantees or causes not isolated by the data | ## Current evidence assets - **Compatibility data:** [Machine-readable JSON](https://reinstate.dev/compatibility.json), reviewed 2026-09-07 - **Fixture commit:** [`cf6e430f3aa7`](https://github.com/HarjjotSinghh/reinstate/commit/cf6e430f3aa73ab55d1c54ef30ffe832c76f689a) - **Acceptance methodology:** [Reinstate MacBook + Windows runbook](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md) - **Architecture and security:** [Architecture](https://reinstate.dev/docs/architecture) and [security model](https://reinstate.dev/docs/security-model) - **Encrypted format specification:** [Manifest and snapshot format v1](https://reinstate.dev/research/encrypted-snapshot-format-v1), including framing, validation, and pre-1.0 limits - **Synthetic path explainer:** [macOS ↔ Windows path-mapping visualizer](https://reinstate.dev/tools/path-mapping-visualizer)with fixed non-private fixtures ## Adapter and compatibility evidence The compatibility matrix links each supported agent range to the exact adapter test source. Versions outside the inclusive stable ranges—including prereleases—are treated as`UNTESTED` and mutating operations fail closed. The matrix separately marks open physical platform gates instead of borrowing a source-test date as platform certification. - **Claude Code:** `2.1.219`–`2.1.263`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md); source checks, deterministic synthetic fixtures, and dual-platform tagged-artifact acceptance. - **OpenAI Codex CLI:** `0.133.0`–`0.149.0`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/results/2026-08-15-macos-phase4-V040RC11.md); source checks, deterministic synthetic fixtures, and dual-platform tagged-artifact acceptance. - **Gemini CLI:** `0.55.1`–`0.55.1`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/gemini.md); read-only fixtures and a Windows physical path; no dual-platform T3 resume journeys. - **OpenCode:** `1.18.21`–`1.18.29`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/opencode.md); T3 resume and T4 destination device journeys recorded on macOS and native Windows (2026-08-22); T5 encrypted-sync journeys recorded on macOS and native Windows (2026-08-23); v0.6.0 tagged-artifact acceptance pending on native Windows and deferred on macOS. - **Grok Build:** `1.0.5`–`1.0.13`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/grok.md); deterministic synthetic fixtures, a measured grok --version range, and T3 resume and T4 destination device journeys recorded on macOS and native Windows (2026-08-22 and 2026-08-23); GD8 collected on macOS only; native Windows range-widening read-only evidence (2026-09-08), completed-turn evidence deferred to the v0.6.0-rc.6 tagged run. - **Pi:** `0.73.1`–`0.73.1`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/pi.md); dual-platform AGENT-PROBE-V1; F1 index source; no T3 device journey. - **Qwen Code:** `0.21.12`–`0.23.0`; [test source](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/session-storage/qwen.md); dual-platform AGENT-PROBE-V1; F1 index source; T2 reader; dual-platform T3 device journey; T4 destination journey; native Windows range-widening evidence. ## Physical results and current limitation The repository contains dated RC5 macOS and Windows observations. They are useful historical evidence, but they do not close the Reinstate acceptance matrix. The current Reinstate runbook requires both agents, both directions, checksum-verifying installers, wrong-passphrase refusal, ciphertext-only remote objects, conflict handling, restore backups, and redacted evidence. Review the[raw acceptance-result directory](https://github.com/HarjjotSinghh/reinstate/tree/main/docs/testing/results) and the [qualified public compatibility summary](https://reinstate.dev/compatibility). Do not infer a stable support claim from an older passing row. ## Why the fixtures are synthetic Real coding-agent sessions can contain proprietary source code, prompts, internal paths, terminal output, or credentials. Committed fixtures are deterministic and synthetic, and the repository's secret checks protect against accidentally turning a compatibility test into a data leak. Public evidence uses versions, exit codes, counts, snapshot identifiers, and redacted paths rather than transcript text. ## Benchmark publication contract Before publishing a speed, success-rate, or session-size result, Reinstate must disclose: - the question and success criteria; - hardware, operating systems, agent versions, Reinstate version, and commit; - the synthetic dataset or safely consented data source; - exact commands, repetitions, warm-up and cache policy, and raw output; - every failure, exclusion, limitation, and denominator; and - a stable canonical page, methodology date, and downloadable evidence. No benchmark claim yet This page deliberately reports no restoration speed, success rate, market coverage, or user distribution. A blank metric is more accurate than a number without a reproducible method. ## Inspect the evidence [Compatibility matrix](https://reinstate.dev/compatibility) [Agent-version history](https://reinstate.dev/compatibility/agent-version-history) [Encrypted snapshot format v1](https://reinstate.dev/research/encrypted-snapshot-format-v1) [Path-mapping visualizer](https://reinstate.dev/tools/path-mapping-visualizer) [Terminology glossary](https://reinstate.dev/glossary) [Architecture](https://reinstate.dev/docs/architecture) [Security model](https://reinstate.dev/docs/security-model) [Source and test map](https://reinstate.dev/open-source) --- Source: https://reinstate.dev/research Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Implementation specification · v1 # Reinstate Encrypted Session Snapshot Format v1 > Read the current Reinstate manifest and encrypted session snapshot v1 contract: object keys, metadata fields, TAR payload, age encryption, validation, and limits. Reinstate v0.1.0 stores an age-encrypted JSON manifest and immutable age-encrypted session snapshots. Snapshot plaintext is one compact JSON metadata line, a newline, and one adapter-generated TAR stream whose byte length and SHA-256 digest are authenticated before restore. This is Reinstate’s current internal pre-1.0 format, not an open portability standard. - **Published:** July 27, 2026 - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Specification status and scope - **Envelope schema:** `1` - **Manifest schema:** `1` - **Snapshot kind:** `reinstate-session-snapshot` - **Release described:** `v0.1.0` This page documents the released implementation so reviewers can reason about stored objects and migration risk. It does not freeze the format, promise backward compatibility through v1.0, grant compatibility to another implementation, or claim approval by a standards body. Keep independent backups and read release notes before upgrading pre-1.0 data. ## Remote object layout Objects live below the configured profile storage prefix. New setup normally uses`profiles/`; the prefix remains configuration, so consumers must not infer profile identity from an arbitrary bucket path. ``` profiles// ├── manifest.age └── snapshots/ └── .age ``` - `manifest.age` is mutable through conditional writes. - Each `snapshots/.age` object is immutable and created only if absent. - Both object kinds use `application/octet-stream`. - A failed manifest update can leave an orphaned immutable snapshot; it is not a new head. ## Decrypted manifest v1 The manifest ciphertext decrypts directly to one JSON object. It is limited to 4 MiB before parsing and rejected when `schema_version` is not `1`. | Field | Current meaning | | --- | --- | | `schema_version` | Manifest contract version; currently `1`. | | `revision` | The snapshot UUID assigned by the most recent successful head update. | | `sessions` | Map keyed by `agent:session_id`. | | `updated_at` | UTC RFC 3339 time of the successful update. | Every session entry contains `agent`, `session_id`,`snapshot_id`, `project_id`, and `updated_at`. Storage ETags and conditional create/update requests provide optimistic concurrency; they are not fields inside the plaintext manifest. ## Decrypted snapshot framing ``` \n ``` The first newline terminates metadata. Metadata is limited to 1 MiB. The remaining bytes are the adapter artifact described by the sole `files[0]` entry; there is no delimiter, base64 layer, ZIP container, or second payload. ## Envelope v1 fields | Field | Validation and meaning | | --- | --- | | `schema_version` | Must equal `1`. | | `kind` | Must equal `reinstate-session-snapshot`. | | `snapshot_id` | UUID selected at push and required to match the requested object. | | `parent_revision` | Previous remote snapshot UUID for the same session, or empty on its first head. | | `agent` | Current adapter identifier, `claude` or `codex`. | | `adapter_schema` | Adapter artifact contract version; Reinstate writes `1`. | | `source_agent_version` | Reserved metadata field; Reinstate does not populate it in the current push path. | | `source_platform` | Detected source platform identifier. | | `project_id` | Configured canonical project identity, checked against the pull request. | | `session_id` | Vendor session identity, checked against the pull request. | | `created_at` | UTC RFC 3339 snapshot creation time. | | `files` | Exactly one logical adapter-artifact descriptor. | The single file descriptor has `path`, `mode`, `size`, and`sha256`. The path is a validated forward-slash vendor-relative session path; mode is currently `0600`. Size and SHA-256 cover the complete TAR payload bytes following the metadata line, not the JSON metadata and not merely the inner JSONL record. ## Adapter TAR payload Both Reinstate adapters produce a streamed POSIX TAR containing exactly one transformed JSONL session entry. Claude entries must remain below `projects/`; Codex entries must remain below`sessions/`. The TAR entry name must match the planned archive path, remain relative, end in `.jsonl`, and pass the adapter's safe-path checks. Export normalizes only allow-listed structural path fields. Restore expands those fields through destination mappings, may rewrite the structural session ID for an explicit keep-both resolution, backs up an existing destination, writes atomically, and verifies that the native adapter discovers the exact restored path. ## Encryption and secret boundary Both manifest and snapshot plaintext are streamed through the Go`filippo.io/age` implementation using an age scrypt passphrase recipient. The passphrase is required for encryption and decryption but is not written into the manifest, envelope, TAR, config file, object key, or remote metadata. Storage credentials stay outside the synchronized objects. “Encrypted” does not mean the format hides every piece of object-store metadata. A storage operator can still observe bucket/object keys, object sizes, request timing, and update patterns. The [security model](https://reinstate.dev/docs/security-model) defines that boundary. ## Restore validation sequence 1. Fetch and authenticate the age ciphertext with the supplied passphrase. 2. Bound and parse the metadata line. 3. Require the supported schema, snapshot kind, identity, agent, session, and project. 4. Require exactly one safe, relative, non-credential artifact path. 5. Stream at most the declared payload size and verify its exact SHA-256 digest. 6. Require a supported adapter and a safe one-entry TAR path. 7. Plan the destination, backup any existing session, and write through a private temporary file. 8. Rediscover the exact session ID at the exact planned native path. The default snapshot payload maximum is 32 GiB and each transformed JSONL record is limited to 16 MiB. These are implementation bounds, not recommended session sizes or benchmark claims. ## Evolution, inspection, and migration Unknown envelope or manifest schema versions fail closed today. There is no committed public migration command or third-party conformance suite. A future inspector or migration checker must operate locally, redact user data, distinguish ciphertext metadata from decrypted content, and ship only after fixtures and downgrade/failure behavior are reviewed. Internal specification, not portability standard. Publishing the current bytes makes Reinstate inspectable. Calling the format an open portability standard would require a separate public proposal, governance, independent implementations, compatibility fixtures, and version-negotiation rules that do not exist in Reinstate. ## Normative implementation sources - [Envelope v1 structs and constants](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/schema/envelope.go) - [Manifest v1 structs and constants](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/schema/manifest.go) - [Snapshot framing, limits, storage, and validation](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/sync/push.go) - [age scrypt encryption](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/crypto/envelope.go) - [Claude archive contract](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/adapter/claude/claude.go) - [Codex archive contract](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/adapter/codex/codex.go) ## Related evidence [Research and evidence hub](https://reinstate.dev/research) [Terminology glossary](https://reinstate.dev/glossary) [Security overview](https://reinstate.dev/security) [Architecture](https://reinstate.dev/docs/architecture) [Compatibility](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/research/encrypted-snapshot-format-v1 Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. Last modified: 2026-09-07. --- Product roadmap # Reinstate Roadmap: From Encrypted Sync to Work Continuity > Review stable v0.5.1 Stable v0.2.0 implements encrypted same-vendor sync and local continuity. Stable v0.3.0 adds verified resume. Stable v0.4.0 adds explicit structured cross-agent handoff after dual-platform tagged-artifact acceptance PASS. Stable v0.5.1 adds universal agent coverage by support tier after dual-platform tagged-artifact acceptance PASS. The v0.6.0-rc.6 release candidate carries Phase 6C cloud continuity (Reinstate Hop) and the interactive CLI; it is not yet certified, with tagged-artifact acceptance pending on native Windows x64 and Apple Silicon macOS deferred; the public installers already pin this candidate while that acceptance run is pending. Phase 6A/6B universal configuration remains planned. Phase 7 is project continuity, planned and targeted at v0.8.0. Phase 8 is Console. Phase 9 is team continuity. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## How to read this roadmap A checked implementation item is not automatically a stable product claim. Each phase has an evidence gate, and the public compatibility page remains the source for what a released binary may mutate safely. Priorities can change with real activation data and coding-agent format changes. Current release boundary Stable `v0.5.1` supports encrypted same-vendor Claude Code and Codex session synchronization, configless local continuity, verified resume, structured handoff, and universal agent coverage by support tier, after dual-platform tagged-artifact acceptance PASS. Apple Silicon macOS and native Windows x64 remain the verified stable platforms; Intel macOS and Linux/WSL2 remain preview and unverified. The `v0.6.0-rc.6` release candidate carries Reinstate Hop and the interactive CLI experience but is not yet certified; its tagged-artifact acceptance is pending on native Windows x64 only, with Apple Silicon macOS deferred until that hardware returns. The public installers already pin this candidate while that acceptance run is pending; see the [changelog](https://reinstate.dev/changelog) for the exact pinned tag. ## Phase map | Phase | Outcome | Current state | Gate | | --- | --- | --- | --- | | 0 | Trustworthy contracts, diagnostics, installers, fixtures, CI, and documentation | Complete | Released foundation and evidence contracts | | 1 | Encrypted same-vendor Claude Code and Codex session sync | Stable | Verified on Apple Silicon macOS and native Windows x64 | | 2 | Local universal session index, search, inspect, and native resume | Stable | Complete physical matrix on the two verified stable platforms | | 3 | Verified resume against repository, runtime, agent, MCP, and skill state | Stable | Dual-platform tagged-artifact acceptance PASS; stable published | | 4 | Explicit portable checkpoints for cross-agent handoff | Stable | Dual-platform tagged-artifact acceptance PASS on Apple Silicon macOS and native Windows x64. Lossy behavior and destination capability differences remain visible | | 5 | Universal agent coverage: one catalog, one support-tier ladder, honest T0 | In progress | v0.5.0 artifacts discover, search, and inspect additional agents only at the committed tier. No new T4 destinations or T5 sync agents | | 6 | Universal non-secret configuration and automatic cross-device reconciliation | Split: cloud continuity (6C, the Hop client) is in release preparation as a candidate; universal configuration (6A/6B) remains planned for a later release | Render native harness configuration without raw credential or config-tree mirroring | | 7 | One project understanding: durable rules and decisions rendered to every agent, plus learned memory with provenance | Planned | State a rule once and have every gated harness honor it; capture a memory in one agent's session and retrieve it, with provenance, from another; flag a memory a later decision contradicts | | 8 | Optional thin console for selecting and preparing work | Exploring | Agents continue to own execution; Reinstate remains the continuity client | | 9 | Team checkpoints, onboarding, provenance, and policy | Exploring | Individual continuity must first be proven safe and useful | ## Phase 5 — Universal agent coverage Phase 5 replaces five agents described in prose with one catalog and a six-rung tier ladder. Public surfaces state the rung. Encrypted sync stays Claude Code and Codex CLI. Native resume stays same-vendor. | Item | Status | | --- | --- | | Catalog core and the five shipped agents at unchanged tiers | In progress | | Wave A/B/C descriptors at T0 with a recorded reason | In progress | | Gemini CLI promotion from T2 to T3 | Stays T2 | | New T4 destinations or T5 sync agents | Out of scope | | Phase 5 dual-platform tagged-artifact acceptance | Planned | ## Native resume and portable handoff stay distinct Native resume preserves a vendor's own session format: Claude Code resumes Claude Code, and Codex resumes Codex. A structured handoff is a different operation, added in stable`v0.4.0`: it carries an explicit checkpoint—goal, decisions, rejected approaches, files, tests, and next action—so a *new* session in another agent can continue the same task. It is not a resume of the original session, and Reinstate will not market that lossy checkpoint as invisible transcript translation. ## Universal configuration without unsafe mirroring Phase 6, not Phase 5, is the configuration and cloud-continuity layer, and it now splits in two. Cloud continuity (6C), the Hop client for encrypted multi-device sync, is in release preparation ahead of the rest. Universal configuration (6A/6B) remains planned: it will describe portable intent for MCP servers, skills, instructions, hooks, plugins, marketplaces, and safe settings. Adapters will preview and render each supported harness's native format. Raw API keys, OAuth tokens, cookies, vendor credential stores, and unrelated native settings remain excluded. ## Near-term non-goals - A custom editor, terminal emulator, or full agentic development environment. - A multi-agent scheduler, model router, or worktree orchestration platform. - A proprietary agent plugin runtime or marketplace. - Replacing Git as source truth. - Perfect silent Claude Code ↔ Codex transcript translation. - Shipping vendor credentials or mirroring complete configuration trees. ## How priorities move The north-star measure is previously started coding tasks successfully resumed per active user. Device count and storage volume are not substitutes. The maintainer will weigh real continuation failures, compatibility churn, security risk, and repeated user requests before promoting a planned phase. The repository's[version-controlled roadmap](https://github.com/HarjjotSinghh/reinstate/blob/main/ROADMAP.md) is authoritative for item-level status. Open a sourced issue or discussion to propose a change. ## Roadmap context [Current product facts](https://reinstate.dev/about/reinstate) [Current compatibility](https://reinstate.dev/compatibility) [Current limitations](https://reinstate.dev/docs/limitations) [Source and contribution paths](https://reinstate.dev/open-source) --- Source: https://reinstate.dev/roadmap Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Synthetic path-mapping lab # macOS ↔ Windows Coding-Agent Path-Mapping Visualizer > Visualize how Reinstate maps fixed synthetic Claude Code and Codex structural paths between macOS and Windows through one canonical project ID. Reinstate maps a recognized structural path by replacing the source device’s configured project root with a portable canonical project token, then expanding that token through the destination device’s mapping. This explainer uses fixed synthetic data only; it does not accept, persist, or transmit a real local path. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Explore a synthetic mapping Choose a direction and current Phase 1 adapter. Every value below is a public fixture invented for this page. There is no free-text field, file access, or clipboard read. No analytics script is rendered, and changing a visualizer selection makes no network request. Selections are never written to cookies, local storage, or session storage; the site's unrelated theme preference may use local storage. DirectionAgent Synthetic-only control: selections update this document in memory and are discarded on navigation. 1 · Source mapping ### macOS device - **Canonical project ID:** `github.com/acme/acme-app` - **Configured local root:** `/Users/alex/Code/acme-app` - **Recognized field:** `cwd` 2 · Portable value ### Encrypted snapshot - **Structural token:** `$${REPO:github.com/acme/acme-app}/src/main.go` - **Transcript prose:** `Open /Users/alex/notes.txt` unchanged 3 · Destination mapping ### Windows device - **Configured local root:** `C:\src\acme-app` - **Expanded value:** `C:\src\acme-app\src\main.go` ### Recognized record trace Before export `{"cwd":"/Users/alex/Code/acme-app/src/main.go"}` Inside adapter archive `{"cwd":"${REPO:github.com/acme/acme-app}/src/main.go"}` After restore `{"cwd":"C:\src\acme-app\src\main.go"}` ### Native session locator Claude Code restore recomputes its destination project-directory key from`C:\src\acme-app`; it does not reuse the macOS directory key. ## Recognized structural fields | Adapter | Allow-listed keys in Reinstate | Additional native-layout rule | | --- | --- | --- | | Claude Code | `cwd`, `path`, `file`,`filename`, `filePath`, `file_path`,`projectPath`, `project_path`,`workingDirectory`, `workdir` | Recompute the destination project-directory key from the mapped checkout root. | | Codex CLI | `cwd`, `path`, `workdir`,`workingDirectory`, `filePath`, `file_path` | Keep the native date-partitioned rollout path and remap structural values. | A value is considered path-like only when it is absolute, already portable, or uses a recognized Windows drive-path shape. Unknown keys remain untouched even when their text looks like a path. ## What the mapper does not change - Free-form prompt, response, reasoning, or terminal-output prose. - Unknown JSON keys or relative strings that do not meet the structural rule. - Git branch, commit, uncommitted changes, runtime, shell, MCP, skill, or plugin state. - Claude Code sessions into Codex sessions, or Codex sessions into Claude Code sessions. - A project with no configured canonical mapping when mappings are required. ## Operational boundary This visualizer explains deterministic source behavior; it does not execute Reinstate or validate a private checkout. Use `rein setup check` and a pull dry-run on each real device. Reinstate source checks and synthetic fixtures do not replace the remaining physical Windows, macOS amd64, WSL2, and two-device acceptance gates. Do not paste a real private path into a website. The current visualizer intentionally offers no such input. A future local diagnostic would need a separate threat model, reviewed client-only implementation, redaction rules, and tests proving that input never leaves the device. ## Source evidence - [Portable token mapper](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/pathmap/token.go) - [Claude structural-field and destination-key logic](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/adapter/claude/claude.go) - [Codex structural-field and rollout logic](https://github.com/HarjjotSinghh/reinstate/blob/v0.1.0/internal/adapter/codex/codex.go) ## Apply the model safely [macOS and Windows use case](https://reinstate.dev/use-cases/macos-and-windows) [Cross-platform guide](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows) [Terminology glossary](https://reinstate.dev/glossary) [Compatibility matrix](https://reinstate.dev/compatibility) [Architecture](https://reinstate.dev/docs/architecture) --- Source: https://reinstate.dev/tools/path-mapping-visualizer Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Use cases # Reinstate Use Cases for Cross-Device Coding-Agent Work > Explore how Reinstate continues Claude Code and Codex sessions across work, personal, desktop, laptop, macOS, and Windows devices with encrypted storage. Reinstate helps developers find and continue local coding-agent sessions, then optionally move supported Claude Code or Codex sessions to another configured computer—especially a work and personal machine, or a Windows desktop and Mac laptop—with local encryption and user-owned storage between them. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Current continuity use cases [### Work and personal computers Push an encrypted supported session from one configured device and pull it on another without requiring the source device to remain online. Plan the two-device workflow →](https://reinstate.dev/use-cases/work-and-personal-computers)[### macOS and Windows Give one project a canonical ID, then map that identity to different native paths on a Mac and Windows PC. Understand path remapping →](https://reinstate.dev/use-cases/macos-and-windows)[### Desktop and laptop Continue one selected same-vendor session on a portable or fixed computer without keeping the source machine online. Plan desktop-to-laptop continuity →](https://reinstate.dev/use-cases/desktop-and-laptop)[### Encrypted session backup Create client-encrypted snapshots in storage you control while preserving the difference between Reinstate recovery and an independent backup strategy. Review the backup boundary →](https://reinstate.dev/use-cases/encrypted-session-backup) ## When Reinstate is a fit today - You use a tested Claude Code or Codex CLI version. - You want same-vendor continuity on another configured device. - Your repository lives at different absolute paths on the two machines. - You can use an S3-compatible bucket and retain the encryption passphrase safely. - You are comfortable running a pre-1.0 release and keeping backups. ## When it is not yet a fit - You need Claude Code sessions converted into native Codex rollouts, or the reverse. - You use an agent below T5: Gemini CLI, Kimi Code CLI (T2), Grok Build or Qwen Code (T4 handoff, no sync), or a T0/T1 discover-only agent. See the[integrations page](https://reinstate.dev/integrations) for exact tiers. - You need MCP servers, skills, plugins, agent credentials, or settings synchronized. - You need stable-v1 compatibility guarantees or a formally audited security product. - Your employer prohibits storing work artifacts in a personally controlled bucket. Stable v0.2.0 includes one-machine search. Stable v0.3.0 adds dual-platform verified resume. Stable v0.4.0 adds portable cross-agent checkpoints after tagged-artifact acceptance PASS. Stable v0.5.1 adds universal agent coverage by support tier. The v0.6.0-rc.6 release candidate carries Reinstate Hop and the interactive CLI, not yet certified; native Windows x64 acceptance is pending and Apple Silicon macOS is deferred. Non-secret configuration remains later roadmap work. ## The common continuity workflow 1. Install the same pinned Reinstate version on each trusted device. 2. Configure one profile, one bucket, and canonical IDs for the projects you will move. 3. Push supported sessions from the device where the work currently exists. 4. On the destination, inspect status and run a pull dry-run before restoring. 5. Resume using the same native agent vendor after the project path is mapped locally. ## Plan your setup [Getting started](https://reinstate.dev/docs/getting-started) [Supported integrations](https://reinstate.dev/integrations) [Compatibility matrix](https://reinstate.dev/compatibility) [Security boundaries](https://reinstate.dev/security) [Mac-to-Windows guide](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows) --- Source: https://reinstate.dev/use-cases Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Use case · Desktop and laptop # Continue Coding-Agent Sessions from Desktop to Laptop > Move one encrypted Claude Code or Codex session between a configured desktop and laptop with Reinstate, user-owned storage, path mapping, and safe restore. Reinstate can move one selected Claude Code or Codex session from a desktop to a laptop through an age-encrypted snapshot in your own S3-compatible bucket. Each computer keeps its own checkout path, agent login, and local tools; both map the project to one canonical ID and resume through the same vendor. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## The outcome: continue the same task on the other computer This workflow is for a developer whose coding-agent task exists on a desktop but who needs to continue it on a laptop—or the reverse. Reinstate transfers supported vendor-native session state after an explicit push. It is stored between devices, so the source computer does not need to remain online while the destination pulls. Reinstate supports same-vendor Claude Code and Codex CLI session transfer. It does not move the Git repository, log the agent into its vendor account, reproduce the entire development environment, or convert a Claude Code session into a Codex rollout. | Continuity layer | What it carries | What remains independent | | --- | --- | --- | | Git | Source and committed history | Uncommitted state unless you move it separately | | Reinstate | Selected supported session plus portable structural paths | Vendor credentials, settings, MCP servers, skills, and plugins | | Your S3-compatible bucket | Encrypted profile manifest and immutable session snapshots | The passphrase, which Reinstate does not store | | Claude Code or Codex CLI | Native session resume on the destination | Cross-vendor conversion | ## When this use case fits Reinstate - Both computers are trusted and authorized to hold the project and session. - Both use the exact Reinstate binary and a recognized version of the same agent vendor. - The project is checked out normally on each device, even if its absolute paths differ. - Both can access one private S3-compatible profile and their own OS keyrings. - You can retain the long encryption passphrase independently of both computers. - You are using pre-1.0 software and will keep independent backups. Stable v0.2.0 physical evidence covers Apple Silicon macOS and native Windows x64. Intel macOS and Linux/WSL2 are preview and unverified. A successful personal transfer on one of those preview platforms is useful evidence, not stable platform certification. Device policy still applies. User-owned storage does not override employment, client, residency, repository, or endpoint policy. A work session should reach a personal laptop only when that device and bucket are explicitly approved. ## The explicit desktop-to-laptop workflow 1. Install Reinstate and the recognized same-vendor agent on both computers. Run`rein setup check` and stop if the selected adapter is`UNTESTED` or `UNSUPPORTED`. 2. Give the project a stable ID such as `github.com/acme/app`. Map it to the desktop checkout during first-device `rein init`. 3. Close the source agent, select one ID, and run`rein push --agent AGENT --session SESSION_ID --dry-run` before the matching mutating push. 4. Join the laptop with `rein init --profile-id PROFILE_ID`, the same storage coordinates, and the same project ID mapped to the laptop's own checkout. 5. Run `rein status`, close the destination agent, and preview`rein pull --agent AGENT --session SESSION_ID --dry-run`. 6. Pull only after the destination and backup root are correct. Resume the exact ID through`claude --resume SESSION_ID` or `codex resume SESSION_ID`. The reverse trip uses the same process: exit the laptop agent, push its changed session, preview the pull on the desktop, restore, and resume through the same vendor. ## Different checkout paths are expected Each device maps its physical checkout to the same portable project identity. A desktop path such as `D:\src\app` and laptop path such as`/Users/me/Code/app` can both represent`github.com/acme/app`. Reinstate normalizes only known structural fields and expands them through the destination mapping during restore. Path mapping does not rewrite prose, reproduce a shell, switch Git branches, install a runtime, or copy environment variables. Check repository and environment state before native resume. ## What verifiable success looks like - Both computers report `0.1.0` and a`SUPPORTED` same-vendor adapter. - The source dry-run selects exactly one intended session and uploads nothing. - The mutating push creates an encrypted manifest and opaque `.age` snapshot. - The destination joins the exact first-device profile UUID and verifies its manifest. - The pull dry-run reports one destination and backup root without creating either. - An existing destination is backed up before atomic replacement. - The vendor-native resume UI opens the intended ID at the mapped checkout. Retain redacted versions, exit codes, IDs, counts, object names, and path-equivalence booleans. Do not retain transcript contents, passphrases, storage secrets, or downloaded snapshots in public evidence. The repository's[physical acceptance checklist](https://github.com/HarjjotSinghh/reinstate/blob/main/docs/testing/phase-1-mac-windows-acceptance.md)remains the release authority. ## Failure recovery | Failure | Safe response | | --- | --- | | Compatibility exit `5` | Stop mutation and use a recognized agent version; do not force an unknown layout. | | Manifest missing on the laptop | Confirm the source pushed first and reuse its exact profile, endpoint, Region, bucket, and prefix. | | Wrong-passphrase failure | Preserve ciphertext and local files, verify the phrase privately, and retry; no restore should occur. | | Safety exit `7` | Close the destination vendor process and rerun the dry-run; never bypass an active-file refusal. | | Conflict exit `6` | Inspect conflict metadata and preserve both branches with `--keep-both` when neither may be discarded. | | Wrong destination path | Stop before pull, correct the project mapping through reviewed re-initialization, and preview again. | Reinstate has no general undo command. A dry-run is the safest rollback because it creates nothing. After a real replacement, preserve the timestamped local backup before taking another action. Do not delete the remote manifest merely to make a broken profile look empty. ## Why independent backups still matter Reinstate's remote profile is optimized for continuity, not comprehensive disaster recovery. Reinstate does not manage provider versioning, retention, archival restore, or remote garbage collection. A mistaken provider deletion, compromised write credential, lost passphrase, or damaged endpoint can make the continuity copy unavailable. - Keep the repository in Git and back up uncommitted work through an approved process. - Keep provider versioning or retention only when it is tested with Reinstate's mutable manifest. - Retain the passphrase in a password manager with an approved recovery process. - Periodically test a harmless restore instead of assuming encrypted objects are recoverable. - Preserve local timestamped session backups until the restored session is verified. ## Desktop and laptop continuity FAQ ### Must both computers be online together? No. After a successful push, the encrypted artifact lives in your bucket. The source can be offline when the destination pulls, although each transfer needs provider access. ### Can the desktop use Windows while the laptop uses macOS? That is the flagship path-remapping case, but native device and physical two-device acceptance remain open Reinstate gates. Use the[Mac-to-Windows guide](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows)and report success as evaluation evidence, not certification. ### Can one side run WSL2? WSL2 must be configured as a separate Linux Reinstate device with its own home, agent state, and paths. Do not share one agent-state directory between native Windows and WSL. WSL1 is unsupported. ### Does Reinstate copy my agent login or API key? No. Vendor authentication, API keys, OAuth material, credential stores,`.env` files, and OS keyring contents are excluded. Authenticate the vendor independently on each computer. ### What if both devices changed the same session? Pull must not silently overwrite a divergent local copy. Reinstate records conflict metadata; review it and choose an explicit resolution. `--keep-both` preserves the local branch and restores a distinct vendor-safe fork of the remote branch. ## Plan the two-device setup [Mac-to-Windows command guide](https://reinstate.dev/guides/move-a-coding-agent-session-from-mac-to-windows) [Encrypted recovery copy](https://reinstate.dev/use-cases/encrypted-session-backup) [Work and personal computers](https://reinstate.dev/use-cases/work-and-personal-computers) [Current compatibility evidence](https://reinstate.dev/compatibility) [Security and restore boundaries](https://reinstate.dev/docs/security-model) --- Source: https://reinstate.dev/use-cases/desktop-and-laptop Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Use case · Encrypted recovery copy # Create an Encrypted Backup of Coding-Agent Sessions > Store selected Claude Code or Codex session snapshots as client-encrypted objects in your own S3-compatible bucket, then verify and test restore. Reinstate can create a client-encrypted recovery copy of selected Claude Code or Codex sessions in your own S3-compatible bucket. It encrypts before upload, excludes known credential material, and can restore through the same vendor—but it is not a complete backup system, so keep independent, restore-tested backups too. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## A narrow encrypted recovery copy, not a general backup product Reinstate snapshots explicitly selected, supported Claude Code or Codex CLI session artifacts and uploads them only after local age passphrase encryption. The provider receives ciphertext, opaque snapshot keys, sizes, timing, account identity, and bucket metadata. It does not receive the encryption passphrase. “Backup” here means a recoverable encrypted copy of supported agent-session state. Reinstate does not back up repositories, uncommitted work, home directories, vendor accounts, credentials, every agent, or the complete execution environment. It does not promise provider retention, point-in-time recovery, or automatic background scheduling in Reinstate. | Included | Excluded or separate | | --- | --- | | Selected supported Claude Code or Codex session artifact | Other agents and unsupported or untested layouts | | Encrypted manifest and immutable snapshot metadata | Git repository, branch, worktree, and uncommitted changes | | Portable known structural project paths | Free-form paths inside transcript prose or tool output | | Conflict and local replacement safety | Vendor login, API keys, OAuth, `.env`, keyrings, or credential stores | | Same-vendor restore | Native Claude Code-to-Codex or Codex-to-Claude conversion | ## Where encryption and trust boundaries sit 1. A supported adapter discovers the selected local vendor artifact and known structural path fields. 2. Reinstate normalizes configured project paths, packages the immutable snapshot, and encrypts it locally with an age scrypt recipient derived from the passphrase. 3. HTTPS carries ciphertext to the private bucket under`profiles/PROFILE_ID/snapshots/.age`. 4. The encrypted `manifest.age` records the current remote session revisions. 5. A restore downloads and fully authenticates/decrypts the artifact before any vendor file is mutated. Storage credentials entered interactively are stored in macOS Keychain, Windows Credential Manager, or the supported OS keyring. The passphrase is not stored by Reinstate. Losing it means losing the ability to decrypt the remote profile by design. ## Create the encrypted copy deliberately First configure a private bucket with the narrow read, list, write, and delete access required by Reinstate. The[Amazon S3 guide](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage)and[Cloudflare R2 guide](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage)separate provider setup from Reinstate setup. After `rein init`, setup checks, and a synthetic self-test pass: ``` rein list --agent AGENT rein push --agent AGENT --session SESSION_ID --dry-run rein push --agent AGENT --session SESSION_ID rein status ``` Choose exactly one harmless session for the first run. The dry-run must say`would push` and must not create a snapshot. The mutating push should report the selected count and a remote revision. Avoid `--all` until the full discovered scope has been reviewed. Encryption cannot un-publish a secret already in a transcript. Known credential files are excluded, but a token pasted into agent conversation is session content and will be protected as part of the encrypted snapshot. If such a token was exposed, rotate it; do not treat encryption as remediation. ## Verify ciphertext and recoverability separately A `.age` suffix alone is not proof. Perform two controlled checks without publishing transcript data. ### 1\. Inspect the provider boundary - The profile prefix contains `manifest.age` and opaque`snapshots/*.age` objects. - No plaintext JSON/JSONL transcript, `.env`, `auth.json`, token, or credential object exists. - A privately downloaded snapshot does not contain a known harmless marker in plaintext. - The temporary initialization probe has been deleted. - The bucket remains private and uses no public website or development URL. ### 2\. Test a destination restore On a separately configured compatible device—or an isolated Reinstate home with an approved test target—join the exact profile UUID, map the same project ID, and run: ``` rein setup check rein doctor --self-test rein status rein pull --agent AGENT --session SESSION_ID --dry-run ``` Confirm the planned native destination and backup root. Close the same-vendor agent, perform the pull, then use `claude --resume SESSION_ID` or`codex resume SESSION_ID`. A backup is credible only after a controlled recovery drill reaches the intended session. Stable physical verification covers Apple Silicon macOS and native Windows x64; Intel macOS and Linux/WSL2 remain preview and unverified. Personal restore evidence must not be represented as project-wide stable certification. ## What protects an existing destination - Pull offers a non-mutating `--dry-run` that reports destinations and the backup root. - A wrong passphrase fails authentication before agent-file mutation. - An active same-vendor process causes safety exit `7` before replacement. - An existing destination is copied into a timestamped local backup before atomic replacement. - Diverged local and remote revisions produce conflict exit `6`, not silent last-writer-wins. - `rein conflicts resolve CONFLICT_ID --keep-both` can preserve both branches. These controls protect restore operations; they do not prevent a bucket administrator or compromised write credential from deleting, replacing, or rolling back ciphertext. ## Failure and recovery decisions | Failure | What remains safe | Next action | | --- | --- | --- | | Storage probe fails | Reinstate does not save a usable-looking config | Correct endpoint, Region, bucket, credential, or delete access; retry init. | | Push dry-run fails | No remote session snapshot was written | Resolve compatibility, selection, path, keyring, or provider access first. | | Passphrase is lost | Local vendor files and independent backups may remain | Do not overwrite local history; the remote ciphertext cannot be decrypted. | | Remote manifest disappears | Additional devices fail closed instead of treating the profile as empty | Preserve snapshots and restore the manifest through an approved provider recovery process. | | Local and remote copies diverge | Pull records a conflict without overwriting local state | Inspect metadata and choose keep-local, keep-remote, or keep-both explicitly. | | Provider credential is exposed | Session plaintext still requires the separate passphrase | Revoke or rotate the credential, audit objects, preserve local copies, and investigate tampering. | Reinstate has no general undo or remote-session deletion command. Provider cleanup must target only a reviewed `profiles/PROFILE_ID/` tree after participating devices stop and required evidence or backups are preserved. Never delete only `manifest.age`. ## Build an independent backup plan around it The encrypted Reinstate profile and the independent backup should fail differently. Keeping both in the same bucket, account, credential boundary, and retention policy can turn one provider mistake into total loss. - Keep source code and repository history in the approved Git workflow. - Protect uncommitted work with a separately reviewed endpoint or workstation backup. - Retain the encryption passphrase in a password manager with an authorized recovery path. - Decide provider versioning, lifecycle, Object Lock, or bucket-lock policy deliberately. - Test retention controls before applying them: the manifest changes, init probes need delete access, and archival tiers can make ordinary pull unavailable. - Schedule harmless restore drills and record only redacted metadata and pass/fail evidence. ## Current limitations - Reinstate uses explicit pushes and pulls; it is not an automatic backup daemon. - It has no built-in schedule, retention policy, remote pruning, or provider version restore. - Snapshots are complete immutable session artifacts rather than block- or delta-level backups. - Only recognized Claude Code and Codex CLI same-vendor workflows can mutate state. - Project path mapping does not reproduce Git, runtimes, shells, environment, or agent configuration. - Remote confidentiality does not protect a compromised local device or guarantee availability. - A formal pre-1.0 security audit is not claimed. ## Encrypted session backup FAQ ### Can the storage provider read my session? The provider should receive age-encrypted manifests and snapshots, not plaintext session contents or the passphrase. It can still observe account, bucket, object keys, sizes, request timing, and access patterns. ### Does provider-side encryption replace Reinstate encryption? No. S3 or R2 encryption at rest is useful defense in depth. Reinstate's client-side encryption creates the boundary in which the provider receives ciphertext. ### Are agent credentials backed up? No. Known auth files, OAuth material, API keys, `.env` files, credential stores, and keyring contents are excluded. Configure vendor authentication independently on a restored device. ### Can I restore the session into another agent vendor? No. Reinstate restores Claude Code state to Claude Code and Codex state to Codex CLI. Explicit portable handoffs are later product direction, not a hidden conversion performed by backup restore. ### Should I enable immutable retention on the profile? Not without testing. The encrypted manifest changes as sessions are pushed, and the initialization probe requires deletion. Object Lock or bucket-lock rules can block those operations. Provider versioning can be valuable, but cleanup and restore procedures must account for old versions and delete markers. ### How often should I test recovery? Use a cadence appropriate to the value and change rate of the sessions. Every test should use harmless data, preview restore, verify the mapped destination, preserve existing state, and prove native resume without exposing transcript contents. ## Configure and test encrypted recovery [Amazon S3 setup](https://reinstate.dev/guides/use-s3-for-coding-agent-session-storage) [Cloudflare R2 setup](https://reinstate.dev/guides/use-cloudflare-r2-for-coding-agent-session-storage) [Desktop and laptop continuity](https://reinstate.dev/use-cases/desktop-and-laptop) [Encryption and restore safety](https://reinstate.dev/docs/security-model) [Current compatibility evidence](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/use-cases/encrypted-session-backup Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Use case · macOS ↔ Windows # Move Claude Code and Codex Sessions Between macOS and Windows > Learn how Reinstate remaps configured project paths to move encrypted Claude Code and Codex sessions between macOS and native Windows. Reinstate is designed to move supported same-vendor Claude Code and Codex sessions between macOS and Windows even when the same project has different absolute paths. A canonical project ID links the two checkouts; agent-specific adapters reconstruct the destination’s native structural paths. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## Why copying the agent folder is not enough Agent session formats contain absolute paths. A checkout at `C:\src\app` on Windows may be `/Users/you/Code/app` on macOS. Claude Code also derives a project-directory key from that path, while Codex records its structural working directory inside each rollout. A blind folder copy cannot safely reconcile those identities. ## The canonical project mapping | Identity | Windows device | macOS device | | --- | --- | --- | | Canonical project ID | `github.com/acme/app` | `github.com/acme/app` | | Local root | `C:\src\app` | `/Users/you/Code/app` | | Portable identity | `$${REPO:github.com/acme/app}` | `$${REPO:github.com/acme/app}` | Reinstate normalizes known structural paths during export and expands them through the destination mapping during restore. It does not search-and-replace every path-shaped string inside prompts or responses. ## How the two current adapters differ ### Claude Code The destination root is used to recompute Claude's exact project-directory key. Reinstate verifies the restored session at that planned location rather than accepting the same ID elsewhere. [Claude Code details →](https://reinstate.dev/integrations/claude-code) ### Codex CLI The source `session_meta.cwd` resolves to a project ID. Restore expands it to the destination root while retaining Codex's native date-partitioned rollout layout. [Codex details →](https://reinstate.dev/integrations/codex) ## Platform status Stable v0.2.0, v0.3.0, v0.4.0, and v0.5.1 have all passed dual-platform tagged-artifact acceptance on Apple Silicon macOS and native Windows x64. Intel macOS and WSL2 remain optional, unsupported/unverified evidence and do not block stable. The v0.6.0-rc.6 release candidate's acceptance is native Windows x64 only under the Windows-first waiver; Apple Silicon macOS is deferred until that hardware returns and is not claimed for this candidate. Do not merge native Windows and WSL into one device. WSL2 is a separately configured Reinstate environment with Linux path semantics. WSL1 is unsupported, and one shared agent-state folder between Windows and WSL is explicitly outside the supported model. ## Cross-platform setup checklist - Use the same pinned Reinstate version on both systems. - Install a tested version of the same agent vendor on both systems. - Clone the repository normally with Git on each system. - Map the same canonical project ID to each native checkout path. - Use one approved S3-compatible profile and the same encryption passphrase. - Run setup checks and a pull dry-run before the first real restore. - Close active agent processes before mutating their local session files. ## What path remapping does not solve - Different Git branches, commits, or uncommitted working-tree changes. - Missing runtimes, tools, MCP servers, skills, hooks, or plugins. - Shell-command differences between PowerShell and POSIX environments. - Paths embedded in free-form transcript text. - Native cross-agent transcript conversion. Stable v0.3.0 reports privacy-safe repository, agent, capability, and runtime truth before native resume. It does not repair the environment or prove that every dependency and source file matches. ## Cross-platform resources [Full platform matrix](https://reinstate.dev/compatibility) [Synthetic path-mapping visualizer](https://reinstate.dev/tools/path-mapping-visualizer) [Project mapping commands](https://reinstate.dev/docs/getting-started) [Two-computer workflow](https://reinstate.dev/use-cases/work-and-personal-computers) [Encrypted storage model](https://reinstate.dev/security) --- Source: https://reinstate.dev/use-cases/macos-and-windows Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page. --- Use case · Two computers # Sync Coding-Agent Sessions Between Work and Personal Computers > Use Reinstate to move encrypted Claude Code or Codex sessions between configured work and personal computers through your own S3-compatible storage. Reinstate can move a supported Claude Code or Codex session from a work computer to a personal computer through an encrypted artifact in your own S3-compatible bucket. The source computer can be offline when you pull, but both devices need the same profile, passphrase, project identity, and compatible agent version. - **Last verified:** September 7, 2026 - **Current release:** [v0.6.0-rc.6](https://github.com/HarjjotSinghh/reinstate/tree/v0.6.0-rc.6) - **Release status:** v0.6.0-rc.6 candidate · stable remains v0.5.1 · v0.6.0-rc.5 tagged Windows run (plus two same-artifact rechecks) ended FAIL (211/4/0/0 of 215), zero product defects, grok:E1-E3 live-backend-connectivity plus a grok version drift to 1.0.13 and an H7 digest-equality-unmeasurable gap the four PARTIAL rows · this candidate widens the verified Grok Build range to 1.0.13 and refines the H7 live-home check to per-file listing with attribution · native Windows tagged-artifact acceptance pending, macOS deferred - **Owner:** [Harjot Singh Rana](https://harjot.co/) ## What moves between the computers Reinstate moves selected, supported vendor-native session artifacts plus the structural metadata needed to restore them. It maps the same repository to a canonical project ID so each device can keep a different local checkout path. | Moves | Does not move | | --- | --- | | Supported Claude Code or Codex session artifacts | Your Git repository or working tree | | Portable structural project-path identity | Vendor login credentials, API keys, or OAuth tokens | | Encrypted manifest and artifact metadata | MCP servers, skills, plugins, hooks, or settings | | Conflict-safe version of remote session state | A translated transcript for a different agent vendor | ## Prerequisites on both devices - The same pinned stable Reinstate release. - A supported version of the same agent vendor. - A local checkout of the project at a configured path. - Access to the same S3-compatible bucket and profile prefix. - The same long encryption passphrase, entered locally. - Separate vendor login on each device; Reinstate does not transfer it. Confirm your employer's policy first. “Bring your own storage” does not override employment, source-code, data-residency, or device policy. Do not move work transcripts to a personal account or computer unless you are explicitly authorized to do so. Use an approved bucket and device boundary. ## A safe two-computer workflow 1. Install Reinstate on both machines and confirm the checksum-verified version with`rein version --json`. 2. On the first device, initialize a profile and map the repository to a stable project ID such as `github.com/acme/app`. 3. Join the same profile on the second device, mapping that project ID to its own absolute local checkout. 4. Push the selected same-vendor sessions on the source. Encryption happens before the bucket receives the artifact. 5. On the destination, run status and`rein pull --agent AGENT --session SESSION_ID --dry-run`; inspect the exact planned restore. 6. Pull, confirm the native destination path, then resume using Claude Code or Codex itself. ## Does the source computer need to stay on? No. Reinstate uses stored synchronization rather than a live remote-control relay. After a push succeeds, the encrypted artifact is in your bucket and the source computer can be offline when the destination pulls it. The destination still needs network access to the bucket. ## What if both computers changed the session? Do not expect silent last-writer-wins behavior. Reinstate records divergent state as a conflict and can create conflict forks instead of overwriting one side without notice. Pull dry-runs and the conflict commands are part of the normal workflow, not only recovery tools. ## Current limitations - Reinstate is not background automatic sync; pushes and pulls are explicit. - Source code still moves through Git or your existing repository workflow. - Vendor authentication must be configured independently on each device. - Phase 1 supports only tested Claude Code and Codex same-vendor sessions. - Stable native-device and two-device release certification is still in progress. ## Set up two computers [Exact setup commands](https://reinstate.dev/docs/getting-started) [macOS and Windows paths](https://reinstate.dev/use-cases/macos-and-windows) [Passphrase and storage security](https://reinstate.dev/security) [Check agent versions](https://reinstate.dev/compatibility) --- Source: https://reinstate.dev/use-cases/work-and-personal-computers Markdown representation of the reinstate.dev page; request the same URL with `Accept: text/html` for the full page.