# Reported issues for jCodemunch MCP

Pod holds 23 of 221 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [jCodemunch MCP](/mcp/jcodemunch-mcp).

## Most discussed

### Windows watcher incremental reindex is ~10s while MCP index_file takes ~0.2s

## Description

On Windows, the filesystem watcher (`jcodemunch-mcp watch-all` or `jcodemunch-mcp watch`) detects a modified file immediately, but updating the jCodeMunch index after a single-file change takes around 10 seconds.

Calling the `index_file` MCP tool directly for the exact same file completes in approximately **0.2 seconds**.

This seems to indicate that the bottleneck is somewhere in the watcher → incremental indexing path rather than in parsing/indexing the changed file itself.

#

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/557) · 2026-08-28 · open · external user · 12 comments

### Add an adaptive, generation-safe data path for large repositories

JCodeMunch currently pays two related large-repository costs in several paths:

1. A tool can hydrate the complete code index even when it needs only a symbol, file,
   or small candidate set.
2. Semantic tools can load and score the complete embedding collection through Python
   objects even when a smaller fetch or a packed, vectorized pass would be sufficient.

The strongest design I found is one adaptive pipeline, not one global cache and not
NumPy everywhere. Each request should read only w

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/398) · 2026-08-01 · closed · outside contributor · 9 comments

### BUG: get_file_outline()

Hi,

This is not a proper bug report, I will update it at a later time.
For me (probable config dependent) i get a lot of: "The outline came back empty" messages from the models (Claude, GPT etc).

Like this.

```
"jcm- get_file_outline (PRJ)(repo: "local/PRJ-acfbc7e7", file_paths:
  ["tools/Labels/AppLabels.py","appGUI/NewEmailWidget.py","tools/MessageViewer.py"])
  ⎿  #MUNCH/1 tool=get_file_outline enc=fo1

     repo=local/PRJ-acfbc7e7 __tables="s:symbols:id|name|kind|signature|line|end_line|p

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/319) · 2026-05-29 · closed · outside contributor · 6 comments

### PyPI install unavailable — install via git+https or the GitHub-release wheel

This was working until today. Both pip and uvx can't find the library now
```bash
❯ uvx jcodemunch-mcp config --check
  × No solution found when resolving tool dependencies:
  ╰─▶ Because there are no versions of jcodemunch-mcp and you require jcodemunch-mcp, we can conclude that your requirements are unsatisfiable.

❯ python -m pip install jcodemunch-mcp==1.108.20
ERROR: Could not find a version that satisfies the requirement jcodemunch-mcp==1.108.20 (from versions: none)

❯ python -m pip insta

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/308) · 2026-05-19 · closed · external user · 24 comments

### Config file ".jcodemunch.jsonc" is ignored in project

## Steps to reproduce:

( system: Ubuntu )

1. Create file ".jcodemunch.jsonc" in project root with content like this:

```
{
    "extra_ignore_patterns": ["docs/legacy/"]
}
```

2. Run command:

```
jcodemunch-mcp config --check

...

Checks
  ✓ config.jsonc valid: /home/myuser/.code-index/config.jsonc
  ✓ index storage writable: /home/myuser/.code-index
...
```
^ as you see the file ".jcodemunch.jsonc" is not mentioned - so that is already a red flag

3. Try to index with DEBUG log level:

```

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/300) · 2026-05-14 · closed · external user · 8 comments

### Reducing the total number of tools in jCodeMunch, jDocMunch, and jDataMunch for Antigravity

With a more recent update of Antigravity Google is enforcing the 50 tool limit for the internal agent by forcing the deactivation of servers. jDocMunch itself is over that limit with its 53 tools. Currently jCodeMunch has 30 tools, jDocMunch has 53 tools, and jDataMunch has 26 tools. This is clearly over the 50 tool limit. I was looking through the tools for the three MCP servers and there are some similar tools, but I couldn't find enough to reduce the number of tool from 109 to 50 or less. 

S

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/297) · 2026-05-14 · closed · external user · 7 comments

### VS Code Hook Support

Any chance we can get hook support for VS Code?  If you publish it in their marketplace it can auto-upgrade too.

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/273) · 2026-05-04 · closed · external user · 10 comments

### Stress test results: jCodeMunch token overhead on grep-optimal territory (v1.8.3, 50 iterations, Sonnet 4.6)

## Summary

Stress-tested jCodeMunch v1.8.3 by pitting it against Claude Code's native tools (Grep/Glob/Read) on **dead code detection** — a reference-counting task that maps directly to grep's core strength (`grep -rlw`). This deliberately tests jCodeMunch on unfavorable terrain to establish a **worst-case token overhead ceiling**.

Two enforcement levels were tested:
- **Hard enforcement (25 pairs):** Platform-level tool restrictions via custom Claude Code agent types. Variant B physically can

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/142) · 2026-03-21 · closed · outside contributor · 12 comments

## Most recent

### Dead-code axes degenerate on Node/TS repos: v2 returns [] without entry points; find_dead_code counts docs/lockfile artifacts

**jcodemunch-mcp 1.108.305, SQLite backend, TypeScript/React repo**

Two related problems make the dead-code axes unusable on this repo:

1. `get_dead_code_v2` returns `dead_symbols: []` with `signal_warning: "2 of 3 signals do not discriminate on this repository and were not counted"` and `framework_warning: "No standard entry points detected (e.g. main.py, app.py, __main__.py)"`. Entry-point detection appears Python-only (main.py/app.py/__main__.py); for a Node/Next.js repo no entry points are

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/562) · 2026-08-28 · closed · outside contributor · 3 comments

### find_references: are type-only imports indexed? suspected cross-file reference misses for TS types

**jcodemunch-mcp 1.108.305, SQLite backend, TypeScript 5.x repo**

During refactor planning we use `find_references`/`check_references` to enumerate cross-file usages of exported types before moving them. Two of three spot-checked identifiers resolved correctly (`CreoJobBuild`: 2 refs found; `LayoutGestureBinding`: 2 refs found, third hit is the defining file). But a prior audit observed missed cross-file **type-only** references for `CreoJobBuild`, `DraftHistoryEntry` (defined in `src/hooks/Fra

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/560) · 2026-08-28 · closed · outside contributor · 3 comments

