Windows: `install` reports "Detected agents: (none)" when the profile path contains non-ASCII characters — agent detection still uses narrow stat() (v0.10.8)

[iBen-creator]

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

1. 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).
2. Confirm %USERPROFILE%\.claude\ and %USERPROFILE%\.claude.json exist.
3. 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=claude

That 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).ShortPath

Suggested 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.