Cannot seem to start the MCP server in multiple tools

[aolin480]

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

[aolin480]

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

[aolin480]

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.

[PatrickSys]

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!

[aolin480]

@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!

[aolin480]

@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!

[PatrickSys]

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!

[aolin480]

@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!

[aolin480]

@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

[aolin480]

@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

[PatrickSys]

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!

[aolin480]

@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 😬

[PatrickSys]

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!

[aolin480]

@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!

[aolin480]

@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!

[aolin480]

@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!