### Coupling instability counts framework entry points (Next.js route.ts) as unstable=1.0 modules

**jcodemunch-mcp 1.108.305, SQLite backend, Next.js App Router repo**

Coupling/instability treats framework entry points as ordinary modules. In this repo, **203 of 366 unstable files are `src/app/api/**/route.ts` files**, and **126 of those have zero importers** — instability 1.0 by construction (Ce/(Ca+Ce) with Ca=0), purely because Next.js registers them as HTTP endpoints. No code ever imports a route handler, so the import-graph formula cannot classify them as stable.

`find_dead_code` alre

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/561) · 2026-08-28 · closed · outside contributor · 3 comments

### search_ast returns zero matches for ALL languages — encoder schema declares 'results' but tool returns 'matches' (schema/producer key mismatch)

## Summary

`search_ast` returns zero matches for **every language and every preset/category**, not just C#. The compact encoder schema (`encoding/schemas/search_ast.py`) declares table key `results` and scalar `result_count`, but the tool (`tools/search_ast.py`) returns `matches` and `total_matches`. The encoder's `response.get("results", [])` finds nothing and silently produces an empty table.

This is the same class of bug as the `search_text` #246 fix (flat columns declared, nested/different

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/553) · 2026-08-26 · closed · external user · 2 comments

### Counter `order` gate rejections return an error body with `isError=False`, and have since v1.108.74 shipped the contract

## The one thing that is wrong

`order` refuses a call two ways: the action is not in the catalog, or the action
changes state and `allow_state_change` was not passed. Both return a JSON body
whose only key is `error`. Neither sets `isError`.

```json
{"error": "Unknown action 'no_such_action_xyz'. Call 'menu' (optionally with a query) to browse."}
```

An MCP client that branches on `isError`, which is exactly what v1.108.74 added
the flag for, reads that as a successful call whose r

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/552) · 2026-08-26 · closed · outside contributor · 4 comments

### `_call_ok` starts true and three of four error exits never clear it, so failed calls record `ok=1`

## The one thing that is wrong

