Repository navigation
[Windows] MCP stdio startup emits localized path-not-found message on stderr #654
Description
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:
initializenotifications/initializedtools/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.
Activity
DeusData commentedon Jun 29, 2026
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.
github-actions commentedon Jul 8, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.DeusData commentedon Jul 8, 2026
v0.9.0 includes Windows installer/runtime reliability work and path handling fixes. Could you retest startup on v0.9.0 and confirm whether this stderr path-not-found noise still appears? Marking awaiting-reporter.
github-actions commentedon Jul 30, 2026
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 be closed in 14 days if there's no update — just add a comment to keep it open. We're happy to pick it back up the moment we can reproduce it.github-actions commentedon Sep 27, 2026
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.DeusData commentedon Oct 19, 2026
Thank you again for the minimal startup reproduction. Checking back: does the localized path-not-found line still appear on your current binary during an otherwise successful handshake? The version and a short stderr excerpt would be enough; no project source is needed for this startup case.
Shinken009 commentedon Oct 22, 2026
Hi Martin,
It's a pleasure to be in touch again. Thank you for following up on my report and for the opportunity to help. I completed the startup retest you requested and reviewed the related Windows regression work; I hope the results and focused cleanup suggestion below are useful.
Current-version retest
I retested the official, unmodified Windows amd64 v0.12.1 binary on October 22, 2026. The localized path-not-found line did not appear in either of the two startup sessions.
For each session, I used fresh, isolated cache/runtime directories, kept stdout and stderr separate, and disabled the optional UI before startup. The exchange was limited to
initialize,notifications/initialized, andtools/list; no repository indexing or private project source was needed.Both JSON-RPC responses arrived while stdin was still open. I then closed stdin and allowed the session to finish normally.
--version: v0.8.1), comparison run: successful responses and MCP process exit code 0, but stderr still contained the original message:The v0.12.1 stderr captures are empty, so there is no diagnostic excerpt to attach for those runs.
SHA-256 of the tested binaries
39f6a789cd858d7428561ac5afaefb9a47b018dcba0ad6fa41ae71a45e0ed65612375e6a39a31f003d776e54ef487640f9f59db7dbeee96973a9ee9eb18bc7bbFor precision, this historical artifact reports
0.8.1in the CLI but0.10.0inserverInfo.versionduring the handshake. The immutable v0.8.1 source hardcodes0.10.0in that response. The comparison refers to the artifact identified by the hash above.Evidence for the original warning
For the tested v0.8.1 binary, the evidence points to the optional startup update check rather than an indexed-project path:
initializehandler starts the update check.curlcommand using POSIX quoting and2>/dev/null, while the Windows wrapper uses_popen.cmd.exeduring initialization, while the MCP process itself exits with code0.Separate
cmd /dshell controls reproduced the same localized error with2>/dev/nullin 3/3 runs. With2>NUL, all 3/3 controls produced the expected output, empty stderr and exit code0. This isolates the redirection problem on this Windows installation; it does not establish that replacing the redirection alone fixes the remaining quoting or makes the HTTP request succeed.In v0.12.1, that update-check call is absent from the initialization handler. This is consistent with the clean startup results. I have not established the first release in which the call was removed.
Existing regression work and scope
I also read your follow-ups on #2213 and #2217 about retaining one canonical Windows startup guard. Rather than open a competing PR, I have left a focused cleanup review on #2217, based on its exact current head.
The proposed delta changes only the guard's temporary-directory ownership: one test file, 4 added lines and 2 removed, keeping cache/runtime as siblings under a single cleanup context. A controlled exception after a successful native initialize reproduced leftover runtime files on the unmodified guard; the candidate removed both directories while preserving the exception and normal daemon shutdown. It also passed 13 supplemental simulated-lifecycle checks and retained the historical Spanish-diagnostic rejection.
This is test maintenance, not a new production runtime fix. The existing stderr-reader join and English/Spanish checks are unchanged. I leave the choice between #2213/#2217 and the sign-off coordination to you and the contributor; the suggestion can follow whichever branch you agree to retain.
These are startup-specific findings, not a claim that every Windows environment or the full product CI has been validated. No client activation, existing-project indexing or global permission changes were required for these checks.
These were isolated stdio sessions, not validation of an installed client configuration. An earlier
could not load saved runtime settingsfailure under the sandboxed workspace was a separate pre-handshake condition; the successful runs used the private lab location without changing existing directory permissions.I hope this answers your question about the current binary and helps with the remaining regression coverage. If another startup condition would be useful to check, I'd be glad to help.
Thank you again for your work on the project and for taking the time to follow up.
DeusData commentedon Oct 25, 2026
Thank you, @Shinken009, for the two clean v0.12.1 sessions and the historical control, and for keeping the guard cleanup separate from a production fix. This answers the requested retest, so I’m removing awaiting-reporter. Sorry for the delay; selecting the canonical guard and closure follow-up are maintainer work, and I’ll follow up soon.
test(windows): keep MCP stdio guard cache and runtime under one temp …
test(windows): guard clean MCP stdio startup