constant timeouts

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.

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

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.

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!

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.

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:

configurable per-request wall deadline installed on the active SQLite connection;
abort through the progress callback and/or a correctly synchronized sqlite3_interrupt;
return a typed timeout/unavailable MCP error with tool, project, elapsed time, and deadline;
clear cancellation state before the connection is reused;
readiness that runs a bounded representative statement, not only a metadata-row read;
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.

Thanks for the independent Linux reproduction and the exact v0.9.0 source check. I have raised this to high priority in 0.9.1-rc and linked it under #593. Bounded query execution and proving that a timed-out statement cannot poison the next request are now explicit review concerns; the exact public configuration surface still needs design review.

@Bia10

Thank you, @Bia10, for the exact tool call and file shape, and @paul5007 for the independent Linux reproduction and the careful source audit!

Both halves have landed:

search_code scans are now bounded and return a typed "exceeded its execution deadline" error instead of hanging until the client gives up (fix(mcp): bound search_code scan deadlines #1866, in v0.11.0).
query_graph Cypher execution has its own execution deadline (fix(cypher): add a wall-clock execution deadline to abort runaway queries (#601) #1109, since v0.10.0).

Could you confirm on v0.11.0 that these calls now either complete or fail fast with that error?

@paul5007, the wider contract you described goes beyond this bug: a configurable per-request deadline, plus a readiness probe that runs a representative statement. We'll consider it separately as an enhancement.

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.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Thank you for the Windows and Linux reproductions. If you have already retested after the deadline changes described above, could you share the exact version and whether the call completes or returns a bounded error? The broader configurable-deadline/readiness proposal remains a separate design question.

Navigation Menu

Repository navigation

constant timeouts #474

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Project scale (if relevant)

Confirmations

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

constant timeouts #474

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Project scale (if relevant)

Confirmations

Activity

DeusData commented on Jun 16, 2026

Bia10 commented on Jun 16, 2026

DeusData commented on Jun 26, 2026

github-actions commented on Jun 26, 2026

paul5007 commented on Jul 19, 2026

DeusData commented on Jul 19, 2026

DeusData commented on Sep 26, 2026

github-actions commented on Sep 26, 2026

github-actions commented on Oct 18, 2026

DeusData commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions