My Claude Code setup: one chezmoi source for every machine
Chezmoi gives every machine the same Claude Code settings, skills and statusline, and my agents can update the config themselves.
All of it is worth showing, but the chezmoi piece is the base. Every machine gets the same Claude settings, skills and statusline, and my live choices don’t get reverted.
The Claude settings file is a chezmoi modify_ script instead of a plain template. That way chezmoi only patches the keys it owns in settings.json and leaves hooks and plugins to their own installers. The model and effort level get seeded only if they’re missing. (That rule came from a bug: every apply used to revert a mid-session /model switch to the template default, now my pick survives the next apply.) The bigger picture is chezmoi one source of truth for every dotfile.
My claude.md file has references to how to edit this and how to push to git so my agents know how to update configs and render diffs and applies when I ask of it.
When I want to change the Claude config, it’s usually just a request in an already-open session. The agent edits the chezmoi source, shows me the diff, and applies & pushes after I read it. All my non-plugin skills live in the same repo, so any new skill I add gets instantly available on every machine the next time I apply.
Most of my skills come from Uberpowers, which is a fork of superpowers by obra, via pcvelz’s fork. It’s where I keep the working loop that turns an idea into brainstorming, into a spec, into a plan.. all before writing a single line of code. In May I broke syncing with upstream permanently because I have my own roadmap, but the foundation is still there.
Sessions got heavy, and the number one thing on my list was finding the source of the context bloat. I had the agent measure every block it was injecting over 30 days of session logs. Turns out I was loading about 15,000 tokens of stuff before I’d even typed a word, and most of those blocks weren’t earning their place. The model wasn’t actually using hardly any of it. I cut the per-turn injections, removed a lookup hook that was searching memory on every prompt, and killed nine skills the model had never once used.
I decided full context was more important than token savings, so I kept one block intact: the per-project carry block from Memento. It tells a new session where the last one left off, with no size limit. I also kept the hooks that push prompts to my phone, but that’s a whole other post (see My whole dev setup fits in my pocket).
I told the agent “Think outside the box, you’ve concluded too quickly” the day my clicks died in Claude Code inside tmux on my home server, but on my laptop with the same settings, it worked. Turns out: I had a mouse setting sitting idle in my dotfiles for 2 months, the flag only exists from Claude Code v2.1.195+, and my home server had updated past it, activating the setting silently. Never thought a no-op setting could bite me later.
The agent’s first theories were wrong, but it wanted to save one to memory before it was proven. I told it “stop saving it to memory, I am not ready to conclude that yet.” A simple diff of the Claude environment variables across the two machines revealed the flag. Setting it to 0 brought back clicks. The missing version note is tracked in issue #71687.
In every session I have a statusline from cship which reads the data Claude Code passes to a statusline and shows me how full the context window is, how close I am to usage limits, etc. My fork adds the weekly Fable limit which Claude Code doesn’t pass, so my fork queries the usage endpoint.
The usage call had another surprise in store for me: I had many sessions open, and they were all retrying the endpoint every 30 seconds after it failed, which in turn meant they were collectively keeping the account throttled. So now my fork backs off for five minutes after a failure. This only surfaced because I was running many sessions at once, which brings me to the next part: Running six to nine Claude Code sessions at once.