Use case · Desktop and laptop

Continue Coding-Agent Sessions from Desktop to Laptop

Reinstate RC8 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
Current release
v0.1.0-rc.8
Release status
pre-1.0 release candidate

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.

RC8 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 layerWhat it carriesWhat remains independent
GitSource and committed historyUncommitted state unless you move it separately
ReinstateSelected supported session plus portable structural pathsVendor credentials, settings, MCP servers, skills, and plugins
Your S3-compatible bucketEncrypted profile manifest and immutable session snapshotsThe passphrase, which Reinstate does not store
Claude Code or Codex CLINative session resume on the destinationCross-vendor conversion

When this use case fits RC8

  • Both computers are trusted and authorized to hold the project and session.
  • Both use the exact RC8 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 evaluating release-candidate behavior and will keep independent backups.

Current source evidence covers the documented Claude Code and Codex version ranges on macOS arm64 plus deterministic fixtures. Native Windows, macOS amd64, WSL2, and physical two-computer resume remain open release gates. A successful personal transfer is useful evidence, not stable Phase 1 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 RC8 and the recognized same-vendor agent on both computers. Runrein setup check and stop if the selected adapter isUNTESTED 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 runrein 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 previewrein pull --agent AGENT --session SESSION_ID --dry-run.
  6. Pull only after the destination and backup root are correct. Resume the exact ID throughclaude --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 representgithub.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-rc.8 and aSUPPORTED 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'sphysical acceptance checklistremains the release authority.

Failure recovery

FailureSafe response
Compatibility exit 5Stop mutation and use a recognized agent version; do not force an unknown layout.
Manifest missing on the laptopConfirm the source pushed first and reuse its exact profile, endpoint, Region, bucket, and prefix.
Wrong-passphrase failurePreserve ciphertext and local files, verify the phrase privately, and retry; no restore should occur.
Safety exit 7Close the destination vendor process and rerun the dry-run; never bypass an active-file refusal.
Conflict exit 6Inspect conflict metadata and preserve both branches with --keep-both when neither may be discarded.
Wrong destination pathStop before pull, correct the project mapping through reviewed re-initialization, and preview again.

RC8 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. RC8 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 RC8 gates. Use theMac-to-Windows guideand 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. RC8 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.