Windows: MCP server refuses to start when cwd contains non-ASCII (CJK) characters — "daemon session context was rejected" (v0.10.5 + v0.10.6)

Summary

On Windows, codebase-memory-mcp fails at MCP startup with codebase-memory-mcp: daemon session context was rejected whenever the current working directory contains non-ASCII characters (e.g. Chinese/CJK). The same binary, same daemon, same environment works fine from any ASCII-only cwd.

This is a startup-blocking bug: the MCP client (Kimi Code CLI in my case, but any client that spawns the server with the project dir as cwd) cannot use the server at all for projects located under a non-ASCII path. It is distinct from the previously reported non-ASCII issues (#571 project naming, #700 / #357 indexing pipeline, #1165 env-var decoding, #1240 git discovery) — here nothing ever starts; no indexing is even attempted.

Environment

codebase-memory-mcp v0.10.5 (global install at C:/Users/Administrator/.local/bin/codebase-memory-mcp.exe)
Reproduced identically on v0.10.6 (fresh download of codebase-memory-mcp-windows-amd64.zip from the v0.10.6 release, tested with an isolated CBM_CACHE_DIR/CBM_RUNTIME_DIR to avoid the version-cohort conflict with the running 0.10.5 daemon)
Windows 11 (x64), reproduced from Git Bash; the original failure was reported by the MCP client (Kimi Code CLI) spawning the server directly
Working directory containing CJK characters, e.g. E:\YC\Project\电商设计

Reproduction

Send a plain MCP initialize over stdio with cwd set to a CJK path:

cd "E:/YC/Project/电商设计"   # any cwd containing non-ASCII characters
printf '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}\n' \
  | CBM_CACHE_DIR="C:/Users/Administrator/.codebase-memory-mcp-cache" \
    CBM_RUNTIME_DIR="C:/Users/Administrator/.codebase-memory-mcp-runtime" \
    codebase-memory-mcp.exe

Actual (CJK cwd):

codebase-memory-mcp: daemon session context was rejected

Control — ASCII cwd, everything else identical (C:/Users/Administrator, E:/YC/Project):

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","serverInfo":{"name":"codebase-memory-mcp","version":"0.10.5"}, ... }}

Additional controls:

A freshly created empty directory with a Chinese name (.../cbm-测试中文) fails the same way — the project content is irrelevant; only the cwd string matters.
Subdirectories below the CJK segment (E:/YC/Project/电商设计/design) fail too.
On v0.10.6 the failing case logs version_cohort.claimed_unheld and then the same rejection, so the session-context rejection happens after the daemon is reached — i.e. the daemon receives the handshake but rejects the session context derived from the cwd.

Suspected cause

The daemon session context appears to incorporate the client's working directory, and something in that registration/verification path mishandles non-ASCII (likely the same UTF-8 → ANSI / lossy-decode family as #1165, this time applied to the cwd rather than to env vars). Whatever is hashed or compared then doesn't match, and the daemon rejects the session.

Impact

Any Windows (and possibly other-platform) user whose project lives under a non-ASCII directory — very common for CJK locales — gets a hard startup failure of the whole MCP server. The error message gives no hint that the cwd is the problem, so it is nearly impossible to self-diagnose (it looks like a daemon corruption issue; I initially suspected the lock files under CBM_RUNTIME_DIR).

Two cheap improvements alongside the encoding fix:

Include the offending value (or at least its sanitized form) in the rejection message, e.g. daemon session context was rejected (cwd=...).
Mention the cwd restriction in the Windows install/troubleshooting docs until fixed.

Workaround

Launch the MCP client from an ASCII-only working directory, or create an ASCII junction to the project and open the junction path instead.

Project name strips non-ASCII (CJK) characters from path, resulting in truncated/unrecognizable names #571 (project name strips non-ASCII)
Windows: CBM_CACHE_DIR / CBM_ALLOWED_ROOT are lossily decoded — every non-ASCII char becomes U+FFFD, so the server silently uses a different path (v0.9.0) #1165 (env vars lossily decoded → U+FFFD)
Windows: Git discovery fails for valid repository at Unicode path #1240 (git discovery fails at Unicode path)
Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700 / Windows non-ASCII path support issue in indexing pipeline #357 (indexing pipeline at non-ASCII paths)

Still reproduces on v0.10.8 (Windows 11 x64), confirmed today with a controlled A/B test:

Same binary, same config, same spawn path (cmd.exe wrapper → codebase-memory-mcp.exe, stdio MCP initialize):
- cwd E:\YC\Project\codeg (ASCII) → handshake OK, serverInfo returned
- cwd E:\YC\Project\电商设计 (CJK) → codebase-memory-mcp: daemon session context was rejected, process exits immediately
Positive control: index_repository with a CJK repo_path works fine on the same build (project indexed, non-ASCII bytes hex-encoded into the derived project name), so the non-ASCII intolerance is specific to the session-root derivation, not the indexing pipeline.

Workaround that holds up in production here: a cmd wrapper that detects a non-ASCII cwd (echo(%CD%| findstr /r /c:"[^ -~]") and cd /d to a private ASCII session directory before launching the exe — same pattern as the profile-root fallback. MCP handshake then succeeds from CJK project dirs; tools are unaffected since they take explicit project arguments.

Happy to test a fix build if useful.

Thank you for retesting this on v0.10.8 with a controlled ASCII versus CJK working-directory comparison, and for offering to test a fix build. That keeps the report current and materially narrows the failure to session-root handling rather than repository indexing.

We need more time to review the Windows encoding and daemon session-context path before proposing a fix. I have marked this as a high-priority startup bug, and the issue will remain open while we investigate it. Thank you for the precise follow-up and the practical workaround.

@LumePure

Thank you so much, @LumePure — this was a model report: the isolated CBM_CACHE_DIR/CBM_RUNTIME_DIR setup, the ASCII-vs-CJK A/B with everything else identical, the empty cbm-测试中文 control proving only the cwd string mattered, and the re-test on v0.10.8 saved us a lot of guesswork.

You were right about the layer: the daemon validated the client's session root with a plain stat() on the canonicalised path, which on Windows goes through the ANSI CRT and cannot represent CJK segments — so a valid directory looked non-existent and the session context was rejected. Fixed on main in 9d4ac2b ("accept Unicode session roots on Windows", by @ertankucukoglu, #1876; pinned by daemon_application_accepts_utf8_session_context_root), hardened by the follow-ups c1b9c45 and 9846c3f (#2070: session roots compare separator-equivalently without respelling the policy root).

Verified today on a real Windows machine against the current main build with your exact reproduction (stdio initialize from …\电商设计, …\电商设计\design and a fresh …\cbm-测试中文, isolated cache and runtime dirs): every case returns serverInfo, the ASCII control is unchanged, and the daemon log shows mcp.request method=initialize status=ok for each. One honest limit: the verification machine is arm64, your host is x64; the fix is UTF-8 path handling, which does not depend on the architecture.

Ships in v0.10.9. If it recurs after upgrading, please reopen with the initialize stderr and <CBM_CACHE_DIR>/logs/cbm-daemon.log. Thanks again — also for the cmd-wrapper workaround you shared for others in the meantime.

Adding a non-CJK data point on v0.10.8 (Windows 11 x64, uk-UA system locale, ACP 1251 / OEMCP 866), since the regression test mentioned above is CJK-based.

Same rejection with a Cyrillic working directory, spawned by Cursor (3.20.x), which starts stdio MCP servers with the workspace folder as cwd:

cwd C:\Users\<user>\Desktop\Бекапи\<project> → codebase-memory-mcp: daemon session context was rejected, exit code 1, zero bytes on stdout
fresh empty %TEMP%\тест_cbm → same rejection
C:\Users\<user>, C:\Users\<user>\Desktop, %TEMP%\test_cbm (ASCII) → initialize returns serverInfo
identical binary and environment in every case; reproduces both with a cold daemon and with a daemon already serving another session; CBM_LOG_LEVEL=debug adds nothing to stderr
cbm-daemon.log (cold case): daemon.start followed immediately by daemon.runtime_stopping reason=last_committed_client_disconnected, no mcp.request method=initialize; no daemon-conflicts.ndjson is written
positive control as in the earlier comment: the same project under the Cyrillic path indexes and queries fine via index_repository with an explicit repo_path (the Cyrillic segment is hex-encoded in the derived project name)

One detail that may matter for the fix: on this machine the Cyrillic characters are representable in the ANSI code page (1251), so the failure is not limited to "characters the ACP cannot represent" — a UTF-8 session root pushed through the narrow CRT is mis-decoded even when every character exists in the ACP. It might be worth adding a non-CJK case (e.g. Cyrillic on a cp1251 host) to daemon_application_accepts_utf8_session_context_root before v0.10.9 ships.

Workaround for Cursor users (Cursor's mcp.json has no cwd field): point command at a small .cmd wrapper that runs cd /d "%USERPROFILE%" and then launches the binary. The handshake succeeds and all tools keep working because they take an explicit project. VS Code is unaffected here because its user-level server is launched from the home directory.

Thank you for the additional Cyrillic/cp1251 comparison. Your point about UTF-8 being misinterpreted by a narrow CRT call even when the characters exist in the ANSI code page is important.

The fix in 9d4ac2b replaces the session-root stat check with cbm_path_info_utf8. I verified that this commit is included in the now-published v0.11.0 release: https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.11.0. Our earlier comment forecast v0.10.9; the actual shipping version is v0.11.0.

The latest reproduction here still uses v0.10.8, so it does not yet show a regression after that fix. Could you retest the same empty Cyrillic-directory control with v0.11.0? We have not independently tested your exact locale/architecture combination in this triage pass. If it still fails there, please reply with sanitized startup output and we should reopen it. Thanks again for isolating the encoding boundary.

Navigation Menu

Repository navigation

Windows: MCP server refuses to start when cwd contains non-ASCII (CJK) characters — "daemon session context was rejected" (v0.10.5 + v0.10.6) #1715

Summary

Environment

Reproduction

Suspected cause

Impact

Workaround

Related

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Windows: MCP server refuses to start when cwd contains non-ASCII (CJK) characters — "daemon session context was rejected" (v0.10.5 + v0.10.6) #1715

Description

Summary

Environment

Reproduction

Suspected cause

Impact

Workaround

Related

Activity

LumePure commented on Aug 24, 2026

DeusData commented on Aug 24, 2026

DeusData commented on Sep 7, 2026

Teroter commented on Sep 15, 2026

DeusData commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions