[Windows] MCP stdio startup emits localized path-not-found message on stderr

[Shinken009]

Summary

On the official Windows amd64 v0.8.1 binary, starting the MCP stdio server emits a localized OS error on stderr even when the cache is empty and the process completes successfully:

level=info msg=mem.init budget_mb=... total_ram_mb=...
El sistema no puede encontrar la ruta especificada.

The second line means The system cannot find the path specified.

Environment

• Windows 11, Spanish locale
• codebase-memory-mcp 0.8.1
• MCP serverInfo.version: 0.10.0
• MCP protocol: 2025-03-26
• Official codebase-memory-mcp-windows-amd64.zip
• ZIP checksum and GitHub attestation verified

Minimal reproduction

Run the binary in stdio mode with a fresh empty CBM_CACHE_DIR, send only:

1. initialize
2. notifications/initialized
3. tools/list

Capture stdout and stderr separately. The behavior reproduces both from C:\ and from a normal repository directory.

Equivalent Python harness:

import json, os, subprocess, tempfile

cache = tempfile.mkdtemp()
env = os.environ.copy()
env["CBM_CACHE_DIR"] = cache
messages = [
    {"jsonrpc":"2.0","id":1,"method":"initialize","params":{
        "protocolVersion":"2025-03-26",
        "capabilities":{},
        "clientInfo":{"name":"minimal-repro","version":"1"}
    }},
    {"jsonrpc":"2.0","method":"notifications/initialized","params":{}},
    {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}},
]
result = subprocess.run(
    [r"C:\path\to\codebase-memory-mcp.exe"],
    input="".join(json.dumps(m) + "\n" for m in messages),
    text=True,
    capture_output=True,
    env=env,
)
print(result.returncode)  # 0
print(result.stderr)

Actual behavior

• Exit code is 0.
• stdout contains valid JSON-RPC responses.
• stderr always includes the localized path-not-found line.
• The message also appears with no indexed projects, so it is not caused by a stale repository root.

Expected behavior

No OS path error should be written during a successful minimal MCP startup, or the missing optional path should be handled silently / logged with identifying context.

Impact

The server remains functional, but MCP clients may surface the line as an error. It also makes ad-hoc PowerShell users more likely to merge stderr with stdout, which corrupts captured JSON.

This appears separate from #423, which concerns CLI JSON/path argument handling.

[DeusData]

Thanks for the Windows stderr report. I’ve triaged it under #394 and #395. MCP startup needs to stay protocol-clean, so localized OS path messages should either be suppressed, structured into logs, or attached to a real failing operation instead of leaking on startup stderr.