[FEATURE] Memory system biases toward saving even when user prefers file-based persistence

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 auto-memory system pushes hard toward creating memory entries for any durable learning (corrections, preferences, rules). In projects where a file-based persistence layer already exists — runbooks, task files, guides, CLAUDE.md — this creates friction:

1. Claude defaults to writing a memory file even when the current working context is a file where the learning naturally belongs.
2. A rule like "prefer files over memory" stored in memory is self-contradictory — it's the very mechanism it's trying to deprioritize.
3. The rule gets applied inconsistently. Claude saves a memory first, the user corrects, Claude deletes it and updates the file. Every session repeats this dance.
4. Memory is local-only, so it silently diverges across machines. Users with multi-machine setups get inconsistent behavior depending on which box they're working from.

Proposed Solution

1. Context-aware routing. If there's an open task/runbook/guide in the conversation, that should be the default target for learnings — memory only when no such file is present or relevant.
2. Project opt-out. A CLAUDE.md directive like memory: files-first or memory: disabled that actually suppresses the pull toward memory, not just adds another memory rule that has to win every time.
3. Treat "rule in memory" as an anti-pattern. Rules that override the memory system shouldn't live in memory — surface them at the CLAUDE.md level instead.

Alternative Solutions

Currently the only workaround is to add a memory entry that says "prefer guides over memory." This is self-contradictory (memory telling Claude not to use memory) and has to win every time against the default bias. It doesn't work reliably.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. User has a well-structured project with runbooks and guides.
2. While executing a runbook, a mistake is made.
3. User corrects Claude.
4. Claude saves the correction as a memory entry — even though the runbook being executed is the natural home for it.
5. User has to tell Claude to delete the memory and update the runbook instead.
6. Next session, without the memory, Claude repeats the original mistake before the runbook update is noticed.

Additional Context

• Affects users with well-structured documentation repos.
• Memory being local-only compounds the problem: rules stored there don't reach other machines or collaborators.
• Claude Code version: 2.1.114