Two git repos isn't env parity

Anthropic's Claude Code still lacks account-level settings sync, leaving cloud sessions without a user's house rules, permission defaults, and memory server, according to developer PrashamTrivedi. The feature request, GitHub issue #22648 "Account-level settings sync across devices," has been open since February 3 with 47 reactions and 25 comments and no ship, while roughly 84 repositories exist for "claude code dotfiles sync" and about 81 for "claude code settings sync." Trivedi, who built his own sync tools claudeSettings and CursorPlugin, reports that six feature branches on his blog came from agents he was not sitting in front of, four of them merged, going back to November 2025.

Two git repos isn't env parity Table of contents My first serious session with Claude Code on the web went badly, and not for any of the reasons I had prepared for. I walked in smug, because I had already done the work to sync Claude Code config across machines. I opened it against a repo I have lived in for a year. The agent was competent. It read the code, it made sensible suggestions, it did not invent a single file path. It also knew none of my house rules. /codePlanner was not there. My permission defaults were not there, so it stopped to ask me about things I had stopped being asked about months ago. The memory server was not connected. It was Threepio after the memory wipe. Same protocol droid, same competence, no idea who any of us were. The part that stung was the smugness. I own a public repo built for exactly this, and it had contributed nothing. Why I am in that session at all Worth answering before the rest of this matters, because the answer is not convenience. The laptop is one machine. It runs one agent I am actually watching, and my attention is the bottleneck . Cloud sessions are the only way I have found to keep four jobs moving at once without four local terminals contending for the same checkout. I can start all four, go to sleep or go for a walk or drive home, and come back to finished work I never had to step into. The constraint I am buying my way out of is throughput, not geography. Geography is real too. Back when I had a day job, the machine with my home directory on it was not in front of me for a good part of the week. That habit outlived the job. The hours when I most want to start something, read the diff on a phone, and decide whether it is worth opening the laptop that evening are still the hours when I am nowhere near the laptop. None of this is hypothetical. Six feature branches on this blog came from an agent I was not sitting in front of, four of them merged, going back to November 2025. One of them shipped the public face of the site. One of them drafted an earlier version of the post you are reading, which is a sentence I am still deciding how to feel about. An unfurnished session is not a curiosity for me. It is where a growing share of the work happens. Everybody builds this repo Search for how to sync Claude Code config across machines and you will not find a shortage of answers. As I write this, GitHub returns about 84 repositories for claude code dotfiles sync , and about 81 for claude code settings sync . Symlink kits. Bun scripts. Encrypted vaults for the tokens. At least four independent projects literally named claude-code-dotfiles , plus claude-config-sync , plus a healthy crop of blog posts walking you through building your own. None of that is a criticism. Fork one or write your own over a weekend, either is reasonable, and between two laptops they do the job. What matters is where they all stop. Anthropic knows the hole is there. The feature request, 22648, “Account-level settings sync across devices” https://github.com/anthropics/claude-code/issues/22648 , has been open since the third of February. Forty-seven reactions, twenty-five comments, no ship. And yes, I built one too. claudeSettings https://github.com/PrashamTrivedi/claudeSettings is public. It has a sync.ts that copies configuration between a central home directory, the settings repo, and a project tree, in either direction, and it does that job correctly. I was somewhere around number 84. Then I did it again. When I started living in Cursor as well, I hit the identically shaped hole and reached for the identically shaped answer: CursorPlugin https://github.com/PrashamTrivedi/CursorPlugin , its own sync.ts , its own central-and-project directions. Two agents, two home directories, two of my own repos, same instinct twice. If the pattern were going to work, it would have worked the second time, when I already knew what I was building. When the session opened cold, my first instinct was not that my approach was wrong. It was that something was broken. What “sync Claude Code config across machines” actually has to move It helps to count what is actually in the folder we keep calling a dotfile. Here is what ~/.claude holds on my laptop as I write this, in September 2026: 46 skills, 11 agents, 24 slash commands, 2 output styles, 5 globally registered MCP servers, 57 tracked projects, and a settings.json that has grown to 21,978 bytes. That is not a dotfile. .vimrc was a dotfile. This has a plugin system, a permission model, a memory layer, and a set of running servers it expects to reach. We inherited the word “sync” from an era when the payload was a few hundred lines of preferences. The payload changed. The word did not. Anthropic’s own table says no The cloud environments documentation https://code.claude.com/docs/en/cloud-environments has a table titled “what carries over from your setup,” and it does not hedge. Your repo’s .claude/skills/ , .claude/agents/ , .claude/commands/ : yes, those come along, because they are part of the clone. Then the other column. Your user ~/.claude/skills/ , ~/.claude/agents/ , ~/.claude/commands/ : No. The docs are not subtle about why. “Live on your machine, not in the repo.” Your user ~/.claude/CLAUDE.md : no. Plugins you enabled in user settings: no. MCP servers you added with claude mcp add at the default local scope or the user scope: no, because those write to ~/.claude.json on your machine. Even session hooks get a warning: “If you have SessionStart hooks in your user-level ~/.claude/settings.json , don’t expect them in the cloud.” One line from the settings page https://code.claude.com/docs/en/settings deserves to be pinned to the wall: ~/.claude/settings.json applies to “every project on your machine, and nothing on your teammate’s or in the cloud session.” One honest exception, which I am not going to bury. Cloud sessions do automatically load skills you enable on claude.ai. That is a real channel and it works. It also covers exactly one row of that table, and it is not your git repo. The agents, the commands, the user-level memory, the plugins, and the MCP wiring are all still standing on a laptop that is not running. Cursor built the same partial door, which is what convinced me this is structural rather than one vendor’s oversight. Turn on the setting called Sync Skills for Cloud Agents and, per the docs https://cursor.com/docs/skills , “Cursor copies the contents of ~/.cursor/skills/ ” so Cloud Agents can reach them. Useful. Cursor then scopes it down in the very next line: “Only ~/.cursor/skills/ syncs. Project skills, ~/.agents/skills/ , and other files on your machine stay local.” Two independent vendors, both looking at the same hole, both shipping a door exactly one directory wide, both picking skills as the directory worth carrying. That is not laziness. It is what happens when the honest answer to “bring my whole environment” is hard enough that everyone ships the tractable slice first. Plugins are the closest thing to an official answer, and they stop at the same boundary too. A plugin bundles skills, agents, commands, hooks, and MCP servers into one installable unit, which is a real improvement on a hand-rolled sync script. Declaring one in the repo’s committed settings is the documented way to get it into a cloud session, and it carries an asterisk. When the plugin comes from a GitHub repository or an npm package, which is where most of them come from, the settings reference says https://code.claude.com/docs/en/settings-reference enabledplugins Claude Code “reports the plugin as not installed until each user installs it themselves.” Somebody still runs the install. Anthropic is building toward paths that remove that somebody and I expect them to land, but today the format designed to move your setup onto other people’s machines does not, on its own, move it onto yours. So the second repo can be perfect. Green CI, freshly pushed, pulled ten seconds ago. The cloud session still starts with none of it. Two reasons the repo alone cannot close this Start with the word everyone skips. An environment is not a folder of settings. It is the whole machine state your agent wakes up inside: the files on disk, the tools on PATH , the credentials, the services it can reach. A repo is a folder. Both reasons below fall out of that mismatch. A git repo does not pull itself. A pull is a two-repository operation, and a cloud session only ever clones one of them, your project. The second one, the repo holding your config, shows up only if something explicitly goes and fetches it. To be fair to both products, that hook exists. Claude Code on the web and Cursor each give you somewhere to put a command that runs before the agent starts, and that command can absolutely clone a second repo and lay it down. The capability is not what is missing. What is missing is a person. Someone has to decide to use that hook, environment by environment, and someone has to write the thing that runs. Look at what a sync repo quietly assumes. I wrote it. I maintain it. I run it by hand, on a machine I am sitting at. When it copies the wrong thing, or copies nothing, I notice in the same minute and fix it. The script was never the whole system. I was the other half of it, and I was dependable because I was standing there. A cloud session removes that half on purpose. I opened it to start the work and go do something else. Checking that my config landed is the exact attention I was trying not to spend. The thing that made machine-to-machine sync trustworthy, a person reading the result and correcting it on the spot, is the thing these environments exist to take off my plate. The first evidence that nobody wired it up is the agent stopping to ask for a permission you granted six months ago. The second reason is the one I have not seen anybody say, and it is the one that actually changed my mind. The schema moves underneath the snapshot. My claudeSettings repo carries agents, commands, hook scripts, and an mcp.json . It carries zero skills. Not because I deleted them. Because Agent Skills shipped in October 2025, and my last commit to that repo is dated the twenty-first of September, 2025. The sync tool predates the artifact that now dominates my setup by a matter of weeks. A sync repo freezes your config as it looked on the day you wrote the script. When the config gains a new kind of artifact, the script keeps copying the old list and reports success. Mine still copies a 3,598 byte settings.json that the live one outgrew by 18 kilobytes. That is not neglect. The script is doing exactly what I told it to do, against a description that expired. I had already written the conclusion down. It sits in CursorPlugin ’s README, in my own words: “Cloud Agents still clone project git, not your laptop ~/.cursor .” I documented the exact reason the repo could not do the job, in the repo, and kept building on the repo anyway. I called a related problem agent config debt https://prashamhtrivedi.in/agent-config-technical-debt/ . That post was about configuration that rots in place. This is configuration that never arrives, which is harder to catch, because rot at least leaves evidence. Why this lives in a home directory at all Fair challenge to raise here. If committed project config is the part that survives the clone, why not keep everything there and stop complaining? Because the repo’s .claude/ already has a job, and it is not this one. It should hold what is true about the project: the build command, the test conventions, the architectural notes a newcomer needs. I commit those, and I would argue for committing them. What does not belong there is what is true about me. /codePlanner describes how I break work down. It is not a fact about this blog, or about any Worker I have deployed. Put it in a repo and you have written your own habits into a shared space, next to your permission defaults, your model preferences, and the list of MCP servers you happen to run. Two people on one repo want different answers to all of that. One person on one repo wants a different answer next year. The arithmetic does not work either. Fifty-seven projects on this laptop, one of me. Config that is keyed to the person, stored keyed to the project, has to fan out every single time the person changes their mind. A monorepo makes that arithmetic disappear by making the number of projects one, and I understand the appeal. It is still the wrong trade. My Cloudflare Workers share architecture patterns with each other. That is not a reason for them to share a repository. A monorepo is for code that is genuinely one product. It is not for separate products that happen to be built the same way. The four ways not to fix it The market offers four ways around the hole. I weighed all of them, and each one buys the same thing: permission to stop thinking about the problem. Keep the workflows on the laptop only. The cloud agent becomes autocomplete, and the real work waits for the machine that has your home directory. The cost: every job except the one you are watching runs without your guardrails, and the unwatched jobs are the ones that need them most. Stop working away from the desk. No kickoff from the phone, nothing started in the morning to review that evening. The cost: a home directory gets a veto over which hours you are allowed to ship in. Commit the shared config into every repo. The documentation recommends exactly this, and it does work. I built the tooling for it myself. ./sync.ts Cursor To Project vendors skills, rules, and commands straight into $PWD/.cursor . The cost: the skill you fixed on Tuesday is correct in four repos and wrong in sixteen, and the permission rule you tightened after an incident exists only in the projects you happened to touch that week. You wanted one source of truth. You now maintain twenty, with no replication protocol except your own memory. Buy a machine and leave it running. A box that never sleeps holds a populated home directory and authenticated MCP servers. Remote into it and you have your environment back. The cost: rent, patching, and the fact that it does not actually work. Claude Code on the web will not read that box’s ~/.claude at any uptime. You have bought hardware to solve the laptop-to-laptop problem that git had already solved. None of the four is parity. Each is a way of not naming the job. The job has a different name Sync is the wrong word, and picking it is what made the second git repo feel like an answer. Sync assumes two peers that both hold state and need to agree. That describes two laptops. It does not describe a machine that was created for one task and will be destroyed when that task ends. What a cloud session actually is: an ephemeral clone, plus whatever runs at birth. That is all of it. Everything you want that box to know has to arrive through the one door that opens when it boots. Which means the job is not sync. It is reconstruction. And reconstruction is a thing you write down and execute, not a remote you add. 1 fn:1 I have a mechanism for this now, it works, and it has receipts. That is Part 2, Install scripts beat always-on machines , landing next week. This post is the diagnosis. The next one is the fix, and the commit history that proves it. Keep the second git repo. It does the job it was built for, and it does that job well. The job was never parity. May the force be with you… 1. If you are already ahead of me and thinking “so run a setup script,” yes. That is the answer, and it is more interesting than it sounds, because the interesting question is not that you run one but what it is allowed to reach for when it does. Next week. ↩︎ fnref:1