MCP server dies on heavy ctx_execute workloads

[khaosdoctor]

Summary

The context-mode MCP server (v1.0.75) crashes with MCP error -32000: Connection closed on heavy ctx_execute / ctx_batch_execute workloads. The crash cascades: a second call after the first failure also dies immediately, wiping tool registration from Claude Code until the user restarts.

Could be related to #242 and #236

Environment

• context-mode 1.0.75
• Claude Code on Linux (Arch, kernel 6.19)
• Node v25.2.1, better-sqlite3 12.8.0 (abi141 prebuilt present)
• Workload: processing ~173 JSONL files (~46 MB total) from ~/.claude/projects/

Reproduction

Twice in the same session, while scanning conversation logs:

1. Call 1: ctx_execute(language: "javascript", code: <~60 LOC JS that reads 173 files, regex-scans ~8 MB of text, pushes substrings into an array, console.logs a small summary>, intent: "..."). Child finished; parent MCP died mid-response. ctx_stats afterwards returned "session (< 1 min)" then the server had silently restarted.

2. Call 2: immediately after, a trivial ctx_batch_execute with six short shell commands (ls, find -name ... | head, cat package.json). Server died again and this time Claude Code stopped re-registering the tools entirely, all mcp__plugin_context-mode_* tools disappeared for the rest of the session.

This has happened before in my machine:

• ~/.claude/context-mode/sessions/ held 7 .db files but only 6 .cleanup markers so, orphaned session state from past crashes.
• ~/.claude/context-mode/content/<session>.db was 4 KB / effectively empty the persistent index never populated despite many hours of use across sessions.
• Historical sessionstart-debug.log: Cannot find module 'better-sqlite3' thrown from plugins/marketplaces/context-mode/hooks/session-db.bundle.mjs. The module is now present in that path, so this specific historical error is resolved, but the empty index DB suggests the write path still fails silently somewhere.

Suspected root cause

src/server.ts:45-50 installs uncaughtException / unhandledRejection handlers that only process.stderr.write(...), they don't re-throw or process.exit, so intent is "log and continue", but there's other things happening:

