Expose named sections of the core system prompt for opt-in user override

Proposal

Let advanced users opt in to excluding specific sections of the core Claude Code system prompt, gated by an explicit acknowledgment. The preset stays intact by default; users who understand the tradeoffs can tune it at their own responsibility.

Concrete schema (v1)

// ~/.claude/settings.json
{
  "experimental": {
    "systemPromptOverrides": {
      "acknowledged": true,
      "exclude": ["output-efficiency", "plan-mode-framing"]
    }
  }
}

• Published section names, documented as unstable across minor versions.
• Unknown section names → warning at startup, not silent no-op.
• acknowledged: false or missing → feature off, no effect on anyone.
• On enable, first session prints: Core prompt overrides active — behavior may deviate from defaults.

replace (swap a section for user-provided text) is deliberately left for a later phase. It introduces file-resolution and injection concerns that are worth addressing separately; exclude alone covers the main need expressed in the symptom reports.

Rationale

Users who read prompt leaks, hit conflicts between the preset and their CLAUDE.md, and tune skills already know what they are doing. Letting them remove directives that conflict with their setup produces more efficient use of Claude for their workflow, not less.

Common users are unaffected by design: they don't read settings.json, don't know the section names, and don't enable experimental flags. Defaults stay optimized for them. This is a release valve for the top of the distribution, not a change to the baseline product.

Why an acknowledgment, not just a flag

The acknowledged: true field is the mechanism that makes this safe to ship.

Some sections of the preset exist for real reasons — alignment, safety, consistency across users. Disabling them carelessly can produce genuinely problematic behavior. At the same time, users who have read the preset, hit the reports below, and written their own CLAUDE.md already understand these tradeoffs.

Treat the acknowledgment as a trust contract: the user states they understand they are trading defaults for control, accepts responsibility for the result, and loses the right to file bugs caused by their own overrides. Anthropic gets a clear signal of who is in expert mode and a clean path to expose power that today lives behind private flags and SDK escape hatches.

This is the pattern used by git push --force-with-lease, browser devtools "I accept the risk", and most serious developer tools: ship unsafe power behind an explicit, documented opt-in.

Safety whitelist

Not all sections should be overridable. Sections covering alignment, refusal behavior, or handling of dangerous requests should be on a non-overridable list. The feature lists which section names are eligible; anything else is rejected even with acknowledged: true.

Eligible categories (initial suggestion): tone, output formatting, efficiency directives, plan-mode framing, verbosity, summary behavior.

Non-eligible: anything governing model refusals, safety-critical behavior, or legally required disclosures.

Edge cases considered

• Section name stability. Names may change across minor versions. Unknown names in user config produce a startup warning, not a silent no-op. A changelog entry for section renames is expected.
• Conditional sections. Sections like plan-mode-framing are only active in their mode. exclude removes them globally wherever they would otherwise be injected — clearly documented.
• Inter-section dependencies. If a section references another that has been excluded, the reference is stripped together. Verified at build time, not runtime.
• Cache interaction. The override set becomes part of the prompt cache key. Changing the config invalidates cache on the next run. Stable configs keep caching behavior.
• Team / Enterprise. Admin policy can disable the feature globally or require specific excludes. Out of scope for v1 but architected so it can be added without breaking individual configs.

Why not simpler alternatives

"Just make CLAUDE.md take precedence over preset directives." This would resolve roughly five of the related symptom reports (#32508, #38491, #38938, #39583, #48902 — all complaints about CLAUDE.md being ignored). It is strictly smaller in scope and worth doing on its own merits.

It does not cover the other two (#43352, #44648), which describe structural conflicts that CLAUDE.md cannot express even with higher precedence — the preset itself authorizes behavior the user does not want, regardless of their own content.

Both fixes are compatible. Precedence is the lighter fix that helps the common case; section-level override is the escape hatch for the cases precedence cannot express.

"Use --append-system-prompt or --system-prompt-file." Append cannot remove. Full replacement loses every benefit the preset provides. Neither addresses the reports.

Infrastructure already present

--exclude-dynamic-system-prompt-sections (PR #46024, currently open) shows the code already treats the system prompt as composable named sections. Its current scope is cache optimization for print mode; the same mechanism can power section-level overrides with minimal new plumbing.

Related symptom reports

Seven open issues report different concrete symptoms of the same structural problem: #32508, #38491, #38938, #39583, #43352, #44648, #48902. Each asks for a specific fix. A combination of CLAUDE.md-precedence and section-level override would let their authors — and users who hit other variants — opt out without per-case triage.