constant timeouts

[Bia10]

Version

latest

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Constantly expiriencing tool call timeouts agents default back to using normal commands...

Reproduction

.

Logs

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Hey, thx for reporting. Can you share more details, like for example server logs, graph details, code language you try to index etc? There are some issue templates with more details :)

[Bia10]

Oh sure i ill ask the current implementation agent who encountered these issues to report back. Here:

Stopped. Here is a paste-ready bug report draft.

Version
codebase-memory-mcp 0.8.1

Platform
Windows x64
OS: Microsoft Windows 10.0.19045
Arch: X64

Install Channel
Likely GitHub release archive / install.ps1. Binary path:

C:\Users\Bia\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe

Binary Variant
standard / stdio server

Help output says:

codebase-memory-mcp              Run MCP server on stdio
--ui=true    Enable HTTP graph visualization

Running process command line:

"C:/Users/Bia/AppData/Local/Programs/codebase-memory-mcp\codebase-memory-mcp.exe"

What Happened
search_code in mode: "full" timed out through MCP after 120 seconds on a C# repo. I expected either a bounded/truncated result, a quick error explaining the result is too large, or a paginated response. Instead the MCP call hung until the client-side timeout.

The compact/indexing paths were responsive; the failure happened when asking for full source around a match in a large C# file.

Reproduction
Observed on a private C#/.NET repository, so the exact source cannot be shared. The relevant shape is:

• C#/.NET + Avalonia repo
• 212 files under src
• 185 .cs files
• 17 .axaml files
• one large C# control file: ~401,054 bytes, ~7,951 lines
• indexed with mode: "fast"

Index call:

{
  "repo_path": "C:\\path\\to\\repo",
  "mode": "fast",
  "persistence": false
}

Index result scale:

7,515 nodes / 23,771 edges / 22,085,632 byte graph db

Failing MCP tool call:

{
  "project": "C-Users-Bia-source-repos-ArcanumEditor",
  "pattern": "ShouldDrawImmediateCommittedBaseMissingChunks",
  "path_filter": "src/Rendering/ArcanumEditor.Rendering.Avalonia/Controls/MapSceneControl.cs",
  "mode": "full",
  "limit": 4,
  "context": 4
}

Actual output:

tool call error: tool call failed for `codebase-memory-mcp/search_code`

Caused by:
    timed out awaiting tools/call after 119.9999977s

Expected output:

A bounded result, a truncated full-source result, pagination guidance, or a fast error saying the full result is too large.

Logs
No obvious standalone log file found under:

C:\Users\Bia\.cache\codebase-memory-mcp
C:\Users\Bia\.config

Cache DBs found:

_config.db                                                        12,288 bytes
C-Users-Bia-source-repos-ArcanumEditor.db                    22,085,632 bytes

Project Scale
7,515 nodes / 23,771 edges / 212 src files / 185 C# files

Confirmations

• I searched existing issues and this is not a duplicate.
• The exact observed repo is private; a shareable repro should use a dummy/public C# repo with a large ~8k-line file and the same search_code mode=full call shape.

[DeusData]

Thanks for the detailed follow-up with the exact tool call and file shape — that's
really actionable. A search_code mode=full call on a ~8 k-line file timing out at
120 s, on a graph of only 7,515 nodes, is a focused bug we want to reproduce and cap.

To determine whether the server is stuck computing or has exited silently:

Instructions for your coding agent:

# Run in a PowerShell window while the MCP server is active

# 1. Confirm version and process state
codebase-memory-mcp --version
Get-Process codebase-memory-mcp -ErrorAction SilentlyContinue |
  Select-Object Id, CPU, WorkingSet64

# 2. Find the server log
$log1 = "$env:LOCALAPPDATA\codebase-memory-mcp\server.log"
$log2 = "$env:USERPROFILE\.cache\codebase-memory-mcp\server.log"
if (Test-Path $log1) { $logpath = $log1 } elseif (Test-Path $log2) { $logpath = $log2 }
Write-Host "Log path: $logpath"
Get-Content $logpath -Tail 20 -ErrorAction SilentlyContinue

# 3. Right after triggering the search_code call that times out,
#    sample CPU every 10s for 2 minutes:
1..12 | ForEach-Object {
  $p = Get-Process codebase-memory-mcp -ErrorAction SilentlyContinue
  if ($p) {
    "{0:HH:mm:ss} CPU={1:N1}s RSS={2}MB" -f (Get-Date), $p.CPU, [math]::Round($p.WorkingSet64/1MB)
  } else {
    "{0:HH:mm:ss} process gone" -f (Get-Date)
    break
  }
  Start-Sleep 10
}

# 4. After the 120s timeout, paste the last 30 log lines:
Get-Content $logpath -Tail 30 -ErrorAction SilentlyContinue

The CPU sample (step 3) tells us whether the server is actively working (CPU climbing)
or idle (CPU 0 = stuck on I/O, or already dead). The last log lines show which internal
operation the server was in when the client gave up.

The exact tool call from your follow-up comment is already enough for us to write the
test — we just need the server-side signal to understand what it was doing.

Thank you!

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

[paul5007]

Additional Linux reproduction from another v0.8.1 deployment, with a substantially larger graph and a different affected tool (query_graph).

Environment:

• codebase-memory-mcp 0.8.1, Linux x86_64, stdio MCP
• graph: 201,326 nodes / 240,018 edges / 273,547,264-byte SQLite DB
• project is private, so I cannot share source; the query below contains no project source

Exact call:

{
  "project": "home-paula-projects-adjurra-platform",
  "query": "MATCH (a)-[r:CALLS]->(b) RETURN a.qualified_name AS caller, b.qualified_name AS callee LIMIT 50"
}

Observed behavior:

• fresh one-shot CLI process completed: 50 rows, 2.94s wall, 1.22s user, 1.38s sys, 629,168 KiB max RSS
• the long-lived MCP transport under concurrent multi-agent use repeatedly goes from responsive metadata reads to Transport closed; previous calls were observed at 5–15s solo and beyond a 30s client deadline under load
• index_status/metadata can remain fast while the costly statement is still unbounded, so readiness does not represent query executability

I also audited the official v0.9.0 source at tag commit b637e3330c96cfe452da623db068c241aaa3ec01. The application store still sets only PRAGMA busy_timeout = 10000 in src/store/store.c. Searches for sqlite3_progress_handler and sqlite3_interrupt find only the vendored SQLite declarations/implementation, not an application-level per-statement deadline. The v0.9.0 indexing supervisor timeout is valuable but does not bound MCP query execution.

SQLite's documented cancellation seams are:

• progress callback: https://www.sqlite.org/c3ref/progress_handler.html
• cross-thread interrupt: https://sqlite.org/c3ref/interrupt.html
• busy_timeout only installs a busy handler: https://www.sqlite.org/pragma.html#pragma_busy_timeout

Requested server contract:

1. configurable per-request wall deadline installed on the active SQLite connection;
2. abort through the progress callback and/or a correctly synchronized sqlite3_interrupt;
3. return a typed timeout/unavailable MCP error with tool, project, elapsed time, and deadline;
4. clear cancellation state before the connection is reused;
5. readiness that runs a bounded representative statement, not only a metadata-row read;
6. concurrency tests proving a timed-out query cannot poison the next request.

This is tracked downstream as TF-Insurance-Solutions/adjurra-platform#1336. Exa research was attempted but its connector required OAuth; the evidence above comes from the installed binary, a one-shot execution, the exact v0.9.0 source tag, and official SQLite documentation.