Repository navigation
Error accessing other projects #1311
Description
Version
codebase-memory-mcp 0.9.0
Platform
Windows (x64)
Install channel
npm
Binary variant
ui
What happened, and what did you expect?
Use OpenCode to connect to Codebase-Memory-MCP, perform code searches, and access incorrect projects.
Reproduction
OpenCode Output：
Now I understand the document structure. Let me check if the project is indexed in codebase-memory and start exploring the actual code files in parallel.
⚙codebase-memory-mcp_list_projects
✱Glob "/ErrorCodes.java" in .
✱Glob "/AlarmInfo.java" in .
✱Glob "/AlarmCodeInitializeAspect.java" in .
✱Glob "/PreAlarm.java" in .
✱Glob "**/alarm_after_config.yml" in .
The project D-code-HiM_SAXS_Backendefbc88TBSefbc89 is already indexed with 36,454 nodes. Now let me start reading the key source files in parallel to verify the document claims. Let me also use codebase-memory to search for the relevant code.
→Read D:\code\CBS_xps2.0_backend\common\src\main...\CommonErrorCodes.java
→Read D:\code\CBS_xps2.0_backend\common\src\main...\cbsv2\alarm\AlarmInfo.java
→Read D:\code\cbs_xd2.0_backend\common\src\main...\cbsv2\constant\InterlockErrorCode.java
Those are from other projects (CBS_xps2.0_backend, cbs_xd2.0_backend), not the target project. Let me read the actual source files from the target project D:\code\HiM_SAXS_Backend（TBS）:
→Read common\src\main...\tbs\model\ErrorCodes.java
→Read common\src\main...\tbs\alarm\AlarmInfo.java
→Read common\src\main...\tbs\alarm\AlarmCodeInitializeAspect.java
→Read app\src\main...\tbs\pre\PreAlarm.java
→Read devices\wentian\wt-config\conf\alarm\alarm_after_config.yml
Logs
Diagnostics trajectory (memory / performance / leak issues)
Project scale (if relevant)
No response
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Activity
DeusData commentedon Jul 28, 2026
Thanks for reporting this. I checked the current server contract: graph queries require an explicit project, and resolve_store has no implicit current-directory fallback (src/mcp/mcp.c:1970-1977). The later Read paths in the transcript are OpenCode operations, so the transcript alone does not show which project argument or graph rows CBM returned.
Could you share the raw MCP arguments and response for list_projects and one affected search_graph call, plus the exact intended project name? Please omit proprietary source. I marked this awaiting-reporter because that boundary is needed to distinguish a CBM project-selection bug from client-side path selection. Thank you.
github-actions commentedon Jul 28, 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.LinYunling commentedon Jul 29, 2026
I'm using OpenCode to make calls via MCP, so I'm unsure how to provide "raw MCP arguments and response for list_projects and one affected search_graph call".
DeusData commentedon Aug 3, 2026
Thank you, that is understandable. You do not need to capture raw JSON-RPC traffic from OpenCode.
Please run
codebase-memory-mcp cli list_projects, then run one direct comparison such ascodebase-memory-mcp cli search_graph --project "<intended-project>" --name-pattern ".*<non-sensitive-symbol>.*" --limit 5. Share those two outputs together with the OpenCode result for the same symbol. You can redact proprietary paths and source text; we mainly need the selected project name and whether the returned file paths belong to it. That will distinguish a CBM project-selection problem from OpenCode choosing files after the graph response.github-actions commentedon Aug 3, 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.github-actions commentedon Aug 25, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.github-actions commentedon Sep 27, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Oct 19, 2026
Thank you again for explaining the capture difficulty. The direct CLI comparison described above is sufficient; raw JSON-RPC traffic is not needed. The intended project name and redacted returned paths are still the missing discriminator between server output and client file selection.
DeusData commentedon Oct 25, 2026
Thank you again for explaining the capture difficulty. The direct CLI comparison described above is enough; the intended project and redacted returned paths remain the missing evidence.