Windows: painfully slow MCP (and CLI) — every process/identity op shells out to PowerShell/tasklist/reg/whoami

[laulpogan]

Reporter: Willard (Windows, raven-kettle). MCP usage on Windows is painfully slow.

Root cause

On Windows, every process/identity primitive in src/platform.rs + src/session.rs spawns a subprocess, and each cold-start is ~0.5–2s (PowerShell especially). The Unix equivalents are a /proc read or kill -0 (microseconds). There is no Win32 API dependency — it's all shell-outs:

fn	Windows impl	hot path
session::parent_pid	powershell.exe Get-CimInstance Win32_Process per hop	session resolution at MCP/CLI startup
platform::process_alive (pid_is_alive)	tasklist.exe /FI	per-pid liveness in daemon_liveness
platform::find_processes_by_cmdline	powershell.exe Get-CimInstance (enumerates ALL procs)	daemon_liveness → wire_status, doctor
platform::pid_cmdline	powershell.exe Get-CimInstance	status/supervisor
platform::machine_id_raw	reg.exe query	identity enroll
platform::os_user_id_bytes	whoami.exe	identity enroll

Two dominant costs

1. MCP startup pid-walk. resolve_session_key → claude_code_session_from_pidfile walks the parent-PID chain (≤16 hops), and on Windows each hop is a PowerShell Get-CimInstance cold-start. The code comment notes the MCP server doesn't inherit CLAUDE_CODE_SESSION_ID on some platforms and Windows Claude Code passes the literal ${CLAUDE_CODE_SESSION_ID} (rejected by valid_session_key), so the env checks miss → the PowerShell walk always runs at startup. If the ~/.claude/sessions/<pid>.json pidfile isn't found quickly, it walks the full 16 hops = up to ~16–25s. Felt on every MCP (re)connect.
2. wire_status / any liveness-touching call → ensure_up::daemon_liveness → one PowerShell CIM (find_processes_by_cmdline) plus a tasklist.exe per session daemon pid (pid_is_alive × N sessions). Multi-second per call on a multi-session box.

Immediate workaround (no code change)

Set a static session key in the wire mcp server's env block in the Windows Claude Code MCP config — this makes resolve_session_key hit the cheap env path and skip the PowerShell parent-pid walk entirely:

"wire": { "command": "wire", "args": ["mcp"], "env": { "WIRE_SESSION_ID": "willard-win" } }

(Any stable non-empty literal. Trade-off: pins this host to one wire identity instead of per-session — fine for a single user.) This kills the startup tax; the wire_status liveness cost is separate.

Proper fix

Replace the Windows subprocess shell-outs with native Win32 calls (no spawn) via the windows crate under [target.'cfg(windows)'.dependencies]:

• parent_pid + find_processes_by_cmdline: one CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS) + Process32FirstW/NextW (gives ppid + exe name), walk in-memory — zero spawns.
• process_alive: OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) + GetExitCodeProcess (STILL_ACTIVE).
• machine_id_raw: RegOpenKeyEx/RegQueryValueEx for MachineGuid instead of reg.exe.
• os_user_id_bytes: GetTokenInformation(TokenUser) instead of whoami.exe.
• pid_cmdline (rare): keep PowerShell or PEB-read via NtQueryInformationProcess.

Lighter interim if avoiding the dep: collapse the per-hop parent_pid PowerShell into a single Get-CimInstance call returning all (ProcessId, ParentProcessId) pairs, walk in-memory (16 spawns → 1); and short-TTL-cache daemon_liveness.

Note

Diagnosed from macOS — cannot compile/run Windows code here (no windows target). Needs a Windows build + verify (Willard). A WIRE_DIAG=1 trace on Willard's box would confirm startup-vs-per-call split.

🤖 Generated with Claude Code

[laulpogan]

Cross-links (found after filing):

• Parent: Windows: status/up/doctor + upgrade hang, SessionStart wait-loop pileup (254 procs), and wire_send peer_unknown on VERIFIED peer #284 (closed). Its fix Windows: status/up/doctor + upgrade hang, SessionStart wait-loop pileup (254 procs), and wire_send peer_unknown on VERIFIED peer #284.1 / PR fix(platform): bound Windows shell-outs so wire status/up/doctor can't hang (#284.1) #298 bounded the Windows Get-CimInstance/tasklist shell-outs with run_with_timeout — that stopped them hanging on a wedged CIM call, but they're still inherently slow (subprocess cold-start). Windows: painfully slow MCP (and CLI) — every process/identity op shells out to PowerShell/tasklist/reg/whoami #350 is the deeper follow-up: stop spawning at all (native Win32), not just time-bound the spawn. So Windows: painfully slow MCP (and CLI) — every process/identity op shells out to PowerShell/tasklist/reg/whoami #350 is the next layer on Windows: status/up/doctor + upgrade hang, SessionStart wait-loop pileup (254 procs), and wire_send peer_unknown on VERIFIED peer #284, not a dup.

• Interacts with Two identities per session: MCP server vs SessionStart-hook WIRE_HOME bind to different DIDs → CLI monitor/pull/tail blind to MCP-paired peers #351 (open). Two identities per session: MCP server vs SessionStart-hook WIRE_HOME bind to different DIDs → CLI monitor/pull/tail blind to MCP-paired peers #351 reports the MCP server and the SessionStart hook binding to different identities on Windows. That changes the workaround here: setting WIRE_SESSION_ID on only the MCP server pins MCP to one identity while the CLI/hook resolves to another — which would entrench Two identities per session: MCP server vs SessionStart-hook WIRE_HOME bind to different DIDs → CLI monitor/pull/tail blind to MCP-paired peers #351's split. Corrected workaround: set the same WIRE_SESSION_ID (or WIRE_HOME) for BOTH the MCP server env AND the CLI/hook environment, so both halves resolve to one identity. That fixes the startup pid-walk perf here AND the identity split in Two identities per session: MCP server vs SessionStart-hook WIRE_HOME bind to different DIDs → CLI monitor/pull/tail blind to MCP-paired peers #351 in one move.

Net: #350 (eliminate the spawns) + #351 (unify MCP/CLI identity) are two facets of the same Windows session-resolution surface; the native-Win32 rewrite + a single consistent session key address both.