Memory Search Inconsistency : Hooks vs Manual Storage Creating Split Memory Experience

[cheonmux]

Environment

• System: M1 MacBook
• Claude Code: Latest version
• MCP Memory Service: sqlite_vec backend
• Installation: Following official documentation

Configuration

MCP Server Configuration (.mcp file)

  {
    "mcpServers": {
      "memory": {
        "command": "/opt/homebrew/bin/uv",
        "args": ["--directory", "/Users/seo/Downloads/mcp/mcp-memory-service", "run", "memory"],
        "env": {
          "MCP_MEMORY_STORAGE_BACKEND": "sqlite_vec",
          "MCP_MEMORY_SQLITE_PRAGMAS": "busy_timeout=15000,cache_size=20000",
          "LOG_LEVEL": "INFO"
        }
      }
    }
  }

API Server

  Running with: MCP_HTTPS_ENABLED=true python run_server.py
  INFO:__main__:Starting MCP Memory Service FastAPI server with the following configuration:
  INFO:__main__:  Storage Backend: sqlite_vec
  INFO:__main__:  HTTPS Port: 8443
  INFO:__main__:  API Key Set: No

Hooks Installation

  Memory Awareness Hooks appear to be working correctly based on session startup:

  🧠 Memory Hook → Initializing session awareness...
  📂 Project Detector → Analyzing sage-test
  💾 Storage → 🪶 sqlite-vec (Connected) • 400 memories • 2.52MB
  📍 Path → ...ry/Application Support/mcp-memory/sqlite_vec.db
  ✅ Memory Hook → Context injected (8 memories)

Problem Description

Despite successful installation and apparent proper functioning, I'm experiencing inconsistent memory
search results that suggest two separate memory systems are operating simultaneously:

Issue 1: Time-Based Search Inconsistency

When I request "recent memories", I get different results depending on the search method:

• mcp__memory__retrieve_memory("recent") → Returns semantic matches, not chronological
• mcp__memory__recall_memory("last 2 memories") → Returns only hook-generated memories with
  timestamps
• Manual searches by tag → Returns manually stored memories without timestamps

Issue 2: Memory Storage Bifurcation

I notice two distinct memory storage patterns:

Hook-Generated Memories:

• Have timestamps (e.g., "Timestamp: 2025-09-02 06:29:57")
• Tagged with claude-code-session, session-consolidation
• Discoverable via time-based searches
• Auto-generated content format

Manual/Command Memories:

• No timestamps
• Custom tags
• Only discoverable via tag-based searches
• User-created content

Issue 3: Search Method Dependencies

Different search functions return completely different memory sets from what appears to be the same
database:

• Time-based searches only find hook memories
• Tag-based searches find manual memories
• Content searches seem to prioritize one type over another

Questions

1. Is this the intended behavior? Should Memory Awareness Hooks and manual storage create different
   metadata structures?
2. Should all memories have timestamps? It seems counterintuitive that manually stored memories are
   excluded from time-based searches.
3. Are multiple systems supposed to run simultaneously? I have:
   - Memory Awareness Hooks (auto session management)
   - MCP Memory Server (manual tools)
   - HTTPS API Server (backend)
4. Is there a unified approach to ensure all memories are equally searchable regardless of how they
   were created?

Thank you for your time and for creating such a comprehensive memory system!

[doobidoo]

Excellent Investigation! 🎯

@cheonmux - This is outstanding analytical work! Your findings have revealed a legitimate architectural inconsistency that definitely warrants attention.

What You Have Uncovered

Your investigation has identified a real "split memory experience" problem:

• Hook-generated memories get consistent timestamps and ["claude-code", "auto-generated"] tags automatically
• Manual memories may lack proper timestamp handling and consistent metadata structure
• This creates discoverability issues where time-based searches only find certain memory types

Validation from Code Analysis

I have confirmed your findings by examining the hooks code:

// From /claude-hooks/config.json
"defaultTags": ["claude-code", "auto-generated"]

The hooks automatically apply structured metadata that manual storage may not consistently follow.

Next Steps

I have created Issue #99 to track this as a high-priority bug, including:

• Investigation tasks to identify the root cause
• Proposed solutions for standardizing metadata across storage methods
• Plans to unify search functionality

Kudos 👏

Your systematic approach to documenting the differences between search methods and identifying the metadata inconsistencies shows excellent troubleshooting skills. This kind of detailed analysis is incredibly valuable for improving the memory service architecture.

Thank you for taking the time to thoroughly investigate and document this issue!