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.

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 · 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:

A tool can hydrate the complete code index even when it needs only a symbol, file, or small candidate set.
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 · 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 · 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.

Read the thread · 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 · 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 · 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:

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 · 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 · 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 · 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 · 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.

{"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 · 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. 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 · 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 · 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 · 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.

"""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).

Reported issues for jCodemunch MCP

Most discussed

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

Description

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

BUG: get_file_outline()

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

VS Code Hook Support

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

Summary

Most recent

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

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

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

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

Summary

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

_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

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

The one thing that is wrong

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

CONFIGURATION.md gives the wrong default for disabled_tools

The one thing that is wrong

Reproduction

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

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

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

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