[DOCS] Inconsistent Precedence Hierarchy between Memory and Settings Documentation

Resolved 💬 3 comments Opened Jan 18, 2026 by coygeek Closed Feb 28, 2026

Documentation Type

Unclear/confusing documentation

Documentation Location

Section/Topic

  • docs/en/memory: The "Determine memory type" section and table. - docs/en/settings: The "Settings precedence" section.

Current Documentation

In Settings (docs/en/settings), the precedence list places Local settings above Shared Project settings:

"Settings apply in order of precedence. From highest to lowest: [...] 3. Local project settings (.claude/settings.local.json) [...] 4. Shared project settings (.claude/settings.json)"

In Memory (docs/en/memory), the text states:

"Files higher in the hierarchy take precedence and are loaded first."

However, the accompanying table lists "Project memory" (Shared) near the top, and "Project memory (local)" (CLAUDE.local.md) at the very bottom.

What's Wrong or Missing?

There is a logical inconsistency in how "Local" vs. "Shared" precedence is described between the two features.

  1. In developer tooling, "Local" configurations usually override "Shared" configurations (as correctly described in the Settings documentation).
  2. However, the Memory documentation table places "Project memory (local)" at the bottom. Combined with the sentence "Files higher in the hierarchy take precedence," this implies that CLAUDE.local.md has the lowest precedence and would be overridden by the shared CLAUDE.md.

It is unclear if this is a documentation error (the table order is inverted regarding precedence) or if Memory genuinely behaves differently than Settings (loading foundational/shared context first and treating it as authoritative).

Suggested Improvement

The Memory documentation should be clarified to match the logic of the Settings documentation, or explicitly call out the difference in behavior.

If Local Memory is intended to override Shared Memory:

  • Reorder the table in docs/en/memory to place "Project memory (local)" higher than "Project memory," to indicate it takes precedence.
  • OR, clarify that "Precedence" in the context of Memory means "Overrides previous instructions" and ensure the list reflects the order in which the LLM processes them (usually specific/local overrides general/shared).

If Shared Memory is intended to override Local Memory:

  • Explicitly state that unlike Settings, Memory prioritizes Shared Project instructions over Local instructions.

Impact

High - Prevents users from using a feature

Additional Context

  • In standard configuration management (e.g., gitignore, npm config, VS Code settings), local user settings generally override workspace/project settings. The current docs/en/settings page follows this standard, but docs/en/memory appears to contradict it visually in the table layout.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