Repository navigation
Codegraph finding more things than exist leading to errors in Claude/Codex #412
Description
For some inexplicable reason, we very often get
● CodeGraphContext - find_code (MCP)(query: "calculate_legacy_signal") │
⎿ Error: MCP tool "find_code" response (83894 tokens) exceeds maximum allowed tokens (25000). Please use pagination, filtering, or limit parameters to reduce the response size. │
And there for sure 100% isnt 83k worth of tokens for that specific query in my codebase. But this happens fairly often, could it perhaps be searching within multiple indexed repos at the same time, even though that still wouldn't explain it because my repos are quiiite different and dont have this overlapping for sure.
What could be the issue?
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
- Status
Activity
github-actions commentedon Oct 29, 2025
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
Shashankss1205 commentedon Oct 29, 2025
Hey, I am sorry this is a bug from our end. We do a full text search and hence there are circumstances of similarity being returned by the find_code function. We need to limit it to something above a threshold for being a similar item. We will patch this in our next version
Shashankss1205 commentedon Dec 30, 2025
Hey @cranyy, I am sorry this issue got overlooked. I am willing to know if this issue persisted and are you interested in getting a smarter solution for this
D4rk-Pho3nix commentedon Jun 4, 2026
Hi @Shashankss1205 👋
I've gone through the repo and would love to contribute a fix + enhancement for this issue. The root cause is clear find_code does a full-text search with no result cap or node-type scoping, causing it to flood the context with low-relevance matches.
My Approach to Issue #412:
End Goal:
Could you please assign this issue to me under GSSoC? Looking forward to contributing :3
D4rk-Pho3nix commentedon Jun 7, 2026
@Shashankss1205 could u assign this issue to me under gssoc ?
Shashankss1205 commentedon Aug 2, 2026
Still reproduces on 0.5.4, and I think I can explain the number you saw.
Your instinct that there "for sure isn't 83k worth of tokens for that query" is right in terms of matches — but the response size isn't bounded by match count. Two separate things are going on:
1. The row cap exists but doesn't limit response size.
utils/tool_limits.py:23capsfind_codeat 20 results, and those defaults deliberately reproduce the legacy behaviour. But every row carries the full function body —tools/code_finder.py:197and five other query sites all projectnode.source:So 20 matches on a name like
calculate_legacy_signalin a codebase with long functions reaches 83k tokens easily. The cap counts rows, not bytes.2. The byte-level guards ship disabled.
cli/config_manager.py:117,121:Both truncation mechanisms exist but are off out of the box, so nothing clips the payload before it reaches the MCP client.
Workaround right now: set
MAX_TOOL_RESPONSE_TOKENSto something under your client's limit (e.g.20000) viacgc config set. That activates the truncation path inserver.py:119-180.To answer your actual question — no, it isn't searching across multiple indexed repos.
find_codescopes byrepo_pathwhen supplied; without it, it matches by name across the graph, which is a separate (and fair) usability concern.Two related notes: #1532 shows
pathis aliased intorepo_pathfor some tools in a way that breaks scoping, and be aware that truncation currently overshoots its own budget by 10-25% because the cap is applied before JSON string-escaping.Keeping this open — a sensible default for
MAX_TOOL_RESPONSE_TOKENS, or droppingsourcefromfind_codeunless explicitly requested, would both be real fixes.Shashankss1205 commentedon Oct 15, 2026
Maintenance review — 15 October 2026
Keep this open for an output-size regression: bound serialized source/docstrings as well as result count, apply repository scope, and test the actual MCP token limit. Small match counts alone do not bound response size.