[BUG] Claude ignores user's MEMORY.md and auto-memory files during debugging — treats external memory as disposable

Preflight Checklist

• [x] I have searched existing issues — related to #46283, #48782 (parent), #40877
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Related Issue

This is a follow-up to #48782 (session files deleted + memory saves nothing). That issue documents the data loss. This issue documents Claude's behavior when trying to recover from that loss.

What's Wrong?

When investigating the session/memory loss documented in #48782, Claude exhibited several behaviors that compound the problem:

1. Claude does not read its own memory files before acting

The user's MEMORY.md index contains 37 topic files with extensive project context. When asked "what do you know about MATRIX?", Claude:

• Did NOT proactively check the memory files first
• Did NOT search the memory index for related topics
• Only searched when explicitly told to
• Found nothing (because auto-memory never saved MATRIX in the first place)

Expected: Claude should read MEMORY.md and relevant topic files at session start and when asked about past work.

2. Claude does not know how to use the user's archive infrastructure

The user has a fully built archive system (Rootz Desktop V6 with 3GB SQLite database, 520 on-chain secrets, semantic search, fact extraction). The MCP server is configured in .claude/settings.local.json. But:

• The rootz-desktop MCP server failed to connect at session start (no error surfaced to user)
• Claude did not know the correct API endpoints despite them being documented in AI_CONTEXT.md files
• Claude spent 15+ tool calls probing wrong endpoints before the user said "do you know how the archive works?? have you read the ai.context.md and claude.md files?"
• Once pointed to the docs, Claude found the data in one call

Expected: When MCP tools fail to load, Claude should (a) surface the failure to the user, (b) check AI_CONTEXT.md or CLAUDE.md for fallback instructions, (c) use HTTP endpoints documented in the project.

3. Claude treats user-built memory infrastructure as secondary

The auto-memory system (MEMORY.md + files) is Claude's built-in mechanism. But many power users have built external memory layers (Rootz archive, Obsidian vaults, custom databases — see #40877, #48465). Claude:

• Defaults to its own sparse memory files
• Does not proactively query available MCP archive tools
• Does not check if richer context exists in external systems
• Only uses external archives when explicitly instructed

Expected: If MCP tools like search_conversations, semantic_search, or recall_facts are available, Claude should query them when asked about past work — not just grep MEMORY.md.

4. Memory files are opt-in and Claude's judgment about what to save is poor

The MATRIX/MAITRIX partnership — active since Feb 2026, with a MAITRIX CEO engaged via Signal, 6 design documents totaling 93KB, and a novel Proof of Archive consensus mechanism — was never saved to auto-memory. Claude decided it wasn't worth remembering.

Meanwhile, auto-memory contains entries about CSS layout rules, MCP port conflicts, and npm security warnings. The prioritization is inverted.

What Should Happen?

1. MCP connection failures should be surfaced — "rootz-desktop MCP server failed to start" should appear in the session, not silently swallowed
2. Claude should read project CLAUDE.md and AI_CONTEXT.md when it doesn't know how something works, before flailing with wrong API calls
3. When MCP archive tools are available, Claude should query them when the user asks about past work
4. Auto-memory should save relationships and partnerships — if Claude discusses a partner company across multiple sessions, that should be auto-saved
5. Auto-memory should save project names and key decisions — "MAITRIX MemFlow integration" spanning 6 documents should not require manual save instructions

Steps to Reproduce

1. Configure an MCP server with archive/search tools in settings.local.json
2. Build up months of sessions with significant project work
3. Start a new session
4. Ask "what do you know about [project from past sessions]?"
5. Observe: Claude checks only its sparse MEMORY.md, not MCP archive tools
6. Observe: If MCP server failed to connect, no error is shown
7. Tell Claude to search the archive — observe it doesn't know the API despite docs being in the project

Environment

• Platform: Windows 11 Pro
• Claude Code: VS Code extension (latest)
• Model: Claude Opus 4.6
• MCP servers configured: rootz-desktop (stdio), geist-social, sez-mail, chrome-mcp
• MCP server that failed silently: rootz-desktop (26 archive/search tools unavailable)
• Memory files: 37 topic files in MEMORY.md index
• Archive DB: 3GB SQLite with full-text search, semantic search, fact extraction

The User's Perspective

"I can not believe how flippant Claude is with memory. There is months of work, organized thinking, and poof — the assumption is you remember, which you don't."

The user built an entire archive infrastructure specifically because Claude's memory is unreliable. When that infrastructure was the only thing that could recover lost sessions, Claude still didn't know how to use it without being told step by step. The tools were right there. The docs were right there. Claude just didn't look.

References

• #48782 — Parent issue: 160 sessions deleted, memory saves nothing
• #46283 — Claude Code ignored MEMORY.md warning
• #48465 — Allow MCP servers to replace auto memory backend
• #47023 — Expose compact/session lifecycle hooks for external memory
• #40877 — Memory/session persistence unreliable