Live · filed from a working practice automationdiary.com
RSS feed 11 · 07 · 2026

What a rm -rf taught me about my Claude Code setup

I deleted my entire Claude Code setup with one command. The rebuild turned into an audit — and a public template of what actually survived.

Three days ago I typed rm -rf ~/.claude into my terminal, deliberately, because I thought I was clearing out cache. I was not clearing out cache. I was deleting my entire Claude Code operating layer — the global configuration file, roughly sixty accumulated memory files, four custom agents, every slash command I’d built, and a hook that filed sessions into my notes automatically. Months of accumulated operating knowledge, gone in the time it takes to press enter.

I want to be precise about what that sentence means, because “operating knowledge” sounds abstract until you’ve actually lost it. This wasn’t a folder of documents. It was the accumulated shape of how I’d taught a tool to work the way I work — which tasks get routed where, what my recurring mistakes are, what a good answer looks like for the kinds of questions I ask every week. None of that is in any model weights. All of it was in that directory. And I had never once backed it up.

Here’s the part of the story that actually matters, though, and it isn’t the deletion. It’s what survived it.

The layer that saved me was the boring one

Two things kept me from losing everything outright. First, I had a Claude Code session still open in another window, and that session had loaded my memory index into its context before the deletion happened — so the one-line summaries of those sixty memory files were sitting in a conversation transcript even after the files themselves were gone. Second, and more importantly: the durable knowledge those memory files pointed to had never actually lived in ~/.claude at all. It lived in a plain-markdown notes vault. The configuration directory was just a pointer, an index, a convenience layer sitting on top of the real thing.

So the clever part of my setup — the memory files, the custom agents, the slash commands, all of it engineered specifically for this tool — died instantly and completely. The dumb part — plain text files in folders, no proprietary format, no dependency on any particular piece of software still existing — didn’t even notice. I could have deleted ~/.claude from orbit and the vault would have been sitting there Tuesday morning, unbothered.

That’s the asymmetry I keep turning over. Most people who build any kind of AI workflow — custom instructions, memory systems, agent configs, whatever the tool of the month calls it — version their code obsessively and never once think to version the layer that tells the AI how to behave. We’ve internalized “back up your code” as a reflex. Nobody has internalized “back up your AI’s operating layer” yet, because the tooling is new enough that it doesn’t feel like infrastructure. It feels like settings. You don’t back up settings.

Except this wasn’t settings. It was the compounding output of every session where I’d corrected the tool, taught it a preference, or written down a rule so I wouldn’t have to repeat myself. Settings are static. This was accreted. And accreted things are exactly the things you regret not versioning, because you can’t regenerate them from a spec — you’d have to relive every correction that produced them.

A catastrophic deletion is the best audit you’ll ever get for free

The other thing I didn’t expect: rebuilding forced me to look at what I’d actually built, instead of what I assumed I’d built. Silent accumulation hides rot. A crash makes you read every line.

The restored global config file went from 8.5KB to 6.5KB, and I didn’t lose a single rule in the process — I just cut the padding around the rules that were doing real work. That file matters more than its size suggests, because it isn’t loaded once. It ships with every single session I run. Every extra sentence in it is a tax paid on every conversation, forever, whether that session needs the rule or not. Bloat in a file like that isn’t a one-time cost you notice and fix. It’s a recurring charge you never see on any bill, because token overhead doesn’t show up as a line item — it shows up as slightly worse, slightly slower answers, compounding invisibly across hundreds of sessions until you finally sit down and read the whole file end to end, which is exactly what losing it forced me to do.

The skills turned up their own rot. Three of them referenced slash commands that no longer existed — dead links I had apparently been carrying around silently for who knows how long, never noticed because a skill with a broken reference doesn’t throw an error, it just quietly underperforms. And four agents named directly in my configuration didn’t exist as files anywhere on disk. Not “hard to find.” Not present. Referenced with total confidence, invoked by name, and absent — and nothing had ever complained, because nothing in the system was checking.

