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:

1. A private git repo holding CLAUDE.md, settings.json and hooks.
2. A split of that CLAUDE.md into 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.)

1. ~/.claude/CLAUDE.md reduced to a generated @import pointer so the only

overwritten file holds no unique content.

1. Install and sync scripts, per machine, keyed on COMPUTERNAME.
2. 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

1. 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.

1. 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.

1. 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.