`_call_tool_impl` tracks the outcome of a call in a local flag, `_call_ok`,
initialised to `True` at
[`server.py:5456`](https://github.com/jgravelle/jcodemunch-mcp/blob/610eb2cfdad865688a197ee7d899d3bded8f5273/src/jcodemunch_mcp/server.py#L5449-L5456).
The `finally` at the bottom persists that flag as the `ok` column
([`server.py:7198-7209`](https://github.com/jgravelle/jcodemunch-mcp/blob/610eb2cfdad865688a197ee7d899d3bded8f5273/src/jcodemunch_mcp/server.py

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/551) · 2026-08-26 · closed · outside contributor · 3 comments

### `from . import <sibling>` resolves to `__init__.py`, so 20 live files in this repo are reported dead

## The one thing that is wrong

`from . import receipts` in `evidence/producers.py` is a dependency on
`evidence/receipts.py`. JCodeMunch records it as a dependency on
`evidence/__init__.py` instead, and the edge to `receipts.py` is never built.

The shipped source uses that form 49 times. Re-indexing this repository with
only the import specifier changed, nothing else, drops
`find_dead_code(granularity="file")` from 42 dead files to 22. The other 20,
`runtime_identity.py` and nine `par

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/550) · 2026-08-25 · closed · outside contributor · 3 comments

### MCP spec conformance: 7 requirement(s) violated (via @hasmcp/mcp-spec-test) — spec 2026-07-28

Running the black-box `@hasmcp/mcp-spec-test` conformance suite against `jcodemunch-mcp` (via `uvx jcodemunch-mcp`) shows the server handles the older negotiated spec revision (2025-11-25) cleanly, but on the newest revision it advertises support for (2026-07-28) it fails 7 checks, all traceable to the `server/discover` method: it never responds when called pre-handshake (the request just times out), and once a session exists it consistently returns a JSON-RPC `-32602 Invalid request parameters`

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/536) · 2026-08-24 · closed · external user · 2 comments

### `CONFIGURATION.md` gives the wrong default for `disabled_tools`

## The one thing that is wrong

The Tools table documents the default as `[]`, and the shipped default is
`["test_summarizer"]`.

## Reproduction

No config file, no environment overrides.

```python
"""The documented default for disabled_tools is not the shipped one."""
import asyncio, os, sys, tempfile

os.environ["CODE_INDEX_PATH"] = tempfile.mkdtemp(prefix="jcm-doc-")  # no config file
sys.path.insert(0, "src")
from jcodemunch_mcp import config as cfg
from jcodemunch_mcp import server

mount

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/515) · 2026-08-19 · closed · outside contributor · 1 comment

### `index_file` can write a file into another repository's index

## The one thing that is wrong

`index_file` selects the deepest indexed `source_root` that contains the requested file
and never establishes that the file and that index are the same repository. `resolve_repo`
stopped doing this in #498; `index_file` still does, and now writes on the strength of it.

## Reproduction

Case 1 is the failure. Cases 2 and 3 are the controls a fix must not break.

```python
"""index_file picks the enclosing index by source_root containment alone."""
import os, shuti

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/509) · 2026-08-19 · closed · outside contributor · 0 comments

### `jcodemunch_guide` and `init` can name tools `tools/list` does not carry

## The one thing that is wrong

`_get_active_tools` reconstructs the active tool set from `tool_profile` and the baked
`_PROFILE_TIERS`, while the tool list is built from three inputs it does not read: a
session tier override, `tool_tier_bundles`, and the `languages` gate on `search_columns`.

Two generators depend on it, `jcodemunch_guide` and the CLAUDE.md that `init` writes, so
both can name tools `tools/list` does not carry.

## Reproduction

Four states, one process. A is the control. Both 

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/507) · 2026-08-19 · closed · outside contributor · 0 comments

### `jcodemunch_guide` can recommend a disabled tool in `### Quick start`

## The one thing that is wrong

`### Quick start` is built from fixed strings that no filter reaches, so it can instruct a
caller to run a tool `call_tool` rejects.

## Reproduction

```python
"""### Quick start names a disabled tool that call_tool then rejects."""
import asyncio, json, os, re, subprocess, sys, tempfile

work = tempfile.mkdtemp(prefix="jcm-quickstart-")
repo_dir, store = os.path.join(work, "repo"), os.path.join(work, "index")
os.makedirs(repo_dir); os.makedirs(store)
os.environ[

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/506) · 2026-08-19 · closed · outside contributor · 0 comments

### `jcodemunch_guide` does not filter `disabled_tools`, so at shipped defaults it advertises `test_summarizer`, which `tools/call` then rejects

## The one thing that is wrong

`_generate_claude_md_snippet` builds its `### All tools` list from a static
constant without consulting `disabled_tools`, so the guide advertises a tool the
same process refuses to run.

## Reproduction

No configuration file and no environment overrides: this is the shipped default
state, reached by pointing `CODE_INDEX_PATH` at an empty directory.

```python
"""Guide vs tools/list vs call_tool, plus the CLI policy generator for contrast."""
import a

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/495) · 2026-08-18 · closed · outside contributor · 2 comments

### `index_file` advances the repository `git_head` to live HEAD after refreshing one file, so `repo_is_stale` goes false for files still at the previous commit

## The one thing that is wrong

A single-file `index_file` writes live HEAD as the repository's stored SHA, which
makes `repo_is_stale` false for the whole repository even when other files
changed in that same commit and were never refreshed.

## Reproduction

```python
"""index_file advances repo git_head, clearing repo_is_stale for files it never refreshed."""
import json, os, shutil, subprocess, sys, tempfile
sys.path.insert(0, "src")

workdir = tempfile.mkdtemp(prefix="jcm-githe

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/493) · 2026-08-18 · closed · outside contributor · 1 comment

### `resolve_repo` matches on `source_root` containment before any repository-identity check, so a path inside a nested git repository resolves to the enclosing parent index

## The one thing that is wrong

`resolve_repo` returns the enclosing parent index, as `indexed: true`, for a path
that belongs to a different git repository, without ever establishing that the
path and the returned repository are the same repository.

## Reproduction

A parent repository with a second, independent git repository checked out inside
it. Case 1 is the failure. Case 2 is the same mis-resolution with the read
happening to succeed. Case 3 is the control.

```python
"""res

[Read the thread](https://github.com/jgravelle/jcodemunch-mcp/issues/492) · 2026-08-18 · closed · outside contributor · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/jgravelle/jcodemunch-mcp/issues).