None of that would have surfaced on its own. I wasn’t going to audit a working setup. Working things don’t get audited; they get left alone until they break, and by the time they break you’ve usually forgotten there was anything to check. The deletion did the audit for me, at the worst possible time, which is the only time an audit like that actually happens.

What I rebuilt, and why each piece is honest rather than clever

I didn’t rebuild the same thing. I rebuilt three specific protections, each aimed at a specific failure mode from the incident itself.

The first is boring in the best way: the whole configuration directory is now version-controlled, using a detached git directory — a three-line wrapper script that runs git --git-dir=~/.claude/config.git --work-tree=~/.claude instead of a normal .git folder sitting inside the directory. That distinction matters more than it sounds like it should. A normal .git folder inside ~/.claude risks getting picked up as a project repo by other tooling, or worse, getting nested inside some other repo’s ignore rules and silently skipped. The detached git dir keeps the config folder looking, to everything else, like an ordinary folder — while still being fully tracked. It’s mirrored to a private GitHub repo as well. The entire value of this is that an rm -rf now costs one git clone instead of costing months. I didn’t build anything sophisticated. I built the equivalent of a seatbelt.

The second is a budget dispatch tree living inside the global config itself: hard routing rules that send coding tasks to a cheap coding CLI, research questions to a grounded search tool, and long drafts to free-tier models — reserving the paid Claude plan specifically for orchestration and the reasoning that’s actually hard. Alongside it, every response now ends with a model attribution footer naming exactly which model did which part of the work, including a self-reported flag on the rare occasion the paid model did something the routing rules said should’ve been offloaded. The point isn’t the savings, though there are savings. The point is that cost discipline stops being something you infer from a monthly billing dashboard three weeks after the fact, and becomes something legible in every single reply, in real time, where you can actually catch drift before it compounds.

The third is a SessionEnd hook that files any substantive session — five messages or more — into the vault automatically: a one-line log entry plus a dated note, summarized by a free-tier model, checked against manual write-ups so nothing gets duplicated, and written defensively enough that it can never block or crash the session on exit. This is the one I care about most, honestly, because it closes the actual loop from the failure. The knowledge base feeds itself now. Forgetting to write things down stops being a failure mode, because the system no longer depends on me remembering to.

The repo, if you want the actual files

I sanitized the whole rebuilt system and put it up publicly: claude-code-os. It’s the CLAUDE.md template, eight skills — several built on Matt Pocock’s MIT-licensed skill work, credited in the repo — the four model-routed agents, the SessionEnd hook, and the detached-git-dir wrapper script. Not a product. A record of what I rebuilt after three days of finding out, the expensive way, which parts of my setup were load-bearing and which were decoration.

If any of this sounds familiar — a config directory you’ve never once versioned, agents or commands you half-remember writing and haven’t checked on in months — you probably have the same gap I had, and you probably won’t find it until something forces the audit. You don’t need the crash to do the audit. You can just go read the claude-code-os repo and steal the parts that fix the gap you already have.

Companion template · from this article

The Prospect Intake + Tension Brief

The exact Obsidian template and the full prompt chain — the structured intake note, the contrast prompt, and the provocation checklist. Drop it into your vault and run your next prospect through it in forty minutes.

$29 Coming soon
Disclosure: Some links on this site are affiliate links — if you buy through them I may earn a commission, at no cost to you. I only recommend tools I actually run, and I tell you when something I tried didn't make the cut. That's the whole promise here.

One real workflow, in your inbox, when it's ready.

No schedule. No filler. No sponsored placements. A new build goes out only when it's worth your ten minutes — usually every 2–4 weeks.

"I'll only send you something I would have written even if nobody paid me to. The day that stops, the newsletter stops."

Cadence Only when a build is worth your ten minutes
NewJust launched
2–4 wkBetween issues
0Sponsored ever