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
- Owner
- Harjot Singh Rana
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 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 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
- Install RC8 and the recognized same-vendor agent on both computers. Run
rein setup checkand stop if the selected adapter isUNTESTEDorUNSUPPORTED. - Give the project a stable ID such as
github.com/acme/app. Map it to the desktop checkout during first-devicerein init. - Close the source agent, select one ID, and run
rein push --agent AGENT --session SESSION_ID --dry-runbefore the matching mutating push. - 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. - Run
rein status, close the destination agent, and previewrein pull --agent AGENT --session SESSION_ID --dry-run. - Pull only after the destination and backup root are correct. Resume the exact ID through
claude --resume SESSION_IDorcodex 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.8and aSUPPORTEDsame-vendor adapter. - The source dry-run selects exactly one intended session and uploads nothing.
- The mutating push creates an encrypted manifest and opaque
.agesnapshot. - 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
| 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. |
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.