Repository navigation
Description
Version
codebase-memory-mcp 0.10.8
Platform
Windows 11 Pro x64 (10.0.26200)
Install channel
GitHub release archive / install.ps1
Binary variant
standard
What happened, and what did you expect?
install completes successfully but configures no agent at all — it prints Detected agents: (none) — even though Claude Code is installed and both %USERPROFILE%\.claude\ and %USERPROFILE%\.claude.json exist.
The cause is the Windows username containing a non-ASCII character. My profile is C:\Users\İgal (İ = U+0130, LATIN CAPITAL LETTER I WITH DOT ABOVE).
Expected: agents whose config directories exist should be detected and configured regardless of whether the profile path is representable in the process ANSI code page.
This is the same root cause as #1715 (narrow stat() on Windows cannot see paths with characters outside the ANSI code page), but it is a different code path. #1715 was fixed for the daemon session root in 9d4ac2b / #1876; agent detection was not covered and is still narrow on main (checked at 055fbb7):
/* src/cli/cli.c — Agent detection */
static bool dir_exists(const char *path) {
struct stat st;
#ifndef _WIN32
return lstat(path, &st) == 0 && S_ISDIR(st.st_mode);
#else
return stat(path, &st) == 0 && S_ISDIR(st.st_mode); /* <-- narrow */
#endif
}cbm_detect_agents() routes every agent through dir_exists(), so on such a profile all of them silently come back false — not just Claude Code.
There is currently no escape hatch
--clients=claude does not help: cli_clients_apply_selection() only clears the flags that were not requested and never force-includes one, so it cannot override a failed detection.
for (size_t i = 0; i < CLI_CLIENT_COUNT; i++) {
if (!wanted[i]) {
*(bool *)((char *)detected + CLI_CLIENTS[i].offset) = false;
}
}That matches #1798 ("install --clients=<token> accepted but inert"), which is closed but still reads as inert on main.
Reproduction
- On Windows, use an account whose profile path contains a character outside the active ANSI code page (e.g.
C:\Users\İgal; CJK reproduces the same way). - Confirm
%USERPROFILE%\.claude\and%USERPROFILE%\.claude.jsonexist. - Run
codebase-memory-mcp install -y --force.
Result:
Detected agents: (none)
Added C:/Users/İgal/.local/bin to the current-user PATH
Install complete.
No MCP entry, no skill, no agents, no hooks are written.
Workaround (verified)
Run install with HOME pointed at the profile's 8.3 short name, which is pure ASCII and resolves to the same directories (cbm checks HOME before USERPROFILE):
$env:HOME = 'C:\Users\GAL~1' # 8.3 short name of C:\Users\İgal
codebase-memory-mcp install -y --force --clients=claudeThat produces the correct, complete result:
Detected agents: Claude-Code
Claude Code:
skills: 1 installed
agent: C:/Users/GAL~1/.claude/agents/codebase-memory-scout.md
agent: C:/Users/GAL~1/.claude/agents/codebase-memory.md
agent: C:/Users/GAL~1/.claude/agents/codebase-memory-auditor.md
mcp: C:/Users/GAL~1/.claude.json
hooks: PreToolUse Grep/Glob search augmentation + PostToolUse Read coverage (non-blocking)
hooks: SessionStart / SubagentStart reminders
The 8.3 short name is discoverable programmatically, so it could also serve as an internal fallback:
(New-Object -ComObject Scripting.FileSystemObject).GetFolder($env:USERPROFILE).ShortPathSuggested fix
Make dir_exists() (and any sibling existence checks used by detection) go through the wide API on Windows — cbm_utf8_to_wide() + _wstat/GetFileAttributesW. The conversion helper already exists in src/foundation/compat_fs.c and is what 9d4ac2b used for the session-root path, so this should be a small, consistent follow-up to that fix.
Note
The failure is silent — install exits 0 and reports success. Since a user with a non-ASCII profile gets a completely unconfigured agent from a "successful" install, a warning when detection finds nothing at all might be worthwhile independent of the encoding fix.
Activity
DeusData commentedon Oct 19, 2026
Thank you for the non-ASCII profile example and for separating agent detection from the earlier session-root fix. The successful ASCII-path comparison is useful evidence. Detection and explicit client selection still need verification; no released resolution is confirmed here.
test(cli): create the non-ASCII Windows profile through the wide API
DeusData commentedon Oct 25, 2026
Thank you for the profile-path comparison. Windows agent detection and explicit client selection still need maintainer verification. Sorry for the delay; I’ll follow up soon.