• indexStdout / intentSearch auto-fire on any stdout > 5 KB (INTENT_SEARCH_THRESHOLD) or > 100 KB (LARGE_OUTPUT_THRESHOLD) — see src/server.ts:739, 749, 769, 779, 810, 839.
• Both call into store.index(...) / store.indexPlainText(...), which write to SQLite via better-sqlite3. better-sqlite3 throws synchronous exceptions from native C++ (SQLITE_BUSY, SQLITE_MISUSE, FTS5 tokenizer errors on unusual UTF-8, etc.).
• Synchronous throws from inside async tool handlers are caught by the outer try { ... } catch at server.ts:788, which returns { isError: true }. But if the throw happens during the response-building step (e.g. inside intentSearch's call chain), it propagates past the handler's catch and lands on the unhandled-exception path — which only logs.
• In that logged-but-not-recovered state, the stdio transport has already half-written a response. The MCP JSON-RPC client sees framing corruption and closes the stdin pipe. The lifecycle guard in src/lifecycle.ts:59-63 treats stdin close as "parent gone" and calls onShutdown(). Server exits.
• On next launch, the orphaned WAL file (*.db-wal) on the session DB causes the new process to die during DB open → cascade failure. This matches the 1→2 crash pattern I observed exactly.

Fixes?

1. Wrap SQLite writes in try/catch at server.ts:810 and server.ts:839 (every store.index* call). On failure, log to stderr and return a plain-text fallback — do NOT let it escape into the handler's outer catch.
2. Close WAL on shutdown: in lifecycle.ts onShutdown, run db.pragma('wal_checkpoint(TRUNCATE)') and db.close() before exit. This prevents orphaned WALs from moving to the next launch.
3. Validate DB on open: on startup, if opening a session DB throws, rename it to .corrupt-<timestamp> and create fresh.
4. Stronger uncaughtException handling: if an exception originates from better-sqlite3 (check err.code?.startsWith('SQLITE_')), attempt a DB close + WAL checkpoint before allowing the process to continue or exit cleanly.

Impact

Anyone using context-mode to process large workloads will hit this eventually. Because the crash wipes tool registration without a clean error in the UI, users think "context-mode is flaky" and fall back to raw Bash, which kinda defeats the plugin's purpose. Sometimes claude itself falls back and refuses to use the mcp again

Happy to run further diagnostics.

[khaosdoctor]

Rebuilt the environment from scratch to rule out orphaned state and managed to reproduce:

1. Removed orphaned .cleanup markers and the empty session content DB from ~/.claude/context-mode/
2. Uninstalled and reinstalled context-mode via Claude Code's /plugin command
3. Verified the fresh cache path ~/.claude/plugins/cache/claude-context-mode/context-mode/1.0.75/.mcp.json contains ${CLAUDE_PLUGIN_ROOT}/start.mjs (the expected template)
4. ctx_doctor returned all green: runtimes, FTS5, hook script, version 1.0.75

Then ran two back-to-back ctx_execute calls against JSONL conversation logs:

Call	Workload	Result
1	Walk 174 files (46 MB total), count short pattern matches	Passed
2	Walk one ~1 MB file, regex-scan with alternation, push bracketed tags into array, small stdout	Crashed (`MCP error
-32000: Connection closed`)

After the second crash, every mcp__plugin_context-mode_* tool disappeared from the Claude Code session and did not come back. The cascade (tools deregistered after one failure) is reproducible independent of the pre-existing orphaned state that I originally suspected in the first report.

Minimal repro script attached in the next comment. The passing and crashing calls differ mainly in output shape. The crashing variant has bracketed markers like [#<idx> <role>], [TOOL_USE ...], [TOOL_RESULT ERROR: ...] and a regex with alternation plus . and _. The passing variant has a plain JSON object output with no brackets or tags.

[khaosdoctor]

Asked AI to generate the script to test the crash it had. So, paste into ctx_execute with language: "javascript" and intent: "context-mode crash details heredoc disconnection". Point TARGET at any JSONL conversation log with tool_use and tool_result blocks (1 MB is enough).

const fs = require('fs');
const path = require('path');

const TARGET = process.env.TARGET || '/path/to/any.jsonl';

function pull(content) {
  if (typeof content === 'string') return content;
  if (Array.isArray(content)) return content.map(c => {
    if (typeof c === 'string') return c;
    if (c.type === 'text') return c.text || '';
    if (c.type === 'tool_use') return `[TOOL_USE ${c.name}: ${JSON.stringify(c.input || {}).slice(0, 500)}]`;
    if (c.type === 'tool_result') {
      const body = typeof c.content === 'string'
        ? c.content
        : Array.isArray(c.content) ? c.content.map(x => x.text || '').join(' ') : '';
      return `[TOOL_RESULT${c.is_error ? ' ERROR' : ''}: ${body.slice(0, 500)}]`;
    }
    return '';
  }).join(' ');
  return '';
}

const lines = fs.readFileSync(TARGET, 'utf8').split('\n').filter(Boolean);
const hits = [];
let idx = 0;
for (const line of lines) {
  idx++;
  try {
    const obj = JSON.parse(line);
    const txt = pull(obj.message?.content);
    const role = obj.message?.role || obj.type;
    if (/context-mode|ctx_|mcp.*disconnect|crashed|heredoc/i.test(txt)) {
      hits.push({ idx, role, txt: txt.slice(0, 800).replace(/\s+/g, ' ') });
    }
  } catch {}
}

console.log(`File: ${path.basename(TARGET)} (${lines.length} lines)`);
console.log(`Hits: ${hits.length}`);
for (const h of hits.slice(0, 15)) {
  console.log(`\n[#${h.idx} ${h.role}]`);
  console.log(`  ${h.txt.slice(0, 350)}`);
}

This other call doesn't crash... Same ctx_execute, intent: "crash patterns in conversation history", different output shape, so I used as a control run:

const errorPatterns = { timeout: 0, crash: 0, killed: 0, panic: 0 };
for (const f of files) {
  const content = fs.readFileSync(f, 'utf8');
  for (const pat of Object.keys(errorPatterns)) {
    if (content.toLowerCase().includes(pat)) errorPatterns[pat]++;
  }
}
console.log(JSON.stringify(errorPatterns, null, 2));

[murataslan1]

Looked at the error handling paths in src/server.ts.

The global handlers at lines 45-50 catch unhandledRejection and uncaughtException but only log to stderr — no recovery, no connection cleanup:

process.on("unhandledRejection", (err) => {
  process.stderr.write(`[context-mode] unhandledRejection: ${err}\n`);
});

The auto-indexing paths (around line 826, LARGE_OUTPUT_THRESHOLD = 102_400) call store.index() from multiple tool handlers. Some are wrapped in try-catch at the outer handler scope, but the indexing itself can throw through the retry layer in store.ts, and if that bubbles up at the wrong moment it hits the global handler instead of a local recovery path.

That said, I think the most likely trigger for the -32000 on heavy workloads is still the lifecycle guard issue from #236 — process.stdin.resume() + unconditional shutdown on stdin events. A heavy workload produces more stdout traffic, which increases the chance of a transient stdin event firing during a pipe buffer flush.

Fixing #236 first and then retesting heavy workloads would help isolate whether the indexing path actually crashes independently or just gets caught in the lifecycle shutdown.

[flightlesstux]

@khaosdoctor — your analysis lines up with #236: the lifecycle guard's stdin listeners treating framing-corrupted pipe closes as "parent gone" is the terminal stage of the cascade you described.

I opened #255 that supersedes #237 (same production-code fix by @ponythewhite, plus the test-contract update that kept CI red). Once #255 lands, the abrupt process.exit(0) on stdin events goes away and the client should stop seeing -32000 on the first crash.

The rest of the cascade you documented — synchronous better-sqlite3 throws escaping past the outer try/catch during response-building, orphaned WAL on next launch, uncaught-exception handler that only logs — is genuinely independent of #236 and I've scoped a separate follow-up PR for it:

1. Wrap store.index* calls at server.ts:810 / 839 in local try/catch so SQLite throws can't leak past the tool handler.
2. db.pragma("wal_checkpoint(TRUNCATE)") + db.close() inside onShutdown to prevent orphaned WALs carrying over.
3. await transport.close() in gracefulShutdown so in-flight JSON-RPC responses finish cleanly.
4. Stronger uncaughtException path: if err.code?.startsWith("SQLITE_"), checkpoint + close before exit.

Would appreciate if you could retest on your original heavy workload once #255 merges — if the cascade still reproduces independently, that's the concrete evidence we need to prioritize the follow-up. If it doesn't, at least items 2–4 are still worth landing as defense-in-depth.

cc @mksglu — flagging so #255 is on your radar as the prerequisite step before this one.

[flightlesstux]

@murataslan1 thanks for digging into the error paths — your "fix #236 first, retest heavy workloads" approach is exactly the sequencing I went with, and the stdout-backpressure → flowing-stdin → false-positive-shutdown mechanism is a much cleaner mental model for why heavy workloads reproduce the bug than what I had before. I'll cite it in the follow-up PR description.

One refinement on scope: your analysis implicitly suggests #236 might be sufficient. I don't think it quite covers the full picture of Lucas's report. Two distinct crashes happened in sequence:

1. Crash 1 — during a heavy ctx_execute workload. This fits the Lifecycle guard stdin listeners cause spurious MCP -32000 Connection closed #236 model perfectly: heavy stdout traffic, flowing stdin, transient pipe event → guard exits.
2. Crash 2 — immediately after, on a trivial ctx_batch_execute (six short shell commands: ls, find ... | head, cat package.json). Almost no stdout traffic, no backpressure. The Lifecycle guard stdin listeners cause spurious MCP -32000 Connection closed #236 mechanism doesn't cleanly explain this one.

The more likely trigger for Crash 2 is what Lucas called out directly: the orphaned .db-wal left behind by Crash 1 causes the new process to die during better-sqlite3 open — which is independent of stdin entirely. The "cleaned up 7 .db files but only 6 .cleanup markers" observation supports that.

That's why I think the follow-up after #255 still needs all four of:

• local try/catch around store.index* calls so SQLite throws don't escape to the global handler,
• wal_checkpoint(TRUNCATE) + db.close() in onShutdown so a Crash 1 doesn't leave a corrupt WAL for the next launch,
• await transport.close() in gracefulShutdown so in-flight JSON-RPC doesn't tear,
• SQLite-aware uncaughtException handling.

Essentially: #236 fixes link 1 of the cascade (stdin false-positive shutdown), but link 2 (corrupt WAL carrying over to cold start) needs its own fix or the second crash will still happen even after #255 merges.

Happy to be wrong if the retest shows Crash 2 doesn't reproduce — that'd be great news. But I'd rather design the follow-up assuming both links need treatment.

[mksglu]

The remaining cascade triggers from this issue are now fixed on next (commit 9e246a8):

WAL checkpoint on exit — The global process.on("exit") handler now calls closeDB() (WAL checkpoint + close) instead of bare db.close(). This prevents orphaned -wal files that caused the 1→2 crash cascade described in the original report.

Corrupt DB recovery — Both SQLiteBase (SessionDB) and ContentStore constructors now catch SQLITE_CORRUPT / SQLITE_NOTADB on open:

• SessionDB: renames corrupt files to .corrupt-{timestamp} for debugging, creates fresh DB
• ContentStore: deletes corrupt files and recreates (ephemeral per-process DB)

Combined with the previously merged fixes:

• 156a1cd — lifecycle stdin listener removal (Lifecycle guard stdin listeners cause spurious MCP -32000 Connection closed #236) — root cause of -32000
• 13dcec2 — SQLITE_BUSY retry logic (MCP server crashes under multi-session SQLite contention (SQLITE_BUSY) #218)
• 302bb7b — node:sqlite adapter to avoid SIGSEGV on Linux (Support alternative SQLite backends (node:sqlite) to avoid native addon SIGSEGV crashes #228)
• bb6552d — ctx_doctor resource leaks (ctx_doctor MCP tool crashes the server mid-session #247)

All four cascade stages from the original report are now addressed. 5 new tests cover the WAL checkpoint and corrupt recovery paths.

@khaosdoctor — would appreciate if you can verify on the next release. The heavy-workload scenario (173 JSONL files, ~46 MB) should no longer crash the server.

[khaosdoctor]

Alright! Thanks a lot. Will try as soon as it's released 

[mksglu]

Alright! Thanks a lot. Will try as soon as it's released

it's released already.