[DOCS] Inconsistent Precedence Hierarchy between Memory and Settings Documentation
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.
- In developer tooling, "Local" configurations usually override "Shared" configurations (as correctly described in the Settings documentation).
- 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.mdhas the lowest precedence and would be overridden by the sharedCLAUDE.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/memoryto 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/settingspage follows this standard, butdocs/en/memoryappears to contradict it visually in the table layout.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