trace_path returns empty trace for client-side functions calling third-party member expressions (v0.9.0)

[arhamrizvi]

Summary

trace_path returns an empty trace (no hops) for client-side Next.js/React functions whose downstream calls are third-party member expressions (e.g. supabase.auth.signInWithPassword(...)). Both calls and cross_service modes return only the header object with no path data.

Environment

• codebase-memory-mcp v0.9.0, Windows 11 (win32), invoked via cli and via MCP stdio
• Indexed project: Next.js 15 / TypeScript app, 12,318 nodes / 24,151 edges (CALLS: 3,277)

Repro

1. Index a Next.js repo containing a client component like:

   async function handleSubmit(e) {
     const supabase = createBrowserClient(...);
     await supabase.auth.signInWithPassword({ email, password });
   }

2. Run:

   codebase-memory-mcp cli trace_path --function-name "<project>.src.app.auth.login.page.handleSubmit" --project <project> --direction downstream --depth 3
   

Actual

{"function":"...handleSubmit","direction":"downstream"}

No hops, no empty-array fields, no diagnostic. Same result with --mode cross_service --depth 4.

Expected

Either resolved hops for member-expression calls into imported client objects, or an explicit empty result ("hops": []) plus a hint (e.g. "no CALLS edges recorded for this node") so agents can distinguish "no callees" from "resolution gap".

Notes / related minor issues

• Ambiguity handling in trace_path is excellent (5 handleSubmit matches -> suggestions list). The gap is only edge resolution for third-party member calls.
• search_graph name matching also surfaces markdown Section nodes (433 matches for pattern "GET", mostly from docs .md files) — a --labels filter default excluding Sections would reduce noise for agents.
• Minor: first index_repository run crashed one worker (exit code 1) and succeeded on retry; log hinted at a deprecated cli index_repository invocation registered by the installer's own hook.

Happy to provide logs or run debug builds.