Project-scoped memories saved to .llxprt/LLXPRT.md are not loaded by memory discovery

[acoliver]

Summary

When using save_memory with scope: 'project', memories are saved to ./.llxprt/LLXPRT.md, but the memory discovery system's upward scan does not look for files in .llxprt/ subdirectories, causing project-scoped memories to not be loaded.

Root Cause

Where save_memory writes (project scope):

In packages/core/src/tools/memoryTool.ts line 120-122:

function getProjectMemoryFilePath(workingDir: string): string {
  return path.join(workingDir, LLXPRT_CONFIG_DIR, getCurrentLlxprtMdFilename());
}
// Results in: ./.llxprt/LLXPRT.md

Where memory discovery looks:

In packages/core/src/utils/memoryDiscovery.ts:

1. Global path (lines 150-154) - checks ~/.llxprt/LLXPRT.md ✓

2. Upward scan (line 192):

const potentialPath = path.join(currentDir, geminiMdFilename);

This looks for ./LLXPRT.md, ../LLXPRT.md, etc. - NOT ./.llxprt/LLXPRT.md

3. Downward BFS search (lines 215-221) - searches subdirectories, might find .llxprt/LLXPRT.md but is unreliable

The Mismatch

The upward scan looks for LLXPRT.md directly in directories, not inside .llxprt/ subdirectories. But save_memory with project scope saves to .llxprt/LLXPRT.md.

The only way project-scoped memories get found is via the BFS downward search, which might fail if:

1. .llxprt directory is being ignored (by .gitignore or .llxprtignore)
2. The maxDirs limit is reached before scanning .llxprt/
3. The search starts from a subdirectory

Expected Behavior

Project-scoped memories saved to ./.llxprt/LLXPRT.md should be reliably loaded when the CLI starts.

Suggested Fix

The upward scan should also check for LLXPRT.md inside .llxprt/ directories:

// In addition to checking path.join(currentDir, geminiMdFilename)
// Also check:
const llxprtDirPath = path.join(currentDir, GEMINI_DIR, geminiMdFilename);
try {
  await fs.access(llxprtDirPath, fsSync.constants.R_OK);
  if (llxprtDirPath !== globalMemoryPath) {
    upwardPaths.unshift(llxprtDirPath);
  }
} catch {
  // Not found, continue.
}

Affected Files

• packages/core/src/utils/memoryDiscovery.ts (lines 186-208)
• packages/core/src/tools/memoryTool.ts (lines 120-122)

Reproduction

1. Run save_memory with a fact using scope: 'project'
2. Verify the file is created at ./.llxprt/LLXPRT.md
3. Restart the CLI
4. The saved memory is not loaded into context

[acoliver]

@CodeRabbit look into this

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the memoryTool.ts file to see where project-scoped memories are saved
cat packages/core/src/tools/memoryTool.ts

Length of output: 14560

---

🏁 Script executed:

#!/bin/bash
# Read the memoryDiscovery.ts file to see how memories are discovered
cat packages/core/src/utils/memoryDiscovery.ts

Length of output: 13054

---

🏁 Script executed:

#!/bin/bash
# Search for LLXPRT_CONFIG_DIR and GEMINI_DIR constants to understand directory naming
rg -n "LLXPRT_CONFIG_DIR|GEMINI_DIR" --type=ts

Length of output: 2386

---

@acoliver I've analyzed the issue and can confirm this is a valid bug. Here's what I found:

Confirmed Issue

Where project-scoped memories are saved:
In packages/core/src/tools/memoryTool.ts (lines 120-122):

function getProjectMemoryFilePath(workingDir: string): string {
  return path.join(workingDir, LLXPRT_CONFIG_DIR, getCurrentLlxprtMdFilename());
}
// LLXPRT_CONFIG_DIR = '.llxprt' (line 75)
// Results in: ./.llxprt/LLXPRT.md

Where memory discovery looks:

1. ✅ Global path (lines 150-154): Correctly checks ~/.llxprt/LLXPRT.md

2. ❌ Upward scan (lines 186-200): Only checks for files directly in directories:

const potentialPath = path.join(currentDir, geminiMdFilename);
// This looks for ./LLXPRT.md, ../LLXPRT.md, etc.
// Does NOT check ./.llxprt/LLXPRT.md

3. ⚠️ Downward BFS (lines 213-221): Might find .llxprt/LLXPRT.md but is unreliable (subject to maxDirs limit, filtering, and search order)

The Problem

The upward scan treats the global path as a special case (checking inside ~/.llxprt/), but doesn't apply the same logic to project-level directories. This creates a mismatch where:

• Write path: ./.llxprt/LLXPRT.md (project scope)
• Read path: ./LLXPRT.md (upward scan looks here instead)

Recommended Fix

In packages/core/src/utils/memoryDiscovery.ts, modify the upward scan loop (around lines 186-200) to also check inside .llxprt/ subdirectories:

while (currentDir && currentDir !== path.dirname(currentDir)) {
  if (currentDir === path.join(resolvedHome, GEMINI_DIR)) {
    break;
  }

  // Check for file directly in directory
  const potentialPath = path.join(currentDir, geminiMdFilename);
  try {
    await fs.access(potentialPath, fsSync.constants.R_OK);
    if (potentialPath !== globalMemoryPath) {
      upwardPaths.unshift(potentialPath);
    }
  } catch {
    // Not found, continue.
  }

  // NEW: Also check inside .llxprt/ subdirectory
  const llxprtDirPath = path.join(currentDir, GEMINI_DIR, geminiMdFilename);
  try {
    await fs.access(llxprtDirPath, fsSync.constants.R_OK);
    if (llxprtDirPath !== globalMemoryPath) {
      upwardPaths.unshift(llxprtDirPath);
    }
  } catch {
    // Not found, continue.
  }

  if (currentDir === ultimateStopDir) {
    break;
  }

  currentDir = path.dirname(currentDir);
}

This ensures project-scoped memories are reliably discovered during the upward scan, matching the behavior of the global memory path.