Skip to content

Session persistence

Session persistence means your agent remembers everything, everywhere. Authenticate an AI engine once — Claude, Codex, Copilot — and your logins, session history, and settings automatically follow you to the next DevBox, on whatever worker happens to run it. No re-logging-in, no lost history when a DevBox stops and a new one starts somewhere else.

Under the hood, ClusterCode syncs only the config that lives in your DevBox’s home directory — ~/.claude, ~/.codex, your gh credentials, and the like — so a fresh DevBox picks up right where the last one left off. Your workspace files never sync; identity is portable, not data.

  • Engine logins — the OAuth sessions and tokens your AI engines write to disk, so you stay authenticated across DevBoxes.
  • Session history — your Claude / Codex / Copilot transcripts, so the agent keeps its memory of past work.
  • Settings — your per-engine configuration and house-style files.

Only your per-tool config ever follows you — the same set on every worker type. Your code stays in your git repositories and on the machine that made it.

Cloud workersSelf-hosted (BYOM) workers
Engine logins & sessions✅ Synced✅ Synced (opt-in)
Settings & config✅ Synced✅ Synced (opt-in)
DefaultOnOff

Cloud workers — ClusterCode hosts the machine and syncs your config only. Sign in once and your logins, sessions, and settings come back on the next DevBox. Your code never leaves the machine it’s on.

Self-hosted (BYOM) workers — machines you own and run yourself. ClusterCode syncs only your config and credentials here too. Because it’s your hardware, syncing even config from a self-hosted worker is opt-in — a separate toggle that’s off by default. Your code never leaves the machine it’s on.

Find these under Settings → Session persistence.

  • Persist my sessionsdefault on. Your agent config and sessions are saved when a DevBox stops and restored into the next one. Turn it off to start every new DevBox completely fresh.
  • Include my self-hosted workersdefault off. Also sync config and sessions from DevBoxes running on your own BYOM machines. Has no effect while Persist my sessions is off.
  • Delete stored data — permanently removes everything ClusterCode has stored for you. See the recovery window below.

Config changes sync within about five minutes, and again whenever a DevBox stops.

Session persistence is built so that ClusterCode’s storage never sees your data in the clear.

  • Encrypted end-to-end. Everything is encrypted with a per-user key before it ever leaves the worker. What ClusterCode stores is ciphertext — the storage service alone can’t read it.
  • Scoped, short-lived access. Workers receive only short-lived, tightly scoped credentials to write your data, and never hold the account keys.
  • Your code stays put. On every worker type, your workspace files are never uploaded or stored — only config, and on self-hosted workers only if you opt in. Your code lives in your git repositories and on the machine that made it.
  • Delete on demand. Delete stored data wipes your stored config and sessions. Deletes have a 14-day recovery window so an accidental deletion (or a bad sync) can be undone before it’s gone for good.

Does my code leave my machine on a self-hosted worker? No — and not on any worker type. Your code never leaves the machine it’s on. Only your engine config and sessions ever sync (and on self-hosted workers, only when you opt in). Your workspace files are never uploaded or stored.

How fast do my changes sync? Config syncs within roughly five minutes of a change, and again every time a DevBox stops.

Is my workspace / code stored? No. ClusterCode only stores your engine config and sessions (encrypted). Your code lives in your git repositories and on the machine that made it — ClusterCode never uploads or stores your workspace files, on any worker type.

How do I wipe everything ClusterCode has stored for me? Go to Settings → Session persistence and choose Delete stored data. It removes all your stored config and sessions. There’s a 14-day recovery window in case you change your mind.

Will turning persistence off delete what’s already stored? No — turning off Persist my sessions just stops future syncing; new DevBoxes start fresh. Use Delete stored data if you also want to remove what’s already stored.

Is my session tied to one specific worker? No. That’s the point — any worker can serve any DevBox by restoring your synced sessions, so you’re never stranded if a particular machine is busy or offline.

  • Settings — where the Session persistence controls live
  • DevBoxes — the environments your sessions follow you across
  • Cloud workers — managed machines with config + session persistence
  • Workers — self-hosted (BYOM) vs managed compute