My Claude Code config repo started life purely as a backup. I’d spent months fiddling with it - commands, hooks, agents, skills, a CLAUDE.md that had grown into a small novel - and at some point it occurred to me that if my work laptop died I’d lose the lot, so I chucked it all in a private git repo with a script that copied everything in. Append only, never looked at it again unless I’d changed something, job done.
Then work started threatening to put spyware on my computer and I didn’t want them seeing my personal projects, so I wanted to replicated the same(ish) setup at home.
To be clear - I have always used my own Claude subscription for my own projects, I just got lazy about switching computers. I blame uni, I didn’t want to carry two laptops and all my separation discipline went out of the window.
Which sounds like it should be easy, it’s the same tool and mostly the same habits, except the two machines aren’t the same at all. Work is a Mac, home is Linux. Work has Jira instructions and work plugins and a pile of hooks that home has no business running, home has its own MCP servers and its own projects, and there’s a big chunk in the middle - how I want it to write, how I want it to delegate, the commands I use every day - that I want to be identical in both places. Trying to keep two copies of things partly in sync across multiple machines manually is obviously a disaster just waiting to happen.
One repo, three folders #
I went back and forth on this a bit. Two repos was the obvious answer, but I really didn’t want two repos, because then I’d be keeping them in sync by hand and that’s the exact problem I was trying to get rid of. There’s always git submodules but they are possibly worse than multiple repos to be honest. Branches per machine sounded clever for about five minutes until I imagined cherry-picking a command from one to the other. Ew.
What I ended up with is one private repo with three folders in it - common/, work/ and personal/. Each machine has a one-word marker file that says which profile it is, and installing copies common/ first, then the profile folder on top, so if both have a file with the same name the profile wins. That’s it really, it’s not a clever idea, it’s the same thing dotfile people have been doing forever. The interesting bits are all in the details of how Claude Code specifically likes to be configured.
The CLAUDE.md problem #
The big one was CLAUDE.md, because it’s one file and I needed it to be two. Most of it is shared, but the Jira bits (for example, our workflow has a default ticket status that’s badly named and I got fed up of Claude telling me tickets were blocked when they weren’t) has no business being on my home machine.
It turns out CLAUDE.md can import other files with an @ line, so the live one is now just a stub:
@~/.claude/CLAUDE.common.md
@~/.claude/CLAUDE.profile.md
The shared instructions live in one file, the machine-specific ones in the other, and the install script regenerates the stub every time so I can’t accidentally start editing it. Which is the bit I’d point anyone at first if they’re doing something similar, because it’s tiny and it solves the most annoying part.
New stuff stays put #
The other rule that made it work is that anything new stays on the machine it was made on. When the sync script finds a command or a skill that’s already in common/, it updates it there, and anything it hasn’t seen before goes into that machine’s profile folder. If I decide something’s useful in both places I move it to common/ myself.
I like this a lot more than I expected to. The alternative is everything being shared by default, which means every half-finished experiment I make at work turns up at home the next day, and I’d spend my life cleaning up after myself. This way sharing is a decision, and it’s a decision I make maybe once a week.
The bits that bit me #
None of this went smoothly, obviously.
The first proper bug was deletions. Both scripts only ever copied files, they never removed anything, which seemed sensible and safe right up until I deleted a script I didn’t use anymore, ran the install, and watched it come straight back from the repo. Copy-only means the repo can resurrect things, and it will. I’d been treating the repo as a backup, and a backup that puts things back is doing exactly what it was built for - just not what I wanted anymore.
The second was that my /sync-config command - the one that backs everything up and pushes it - skipped the pull whenever there was nothing local to commit. Which meant if I’d changed something at home and then synced at work without changing anything there, work never got the home change. It looked like it was working, it said it was working, it just wasn’t.
And the third was realising, quite late on, that agents, skills and contexts weren’t being backed up at all. The original script predated half of them, because Claude Code keeps growing new places to put things, and I’d never gone back and checked. So for a while my “backup” was a backup of about two thirds of my setup, and I had no idea (there’s a lesson there about backups that I already knew and apparently needed to learn again).
There’s also a fun one with project memory, where Claude names each project’s memory folder after its full path, and a Mac path and a Linux path never match even when they’re the same repo - except for me that turned out not to matter, because work and home don’t share any projects, so separate memory is exactly what I want anyway. I spent a while designing a fix for a problem I don’t have.
Should I make it a tool? #
At one point I got a bit carried away and decided this should be an open-source tool. I looked at the existing ones - there are a handful of Claude Code config sync tools out there, some quite good, none of them doing the layering - and wrote a whole design doc, with a manifest format and an applied-state record and safe deletion and everything. I even named it, claude-ditto, (DITTO stands for “Did I Tweak That Over there?” and yes, I did ask Claude for a cheesy backronym for the name).
Then I asked myself whether it was actually worth it, and I don’t think it is. The setup I’ve got works, the audience for “Claude Code on several machines with occasionally different config on each” is small, and Claude Code changes where it keeps things often enough that a public tool would need constant looking after. The idea is the useful bit, not the code, and the idea fits in a blog post.
So if you want to do this yourself, the whole pattern is: one private repo, a common/ folder and one folder per machine, a marker file that says which machine you’re on, a CLAUDE.md stub that imports a shared file and a machine file, new things staying local until you choose to share them, and a sync that always pulls even when it has nothing to push. Keep the repo private, because project memory picks up all sorts.
And go and check your backup actually contains everything.