Feature Request: Allow User-Level Config to Take Priority Over Project-Level Config

Background / Current Behavior

Claude Code currently follows a strict hierarchical config resolution: project-level configuration (.claude/settings.json or equivalent) always overrides user-level (global) configuration (~/.claude/settings.json). This mirrors traditional CLI tool conventions (e.g., Git's local > global precedence), which is reasonable for most developer tooling.

However, for an AI coding assistant, this model creates friction in day-to-day usage because user-level personalization directly impacts individual developer velocity — arguably more so than in conventional tools.

---

Why This Is an Issue (Use Cases for AI Assistants)

1. Custom Instructions & Personal Persona

A developer may have spent significant effort crafting a personal system prompt or set of custom instructions — tailored to their coding style, preferred verbosity, domain shortcuts, or mental model conventions. When working inside a project that defines its own (often more generic) system prompt, those personal instructions are silently overridden with no opt-out mechanism.

Example: A senior engineer has a global custom instruction that enforces concise, comment-free diffs and always asks for tradeoffs. A project config sets a bland default prompt. There is currently no way to preserve the personal prompt without modifying the project's shared config.

2. Model Selection & Personal Cost Management

A project may enforce a faster/cheaper model for the team to control shared costs or ensure predictable latency. An individual contributor may want to locally override this — using their own API tier or personal budget — to invoke a more powerful model (e.g., claude-opus-4) when debugging a particularly complex issue.

Example: A team defaults to claude-haiku-4-5 for routine tasks. A developer working on a hard architectural bug wants to temporarily use claude-opus-4-8 under their own account. There is no supported way to express this intent.

---

Proposed Solutions

Option A — CLI Flag for Config Priority

Introduce a flag to allow the user to explicitly prefer their global config over the active project config for a given invocation:

claude --prefer-user-config
claude --ignore-project-config

This is the lowest-friction solution for power users and doesn't require any changes to shared config files.

Option B — Priority Field in Global Config

Allow the global config (~/.claude/settings.json) to declare a priority that overrides project-level config for specific keys or entirely:

{
  "configPriority": "user",
  "model": "claude-opus-4-8",
  "customInstructions": "..."
}

This enables a persistent "always prefer my settings" mode without needing a flag on every invocation.

Option C — Per-Key Override Support (Fine-Grained)

Allow the user to mark individual keys in their global config as non-overridable by project config:

{
  "model": { "value": "claude-opus-4-8", "priority": "user" },
  "customInstructions": { "value": "...", "priority": "user" }
}

This gives the most flexibility — the project can control shared settings (e.g., allowed tools, safety guardrails) while the user retains control over personal preferences.

---

Additional Context

• This is particularly relevant as Claude Code is increasingly adopted in team/enterprise settings where project configs are committed to version control, making them effectively immutable for individual contributors.
• Options A and B are additive — neither breaks existing behavior. Option A could ship quickly as an experimental flag.
• Guardrails (e.g., security policies, allowed tools) should arguably retain project-level supremacy even if this feature is implemented — the proposal is scoped to personalization settings (model, instructions, output style, API settings).

---

Suggested priority: Medium — low implementation risk, high DX impact for power users in team environments.