jcode memory CLI subcommand (list/search/export/import/stats) ignores working dir, project scope always empty (regression class of #491)

Summary

jcode memory list/search/export/import/stats (the jcode memory ... CLI subcommand, src/cli/commands.rs::run_memory_command) never scopes its MemoryManager to the working directory, so project-scoped memories written by an interactive session are invisible to the CLI, even when run from the identical directory (-C is accepted but ignored for this subcommand). This is the same root-cause pattern as #491, but in a different, still-broken code path that #491's fix did not cover.

Reproduce (on v0.64.2 / master)

1. In an interactive session (TUI or agent), from directory D:

   memory { action: "remember", content: "probe-cli-bug", scope: "project" }
   

   Returns Remembered fact (project): "probe-cli-bug" [id: mem_...] and the entry is confirmed durably written to ~/.jcode/memory/projects/<hash-of-D>.json.

2. From a plain shell, same directory D, entirely separate process:

   jcode memory search "probe-cli-bug" -C D
   jcode memory list -s project -C D
   jcode memory stats -C D
   

   All three return empty (No memories found matching '...', No memories found., Project memories: 0) despite the on-disk store containing the entry.

3. Directly reading ~/.jcode/memory/projects/<hash-of-D>.json in parallel confirms the entry is present and unchanged throughout.

The same symptom also reproduces via a swarm-spawned agent (swarm spawn) sharing the identical working directory as the interactive session that wrote the memory — that path likely goes through the already-fixed MemoryTool, so it's probably a related-but-distinct gap (worth double-checking after the CLI fix, since it's harder to rule out cache/process-lifetime effects there).

Root cause

run_memory_command in src/cli/commands.rs builds an unscoped manager and never adopts the CLI's -C/--cwd (or even std::env::current_dir()):

pub fn run_memory_command(cmd: MemorySubcommand) -> Result<()> {
    use memory::{MemoryEntry, MemoryManager};

    let manager = MemoryManager::new();   // <-- project_dir: None, same defect as #491
    ...

Every match arm (List, Search, Export, Import, Stats) then calls manager.load_project_graph() / remember_project(), which resolve to None for the project path (see project_memory_path() in crates/jcode-base/src/memory.rs), so project-scoped reads/writes silently no-op or return empty — global scope is unaffected, exactly as in #491.

Confirmed via GitHub code read: no cwd/working_dir/project_dir usage anywhere in src/cli/commands.rs's memory handling; dispatch.rs::map_memory_subcommand doesn't thread a working dir through either.

Suggested fix

Mirror the fix already applied to MemoryTool::scoped_manager (crates/jcode-app-core/src/tool/memory.rs): resolve the working directory the CLI was invoked with (respecting -C/--cwd if the top-level CLI captures it, else std::env::current_dir()), and call .with_project_dir(dir) before constructing/using the MemoryManager in run_memory_command.

Environment

• macOS (aarch64), jcode v0.64.2 (6c6fbba1c), release build.
• Storage root ~/.jcode.

Related

• #491 (closed) — same defect class, fixed only for the in-agent memory tool, not the jcode memory CLI subcommand.

Start in src/cli/commands.rs::run_memory_command and trace dispatch.rs::map_memory_subcommand to see how -C/--cwd is handled. Compare the CLI manager setup with MemoryTool::scoped_manager in crates/jcode-app-core/src/tool/memory.rs and project_memory_path() in crates/jcode-base/src/memory.rs. Done means project-scoped list, search, export, import, and stats use the invoked working directory while global memory behavior remains unchanged.