Cannot seem to start the MCP server in multiple tools

I am getting errors when trying to start the codebase-context MCP server in either Warp, Codex, or Opencode. In Warp, I am getting the following error:

2025-12-29 22:22:44.581 | [note] Attention! There may be sensitive information (such as API keys) in these logs. Make sure to redact any secrets before sharing with others.
2025-12-29 22:22:44.581 | [info] MCP: Using stdio transport
2025-12-29 22:22:44.584 | [info] MCP: Sending request: {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"dev.warp.Warp-Stable","version":"v0.2025.12.17.17.17.stable_02"}}}
2025-12-29 22:22:45.592 | [info] MCP [pid: 24761] stderr: Registered analyzer: angular (priority: 100)

2025-12-29 22:22:45.592 | [info] MCP [pid: 24761] stderr: Registered analyzer: angular (priority: 100)
Registered analyzer: generic (priority: 10)

2025-12-29 22:22:45.599 | [error] MCP: Failed to connect to server: Client initialization error: connection closed: initialize response

Also, I tried running the npx command as a standalone command, and currently getting this in the stderr.log

npx -y codebase-context-mcp 1>stdout.log 2>stderr.log

Error:

npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/codebase-context-mcp - Not found
npm error 404
npm error 404  The requested resource 'codebase-context-mcp@*' could not be found or you do not have permission to access it.
npm error 404
npm error 404 Note that you can also install from a
npm error 404 tarball, folder, http url, or git url.
npm error A complete log of this run can be found in: /Users/aaronolin/.npm/_logs/2025-12-30T04_26_22_583Z-debug-0.log

I also tried using the github repo for the package, and I don't get any errors, but the MCP server is still giving me errors:

Warp MCP config:

{
  "codebase-context": {
    "args": [
      "-y",
      "github:PatrickSys/codebase-context",
      "/Users/username/code"
    ],
    "command": "npx",
    "env": {},
    "start_on_launch": true,
    "working_directory": null
  }
}

Error:

2025-12-29 22:31:36.225 | [note] Attention! There may be sensitive information (such as API keys) in these logs. Make sure to redact any secrets before sharing with others.
2025-12-29 22:31:36.225 | [info] MCP: Using stdio transport
2025-12-29 22:31:36.228 | [info] MCP: Sending request: {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"dev.warp.Warp-Stable","version":"v0.2025.12.17.17.17.stable_02"}}}
2025-12-29 22:31:37.265 | [info] MCP [pid: 28263] stderr: Registered analyzer: angular (priority: 100)

2025-12-29 22:31:37.266 | [info] MCP [pid: 28263] stderr: Registered analyzer: angular (priority: 100)
Registered analyzer: generic (priority: 10)

2025-12-29 22:31:37.272 | [error] MCP: Failed to connect to server: Client initialization error: connection closed: initialize response

I put the command in MCPJam, and getting the same kind of error too 🤔

So I think I see this issue. When I run the npx command, this is being output and causing the errors:

Registered analyzer: angular (priority: 100)
Registered analyzer: generic (priority: 10)

I added code to silence those, and everything is working great now.

@aolin480

Hi @aolin480 ,

I learned that while this was working in Cursor, VSCode, and my Codex CLI version (from a few weeks ago), it wasn't working in stricter MCP clients. This is fixed in v1.2.2 and already published. Thank you for the detailed report.

Regarding your (now closed) PR #3 :

I did a deep dive into the code. The React/Next.js AST parsing logic is excellent and exactly the kind of framework awareness we need.

However, I noticed the EcosystemAnalyzer orchestrator overrides the AnalyzerRegistry's standard resolution logic and overall functionality. For v1.2+, I need to enforce a single registry pattern so that the Governance Engine (which handles legacy/rising patterns and trends) has a unified view of all analyzers.

I would like to integrate the React/Next.js support into the core, wiring it directly through the standard AnalyzerRegistry.register() flow. The key insight from your fork was that detectMetadata() was only calling the first, highest priority analyzer (hence I assume why you built the EcosystemAnalyzer) helped me identify and fix the root cause properly by ensuring all analyzers contribute to the metadata.

I'll credit you as co-author in the commit for React/Next.js support. Let me know if you'd like to contribute directly to the integration, or I can proceed with the current plan.

Thank you for the heavy lifting on the React ecosystem!

@PatrickSys

