Account-level sync for user config and auto memory
Environment: Windows 11 Pro 26200, Claude Code 2.1.233 (native) and 2.1.229
(MSIX desktop app), Max plan. Two machines, one user, one login.
Summary
Everything that defines how Claude Code works for a user is stored as local
files. Nothing follows the login. A second machine starts with a completely
blank Claude: no standing rules, no accumulated memory, no settings.
The docs state this as the design position, for auto memory:
Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments.
What follows the login today, and what does not
| Follows the login | Stays on one machine |
|---|---|
| claude.ai conversations and project memory | ~/.claude/CLAUDE.md |
| Remote Control session registration | ~/.claude/settings.json |
| Authentication | Auto memory (~/.claude/projects/<project>/memory/) |
| | Hooks, and anything they load |
The only things that travel are the ones already hosted on Anthropic's side.
Why this is the wrong default
The product's entire value is accumulated context and configuration. That is
precisely the part that does not follow the account.
For comparison: Interactive Brokers — a brokerage, not a software company —
stores Trader Workstation's settings, including custom hotkeys, against the
login. Signing in on any machine brings the configuration with it. A trading
platform solved this; a configuration-and-context tool has not.
What users are forced to build instead
Over one evening, to get a second machine to behave like the first:
- A private git repo holding
CLAUDE.md,settings.jsonand hooks. - A split of that
CLAUDE.mdinto shared rules and per-machine facts, because
the naive whole-file copy destroys one machine's paths and state on every
sync cycle. (32 KB on one machine, 3.5 KB on the other; whichever synced last
won.)
~/.claude/CLAUDE.mdreduced to a generated@importpointer so the only
overwritten file holds no unique content.
- Install and sync scripts, per machine, keyed on
COMPUTERNAME. - For memory specifically: Windows directory junctions from every project
key to one canonical store, because memory is keyed on project path and each
new folder starts empty. Later replaced by autoMemoryDirectory.
None of that is domain work. It is all reimplementation of "my account knows my
preferences".
The half-step that already exists
autoMemoryDirectory is settable from any settings scope and relocates the
memory store to an arbitrary path. So the storage location is already treated as
a user-facing decision — it just stops short of the useful destination.
Requested
- Opt-in account-level sync for
~/.claude/CLAUDE.md,~/.claude/settings.json
and the auto-memory directory, so signing in on a new machine restores the
user's configuration and accumulated memory.
- If full sync is out of scope, a supported sync path — a documented
mechanism and a conflict story for concurrent sessions on two machines, which
plain git does not provide for markdown memory files.
- Failing both, say so in the docs where users will hit it, alongside the
autoMemoryDirectory documentation, so the first discovery is not a second
machine behaving like a fresh install.
Related
Installer and claude doctor defects previously reported as
anthropics/claude-code#86999.
3 Comments
Reported on a paid Max subscription against generally-available Claude Code 2.1.233, not a preview or beta build.
The second machine case is what convinced me this is not a sync problem. Syncing files gets you the standing rules. It does not get you what the first machine learned while working, because that never became a file in the first place.
What worked for us was moving the memory off the disk entirely: each session writes a closed decision out as it closes, with an author and a date, and any machine reads the same store. The new laptop is not blank because there was never a local copy to be missing.
If all you need is the standing rules following you around, a synced dotfile repo is cheaper and does that fine.
@r44dazza-dev I couldn't find another way to reach you, so I hope it's okay to leave this here. I'm doing some research for a school project on what happens to people's AI work once it has to live in more than one place, and the evening you spent building a config repo, sync scripts and directory junctions caught my attention. What I'm trying to understand is what was behind needing the second machine in the first place, and whether it stayed just yours. If you'd be up for a short call, around 15 minutes, I'm at oluwaniifemi.emmanuel@uni.minerva.edu. If a reply is easier, I'd mostly like to know why the work needed to run on that second machine, and whether anyone else has ended up using or seeing what you build across them. Thank you.