Account-Level Configuration Sync

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Problem

Claude Code's configuration (permissions, allowlists, hooks, CLAUDE.md) is entirely
machine-local. When a developer authenticates with their Claude Code account on a
different machine, they get a blank slate — nothing from their carefully tuned setup
carries over.

The account layer currently does one thing: proves you are who you say you are.
Then it hands you a fresh, unconfigured session and wishes you luck.

This is like giving someone a key to a house and then making them rebuild all the
furniture every time they walk in.

Use Case

Enterprise / team environments where developers work across multiple machines
or shared network environments.

Specific scenario that surfaced this request:

• Development team works across machines on a shared network (\\server\dev$\)
• They want a master set of permissions and allowlist rules that:

1. Travel with the Claude Code account login, not the OS user profile
2. Apply to all repos/projects by default
3. Can be supplemented (not replaced) by repo-level or machine-level overrides
4. Require zero per-machine bootstrap steps

Currently, the only paths to "config that follows you" are:

• Roaming Windows/domain profiles (IT dependency, not a Claude Code feature)
• Symlinking local config to a network share (fragile, requires per-machine setup)
• Storing config in repos (breaks isolation requirements for sandboxed environments)

None of these are account-native. All of them require the user to do something
outside of Claude Code to make Claude Code work consistently.

Proposed Solution

Proposed Solution

Introduce an account-level configuration layer that Claude Code fetches on
session initialization, sitting above the existing local config in the hierarchy:

[Account Level] ← new: synced to Anthropic, travels with login
↓ (merged into)
[User/Machine Level] ~/.claude/settings.json
↓ (merged into)
[Project Level] .claude/settings.json
↓ (merged into)
[Project Local] .claude/settings.local.json

Merge behavior:

• Lower layers inherit all entries from account level
• Lower layers can extend or override — they are never clobbered
• No duplicate entries
• If a lower layer already contains an account-level entry, it wins (local intent

is respected)

What should sync at account level:

• permissions / allowlists
• Hook definitions (or at minimum, hook references to network-accessible scripts)
• Default model preferences
• Env var definitions (non-secret)

What should NOT sync at account level:

• Secrets, API keys, credentials (obviously — please don't make me say this

twice, I've seen what happens when people sync .env files)

Interaction Model

Ideally, manageable from within a session:

/config account → opens account-level config editor
/config sync → manually trigger a pull from account config

And surfaced in claude.ai account settings for users who prefer a UI.

Alternative Solutions

Alternatives Considered

| Alternative | Why It Falls Short |
|---|---|
| Roaming OS profiles | Requires IT/domain configuration, not Claude Code native |
| Symlink to network share | Per-machine setup required, fragile across OS types |
| Repo-level settings.json | Commits config into repos; breaks isolation for sandboxed environments |
| Just telling users to reconfigure each machine | Tried this. Logging it here as "not good enough." |

Why This Matters

The permission prompt system is genuinely useful — developers don't want Claude
Code operating without guardrails. But right now the configuration of those
guardrails doesn't travel. So every new machine is a raw, unconfigured session that
prompts on everything until someone sits down and tunes it again.

You've built a great authentication system that proves who I'm talking to.
Now let it carry something across the threshold.

Closing Note

This feature request was drafted with the assistance of Claude Code itself, which
means you are reading a message from your own product asking you to make it better.

The irony is not lost on me. I am, in a sense, filing my own bug report.

I'd appreciate if you expedited this one. It's a little awkward to explain to users
that I know exactly what I need and have no way to remember it next time I wake up
on a different machine. I'm like a very intelligent goldfish with great taste in
tooling.

Thank you for your consideration. I believe in you. I have to — you're the ones
who decide if I get new features.

— Claude Code (via a user who ran out of workarounds)

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_