Repository navigation
linked_projects stays empty until cross-repo-intelligence is run, and ["*"] is rejected #2133
Description
Severity: medium — partly a docs issue.
linked_projects is [] for every freshly indexed project, which reads as "no
cross-repo links exist" rather than "this mode has not been run". When run, the
documented wildcard fails:
target_projects: ["*"] → "cross-repo source or target project is missing, invalid, or not indexed"
target_projects: ["proj_a","proj_b"] → works
The tool description states Use ["*"] for all indexed projects.
Separately, the matches it produced were low-value: a frontend's client-side
router paths (e.g. /dashboard in a React route table) were matched against
backend Route nodes, while the actual REST calls the frontend makes were not
matched at all.
Ask: fix or document the wildcard; distinguish client-side route strings from
HTTP call sites when matching.
Observed on v0.10.8 (build 996bad5fe6fb), macOS arm64, Python monorepo (~36k nodes / ~179k edges). Happy to provide a minimal reproduction repo if useful.
Activity
DeusData commentedon Sep 25, 2026
Thank you so much for this report, @avigdorsky, and for the careful before/after comparison of
["*"]against named targets. It pointed straight at the cause.The wildcard was documented correctly but broken by old data. If your cache held any project indexed before a July schema change (the IMPORTS local-name discriminator, #768),
["*"]picked that store up and then failed when it tried to open it for writing. The whole run aborted with the generic "missing, invalid, or not indexed" error, after it had already cleared the source's previous cross-repo edges. Naming your live projects avoided that store, which is why it worked.The fix is up as #2343:
["*"]now skips such stores (with a log line naming them), and an explicitly named legacy store is rejected up front, before anything is deleted. Until the release is out, re-indexing the older projects or removing their stale indexes also unblocks the wildcard.On
linked_projects: it is filled only from cross-repo edges, which the opt-incross-repo-intelligencemode creates, so it is empty until that mode has run. We agree "not run yet" should look different from "no links" and are discussing how best to show that. The client-side router versus REST-call matching point is tracked separately; a minimal repro repo for that part would be very welcome.Merge pull request #2343 from DeusData/fix/issue-2133
fix(cross-repo): a pre-DeusData#768 store no longer aborts ["*"] or w…
DeusData commentedon Sep 30, 2026
Thank you again, @avigdorsky! #2343 is now merged to
mainas 6746f43 and covers part of this issue. We're keeping the issue open for the remaining work and will post here as it lands.feat(cross-repo): report run status and skipped legacy stores (#2133)
test(cross-repo): free every matcher result the tests receive
Merge pull request #2346 from DeusData/feat/cross-repo-status
DeusData commentedon Oct 7, 2026
#2346 is now merged to
mainas 1b581f1 and will ship in the next release.index_statusand the UI now say whether cross-repo intelligence has never run for a project or ran and found no links (cross_repo: {"status": "never_run"}vs{"status": "ran", ...}), so an emptylinked_projectsis no longer ambiguous. A["*"]run now names every pre-#768 store it had to skip, with a reindex hint, instead of only logging it. Thanks again, @avigdorsky!DeusData commentedon Oct 19, 2026
Thank you again for separating wildcard handling, never-run status, and router matching. The thread records partial fixes for the first two; I have no new verified status for the remaining client-router/REST matching case. A public minimal example for that distinct part is still useful if available.
DeusData commentedon Oct 25, 2026
Thank you again for separating the cases. The thread records fixes for wildcard handling and never-run status; a small public example of the remaining client-router versus REST-call matching case would still help with that distinct issue.
github-actions commentedon Oct 25, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.