Windows: chroma-mcp connection fails - uvx.cmd breaks MCP stdio transport

[CodesHour]

Bug Description

On Windows, the chroma-mcp vector search backend fails to connect with MCP error -32000: Connection closed. The search MCP tool is completely non-functional — every call returns this error or chroma-mcp connection in backoff (Xs remaining).

Environment

• OS: Windows 11 Pro 10.0.26200
• claude-mem version: 10.3.1 (main branch, latest as of Feb 20, 2026)
• Node.js: v24.13.0
• Bun: installed at ~/.bun/bin/bun.exe
• Python/uvx: uvx 0.9.28, Python 3.13
• uvx location: C:\Users\<user>\.local\bin\uvx.exe

Root Cause

In worker-service.cjs, the connectInternal() method spawns chroma-mcp using:

let i = process.platform === "win32" ? "uvx.cmd" : "uvx";

On Windows, uvx.cmd is a batch file wrapper. When StdioClientTransport spawns it as a child process, the .cmd wrapper adds an indirection layer that breaks the stdin/stdout MCP handshake. The connection closes within milliseconds (~4ms) before initialization completes.

Logs

[CHROMA_MCP] Connecting to chroma-mcp via MCP stdio {command=uvx.cmd, args=chroma-mcp --client-type persistent --data-dir C:\Users\<user>\.claude-mem\chroma}
[CHROMA_MCP] Connection failed, killing subprocess to prevent zombie {error=MCP error -32000: Connection closed}
[CHROMA] SDK chroma sync failed, continuing without vector search

This is the same class of bug as #695 (macOS), but with a Windows-specific cause.

Fix / Workaround

Changing uvx.cmd to the full path of uvx.exe resolves the issue completely:

// Before (broken on Windows):
let i = process.platform === "win32" ? "uvx.cmd" : "uvx";

// After (works):
let i = process.platform === "win32" ? "uvx.exe" : "uvx";

Using uvx.exe directly bypasses the .cmd batch wrapper and allows the MCP stdio transport to function correctly. After this one-line change, all search/vector operations work perfectly.

Suggested robust fix:

const { execSync } = require('child_process');

function resolveUvx() {
  if (process.platform !== 'win32') return 'uvx';
  // Prefer .exe directly to avoid .cmd stdio issues
  try {
    const resolved = execSync('where uvx.exe', { encoding: 'utf-8', timeout: 5000 }).trim().split('\n')[0];
    if (resolved) return resolved;
  } catch {}
  return 'uvx.exe'; // fallback — .exe suffix still avoids .cmd
}

Steps to Reproduce

1. Install claude-mem 10.3.1 on Windows 11
2. Ensure uvx is installed (via pip install uv or standalone installer)
3. Use any search MCP tool (e.g., search with any query)
4. Observe MCP error -32000: Connection closed in response and logs

Related

• macOS: Chroma MCP connection fails with 'MCP error -32000: Connection closed' #695 — Same symptom (chroma-mcp connection failure) on macOS, different root cause
• PR fix: prevent chroma-mcp spawn storm with 5-layer defense (641 processes → max 2) #1065 — 5-layer defense fix for macOS: Chroma MCP connection fails with 'MCP error -32000: Connection closed' #695 (does not resolve this Windows-specific .cmd wrapper issue)

Impact

All MCP search functionality (semantic/vector search) is broken on Windows. The SQLite FTS fallback doesn't activate for MCP tool calls — they just error out. The worker itself runs fine (/api/health returns OK), but the internal chroma-mcp child process can never connect.

[github-actions]

The GitHub issue describes a problem where the chroma-mcp backend fails on Windows due to a bug in the handling of the uvx command-line tool. Specifically, the uvx.cmd batch file wrapper, used in Windows environments, disrupts the standard input/output connection required for the MCP protocol handshake, leading to rapid connection closures and rendering the vector search functionality entirely non-functional. The issue is caused by using uvx.cmd instead of the executable uvx.exe in the connectInternal() method of the code, and is similar to a previous macOS issue (#695) but has a Windows-specific root cause. A one-line fix is proposed, replacing uvx.cmd with uvx.exe, which bypasses the batch file wrapper and resolves the problem completely. A more robust implementation using execSync to dynamically resolve the correct uvx path is also suggested. The issue impacts all MCP-based vector search features, leaving users

[mil-orb]

Independent confirmation — I hit this exact bug on Windows 11 Home (10.0.26200) with:

• claude-mem 10.3.1
• Node.js v24.13.0
• uvx 0.9.30 installed via standalone installer → only uvx.exe exists at ~/.local/bin/uvx.exe

Additional root cause detail

The issue report is mostly correct but the root cause is slightly different than described. It's not that the .cmd wrapper "breaks the stdin/stdout MCP handshake" — it's that uvx.cmd doesn't exist at all on systems where uv was installed via the standalone installer (which creates uvx.exe only, no .cmd wrapper).

The failure chain is:

1. worker-service.cjs passes "uvx.cmd" to StdioClientTransport
2. The MCP SDK uses bundled cross-spawn, which resolves "uvx.cmd" → wraps as cmd.exe /d /s /c "uvx.cmd chroma-mcp ..."
3. cmd.exe can't find uvx.cmd → exits with code 1
4. MCP transport sees subprocess die → "Connection closed" → backoff timer

Verified fix: Changing "uvx.cmd" to just "uvx" works — cross-spawn correctly resolves "uvx" to uvx.exe on Windows via PATHEXT. No need for where or execSync.

// Simple, correct fix:
let i = process.platform === "win32" ? "uvx" : "uvx";
// Or just:
let i = "uvx";

Since cross-spawn already handles Windows .cmd/.exe resolution, the platform ternary is unnecessary entirely.