If you use something like Claude's Cowork mode, or any local agentic setup, you have probably spent weeks tuning it. You wrote custom skills that encode how your team actually works. You taught it your writing voice. You wired up scheduled jobs that run every morning without you. It feels like a product. It behaves like infrastructure. And almost none of us have asked the obvious question: what happens to all of that if the laptop dies tonight?
Most of It Is Fine (and That's the Trap)
The risk hides well. When you actually inventory a local agent setup, most of it turns out to be recoverable, which lulls you into assuming all of it is.
The app and your account are cloud-backed. Reinstall, log in, done. Your connectors to Slack, Linear, Notion, Gmail, your calendar, your cloud storage: those are OAuth tokens pointing at cloud services. The token dying on your disk is irrelevant; you re-authorize and they are back. And the output of all your work, the tickets your agent filed, the messages it posted, the docs it uploaded, lives in those destination systems. Your recovery point objective there is effectively zero without you lifting a finger.
So you glance at the setup, see that most of it self-heals, and move on. That is exactly the trap.
The Crown Jewels Are the Part You Built
The irreplaceable components are the value you created, and they are the part with no undo:
- Your custom skills: the workflow logic specific to your org. This is months of accumulated institutional knowledge about how things actually get done, and it is the single hardest thing to reconstruct from memory.
- Your voice and memory: the accumulated context that makes the agent's output sound like you instead of like a stranger.
- Your scheduled tasks: the automations running on a cadence. Configuration that is technically quick to rebuild, but only if you remember every one of them.
- Your configuration: the settings, the project instructions, the record of which plugins and connectors are wired together.
- Your working folder: anything generated locally that has not yet been pushed somewhere durable.
None of that is backed by your account. It lives on one disk. And the failure modes extend well beyond a stolen laptop. In current builds, user-created skills have in some cases been written into ephemeral, per-session directories that get cleaned up automatically, silently deleting the very thing you spent the most time building. There is also no shared storage across the different Claude desktop products, so a skill you made in one place is invisible in another. The risk is not just hardware failure. It is an ordinary Tuesday.
Treat It Like Any Other System You'd Have to Recover
If you have ever run disaster recovery for real infrastructure, none of the fix is novel. The value is in remembering to point those instincts at your own productivity setup:
- Find out where your skills actually live. Ephemeral session directory or a durable path like
~/.claude/skills/? This is step zero. Everything else depends on the answer. - Put skills and config under version control. Move them into the durable location, then into a private git repo. Git becomes both your backup and your reinstall mechanism; recovery collapses to
git clone. Package the skills as a plugin and it gets cleaner still: recovery is a reinstall. - Back up the config directory: project instructions, settings, voice and memory files. Same repo or your dotfiles.
- Write a one-page recovery runbook. List the connectors to re-authorize and the scheduled tasks to recreate. You do not restore these from a file; you rebuild them. So the thing you actually need saved is the inventory.
- Test the restore. A backup you have never restored is a hope, not a plan. Clone to a second machine or a fresh profile and confirm the skills load and a scheduled task fires. Until you have done that once, you have a theory.
A useful way to prioritize: your skills change rarely but are irreplaceable, so commit on every change. Your work products change constantly but are already cloud-backed, so leave them alone. The entire gap lives in the first category, which is also the smallest and easiest to protect.
Why Nobody Thinks About It
The mental model is "it is just an app, my account has everything," and for a normal app that is true. An agent you have customized is closer to a small pile of shadow IT you built for yourself: real operational value, running on one machine, with no owner, no backup policy, and no test-restore ever performed.
The muscle memory from protecting servers transfers perfectly. Identify the crown jewels. Get them off the single point of failure. Prove you can bring them back. We just forgot to run the drill on the thing sitting on our own desk.