claude-code - 💡(How to fix) Fix [FEATURE] Allow MCP servers to replace auto memory backend [2 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Auto memory instructions live in the system prompt. MCP server instructions have lower priority. Agent follows system prompt, ignores MCP memory tools.

Users must choose:

• Auto memory on: MCP memory tools unused
• autoMemoryEnabled: false: no context at session start
• CLAUDE.md overrides: system prompt still wins

Every MCP memory server hits this. Related: #41283, #46050, #41473.

What happens today

1. User installs a memory MCP server alongside Claude Code
2. Auto memory instructions (in the system prompt) tell the agent to use Write/Edit on MEMORY.md
3. MCP server instructions (lower priority) tell the agent to use memory_store/memory_search
4. Agent follows the system prompt. MCP memory tools go unused.
5. User adds "use rekal, not auto memory" to CLAUDE.md. Helps sometimes, ignored other times.
6. User sets autoMemoryEnabled: false. No memory loads at session start. Cold starts every time.

There is no winning configuration. Either auto memory competes with the MCP server, or the user loses context injection at session start.

Proposed Solution

A setting that delegates memory to an MCP server:

{ "memoryProvider": "mcp:rekal" }

When set:

1. Session start: call MCP tool, inject result where MEMORY.md content goes
2. Replace auto memory prompt with MCP server's instructions at same priority
3. Built-in auto memory stays default when unset

Smaller alternative:

{ "autoMemoryStartupTool": "mcp__rekal__memory_build_context" }

Call one MCP tool at session start, inject result, suppress auto memory write instructions. One branch in the memory orchestrator.

Alternative Solutions

Tried, all break:

• CLAUDE.md "don't use auto memory": system prompt priority wins
• autoMemoryEnabled: false: no context injection at session start
• Hooks injecting additionalContext (memora's approach): fragile across versions
• autoMemoryDirectory redirect: format mismatch, write conflicts

Priority

Low - Nice to have

Feature Category

MCP server integration

Use Case Example

I maintain rekal, an MCP memory server with hybrid search (FTS5 + vector + recency).

Step 1: Start Claude Code in a project with rekal configured as MCP server. Step 2: Agent begins work. It should call memory_build_context to load relevant cross-session knowledge. Instead it reads MEMORY.md because the system prompt says to. Step 3: Agent discovers a non-obvious debugging insight. It should call memory_store with deduplication. Instead it writes to MEMORY.md because the system prompt says to. Step 4: Next session. Agent needs to recall that insight. It should call memory_search. Instead it reads the flat file. No search, no ranking.

With memoryProvider set:

• Step 2 calls the MCP tool, result injected at session start automatically
• Step 3 calls memory_store, deduplicates against existing knowledge
• Step 4 calls memory_search with hybrid ranking across all past sessions

Same UX as auto memory. Better backend. No conflicting instructions.

Additional Context

• rekal: MCP memory server with hybrid search (FTS5 + vector + recency)
• memora: MCP memory server with knowledge graphs (uses hooks as workaround)
• The memory orchestrator already branches on autoMemoryEnabled. A memoryProvider branch before existing logic is a contained change.
• autoMemoryDirectory already redirects storage path; this extends it to storage mechanism.
• Fixes the problem for every MCP memory server at once.