@PatrickSys Thanks for replying back. To be honest, I accidentally created that PR on your repo 😅. I forked the Codebase Context repo, and made some changes so I can start testing it on my projects first, to see how everything is working. So please disregard, although if you want to take something from there, by all means, go ahead. I was working on my own branch in the forked repo, and I just merged the changes into the master branch in the forked repo (https://github.com/aolin480/codebase-context-react-nextjs).

My ultimate goal was to test this first, and see how it's doing, and then possibly hit you up and let you know that I have something there, knowing there may be some rework, but in the forked version, I added things like Zod, React Hook Form, etc. Just some popular frameworks to check the codebase against, since that's what I use in some of my projects.

Thank you!

@PatrickSys

@PatrickSys i am working on tearing out the ecosystem detection. Once I am done with that, I'll let you know if you want to review everything.

Thanks!

@aolin480

Hey @aolin480, no worries on the accidental PR, happens to the best of us!

I've looked into your fork and seen how you handled the workspace/multi-framework support and what was lacking on the current architecture as I was currently focused building for the Angular analyzer.

I’ve just created the PR #4 for v1.3.0 which fixes the analyzer registry bug and adds the workspace detection utilities.

I'm going to hold off on implementing the React/Next.js parsers on my end for a bit. Since you've already done the heavy lifting there, I don't want to step on your toes or cause merge conflicts if you decide to upstream your version later.

That's totally up to you, if you want to send a PR, the core is ready for it. If you prefer to stick to your fork, that's cool too! Just let me know so I know whether to wait or eventually tackle it myself.

Thanks again for the catch on the bug and your work!

@PatrickSys

@PatrickSys Sounds good. Yeah, let me keep this how it is right now on my end, and again, I want to test it out for a week or so, and then I can get it cleaned up, and then just pull down your current version, and implement it cleanly, and then create a PR for it. I don't need to include the smoke tests or anything in that version.

Thanks!

@PatrickSys

@PatrickSys I rebased my fork on top of your branch, and got the README.md back to the original version, but added MCPCONFIG.md as well as documentation for the smoke tests for React/NextJS if you want to check it out. Structurally, it should be on parity with your latest release, plus the new ReactJS and NextJS analyzers.

If you have any questions, just let me know -> https://github.com/aolin480/codebase-context-react-nextjs

@PatrickSys

@PatrickSys I actually added a pretty neat feature to my version. I work in a rather large NX monorepo, and what I am seeing is that tools like indexing, and search_codebase were timing out during my requests. I added this PreWarm feature so that when the agent loads in the MCP config for codebase context, it prewarms the model first, so that when the agent needs to use it, the index is ready, and we won't get any timeouts. Just wondering your thoughts on this?

Again, our NX monorepo is rather large, so I think this is a pretty nice improvement -> aolin480@09a9b66

@aolin480

Hey @aolin480

Thank you for the rebase and expanding the mcp configuration docs for different clients - for me in the README.md it was also fine.

I've looked into the last updates and the PreWarm makes fully sense on larger monorepos. Good catch!
As for the React/NextJS analyzers, the mplementation looks solid and it is well covered by tests!

I've got a quick question on the parseJsonInWorker for loading the index - did you actually run into blocking with large files or is that more of a defensive thing?

Looks ready to go if you still want to PR it. Let me know when you're ready and I'll review.

Thanks again for the all the contributions!

@PatrickSys

@PatrickSys Awesome thanks!

About the parseJsonInWorker, my .codebase-index.json file is ~35MB, and when the analyzers were calling JSON.parse() directly during metadata detection, it was blocking the main event loop long enough to contribute to timeout issues. Moving the parse to a worker thread keeps the server responsive while handling those larger index files. The 20MB threshold check is there to skip the stats loading entirely for really large codebases, but for files under that limit, the worker approach prevents the synchronous parse from stalling other operations.

I am going to try to increase that threshold to 40MB, and test things this week. I think it's a very rare occurrence that the .codebase-index.json would be over 20MB, so for most cases, the skipping of this metadata wouldn't happen, but we want to make sure for larger .codebase-index.json that we're not going to have the MCP server timeout.

I will play around with a slightly larger threshold and see if I have any issues though, and I can keep you updated.

I think the codebase I am working with day to day is a great test for the Codebase Context MCP server 😬

@aolin480

Thanks for the explanation @aolin480 - that makes sense.

I've only tested with smaller sized Nx Monorepos which had <5MB index, so I haven't run into this. 35MB sounds like stress testing the MCP (I bet that initial indexing gives you enough time to grab a coffee) and definitely justifies moving the parsing off the main thread.

For me there's no need to spend time testing threshold values - including the worker implementation in the PR is good. Looking forward to it!

@PatrickSys

@PatrickSys So small update. The react and next rules are doing great. I actually updated my AGENTS.md a couple of days ago, and added some more support for NX monorepo's as far as instructions, and the NX mcp server I installed was taking precedence over codebase context, and I definitely noticed and I swapped the rules so that codebase-context runs before the NX MCP rules, and it definitely made a difference. Everything has been running great though with my current version.

I will try to rebase any changes you made onto my branch, and try to get everything in sync with what you have done, and maybe we can finally get a PR up for ReactJS/NextJS.

Just wanted to provide you an update.

Thanks!

@PatrickSys

@PatrickSys 👋🏽 I know it's been a while. I just rebased my changes on top of your upstream master branch. Going to run my build for a few days to see how everything is working. Remove my index and recreate it, etc. Hopefully we can get this merged in soon, but I am really loving this with my NX/NextJS/ReactJS projects!

@PatrickSys

@PatrickSys Also. I have a pain point with this MCP server right now. I can't just define one codebase-context mcp server in my mcp config. For multiple projects, I have to specify mcp_servers.project1-codebase-context, mcp_servers.project2-codebase-context. I have to do this because using something like Codex desktop, which has multiple projects now, when the codebase-context mcp tool is loaded, we're freezing the directory with the cwd command in the codebase-context codebase, and in Codex Desktop, this is actually represented as / all of the time, and it's not even relative to the current project I am working in.

I toyed around with some other code index mcp servers, and you just define a single mcp config, and you don't have to provide any directories, and the mcp code is actually intelligently finding the root of the project, and then pulling in the index file or index config, and then it just works.

I am adding something to my version that involved a root-resolution, and this will intelligently look for certain "project markers" (like .codebase-context), and then it knows where the index is, and should load it in.

const STRONG_PROJECT_MARKERS = ['.codebase-context', '.git', 'nx.json', 'pnpm-workspace.yaml'];

You can still provide a hardcoded path as well, so I am not totally removing that.

I am going to mess around with this as well to see what the results are. I'll keep you updated.

UPDATE ::
OMG! This is working perfectly! I am going to continue testing it, but I think for some of the tools, we're also going to have to add something like project_directory that is an optional parameter, just in case you're running this MCP server in something like MCPJam, so you can debug certain projects. THIS IS AMAZING!

@PatrickSys

@PatrickSys Another update. I tried going the route of dynamically getting the index of the project, but it was very challenging without refactoring a lot, so I am going to leave that bit for now, and I reverted what I've done 😬 Trying to do this intelligently seemed to be more work than just defining it, which is fine. Concentration on this feature has ceased.

@aolin480

Hey @aolin480, I'm glad to hear the rebase went smoothly. Take your time in testing, when you're happy with it feel free to send the PR.

As for the multiple project support that's definitely a real pain point right now. Even if you reverted the root-resolution approach, the problem still needs to be fixed. I've opened a dedicated issue for that in #63 to avoid it blocking the React/Next.js PR. I will try to work today on that.

Thank you for your time into investigating the issue!

@aolin480

Hey @aolin480. The PR #67 (fix/issue-63-multi-project-routing) addresses the core pain points you raised here:

One MCP server per repo → Fixed. A single server now handles multiple projects via workspace-aware routing. No need for separate mcpServers entries per repo.
Codex Desktop cwd is / → Fixed. In MCP mode the server no longer falls back to cwd. It either resolves from client-announced MCP rootsor asks you to specify project.
Walk-up detection with project markers → Built into project-discovery.ts. The server walks up from a file or subdirectory path to find the nearest project boundary (package.json, .git, etc.).
project_directory as optional parameter → All 10 tools accept both project and project_directory as an optional selector. Pass an absolute path, a relative subpath, or even a file path and the server resolves the right project.
Worker thread + PreWarm → Not in scope for this PR, but the deferred-indexing model means roots are registered without blocking on index builds.

To test with the branch build:

git clone https://github.com/PatrickSys/codebase-context.git
cd codebase-context
git checkout fix/issue-63-multi-project-routing
pnpm install && pnpm build

This will be released in 1.9.0

Then point your MCP client config at the local build (see README for the node command format).

This doesn't fully close #2 as there's still room for improvements like worker-thread isolation and smarter pre-warming. But it eliminates the architectural blocker that forced one server process per repo.

@PatrickSys

@PatrickSys This is amazing news! I will check it out to see how you did it. Fantastic!

feat: add react and nextjs analyzers

@aolin480

Closing the loop here: the React/Next.js analyzer work has now landed via #87. Thanks again @aolin480 for the original investigation, the fork work, and the repeated real-world testing on larger Nx/Next/React repos. That work clearly helped shape the final integration.

I’m going to close this issue for hygiene since the main thread here has been resolved and upstreamed.

I’m not treating prewarm as part of this issue, but I also don’t want to throw it away. If it still shows clear value on large monorepos after the current routing/indexing changes, it can come back as its own focused follow-up with evidence behind it.

Closing as resolved.

@PatrickSys

@PatrickSys Thank you! I apologize for the radio silence on this, but I am glad you were able to get this merged in. I am going to fire up your repo version now for a new project.

Thank you!

Navigation Menu

Repository navigation

Cannot seem to start the MCP server in multiple tools #2

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Cannot seem to start the MCP server in multiple tools #2

Description

Activity

aolin480 commented on Dec 30, 2025

aolin480 commented on Dec 30, 2025

PatrickSys commented on Dec 31, 2025

aolin480 commented on Dec 31, 2025

aolin480 commented on Jan 1, 2026

PatrickSys commented on Jan 1, 2026

aolin480 commented on Jan 1, 2026

aolin480 commented on Jan 7, 2026

aolin480 commented on Jan 9, 2026

PatrickSys commented on Jan 9, 2026

aolin480 commented on Jan 12, 2026

PatrickSys commented on Jan 12, 2026

aolin480 commented on Jan 27, 2026

aolin480 commented on Mar 1, 2026

aolin480 commented on Mar 1, 2026

aolin480 commented on Mar 2, 2026

PatrickSys commented on Mar 6, 2026

PatrickSys commented on Mar 11, 2026

aolin480 commented on Mar 12, 2026

PatrickSys commented on Apr 3, 2026

PatrickSys commented on Apr 3, 2026

aolin480 commented on May 31, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions