Plugin (Windows): slm-launch.bat always runs the plugin venv — add SLM_LAUNCHER selection to match POSIX

[bgausden]

Problem

On macOS/Linux, slm-launch picks which slm binary runs the MCP server (SLM_LAUNCHER: auto by default, system, plugin, or a path), and under auto it prefers an slm already installed on PATH (8e914e4, "the plugin uses the SuperLocalMemory you already have").

The Windows launcher has no selection. plugin-src/scripts/slm-launch.bat always runs %CLAUDE_PLUGIN_DATA%\venv\Scripts\slm.exe, so on a Windows host that already has SLM installed (pip/pipx/npm, possibly running as a logon task via slm serve install):

• the plugin still needs its own venv, and so still needs Python ≥ 3.11 on PATH at SessionStart;
• the MCP server runs the plugin's copy of slm, which can be a different version from the daemon serving the same store — this is what the POSIX auto path warns about already.

slm serve start is already idempotent against a running daemon (commands.py), so a second daemon is not started today; the issue is which binary the launcher runs.

Proposed change

Port the POSIX selection from slm-launch L59–131 to slm-launch.bat, using where slm for PATH lookup. Leave "is a daemon already running?" to slm serve start rather than re-implementing liveness in batch. Mirror the change to plugin/scripts/slm-launch.bat.

Acceptance criteria

• With SLM_LAUNCHER unset and slm on PATH, slm-launch.bat runs slm serve start then slm mcp using the PATH binary, and never references venv\Scripts\slm.exe.
• With SLM_LAUNCHER unset and no slm on PATH, it runs %CLAUDE_PLUGIN_DATA%\venv\Scripts\slm.exe (today's behaviour).
• SLM_LAUNCHER=system with no slm on PATH exits non-zero with a message naming SLM_LAUNCHER=system.
• SLM_LAUNCHER=plugin with CLAUDE_PLUGIN_DATA unset exits non-zero with a message naming CLAUDE_PLUGIN_DATA.
• SLM_LAUNCHER=<path> runs that binary; a non-existent path exits non-zero naming the path.
• Under auto, when both a PATH slm and a plugin venv exist with different versions, a warning naming both versions is written to stderr (parity with POSIX).
• plugin/scripts/slm-launch.bat is byte-identical to plugin-src/scripts/slm-launch.bat.
• tests/test_plugin/test_wf_windows_crossplatform.py asserts the .bat handles SLM_LAUNCHER values auto, system, plugin and a path (structural, like the existing tests there).

Out of scope

• Skipping the venv bootstrap in ensure-venv.bat — separate issue, depends on this one.
• Remote daemons (Feature Request: Support remote SLM daemon in the Hermes native plugin #138).

---

This issue was generated by an AI assistant (Claude) from a read of the code at 5bfa47c, and reviewed by a human before posting.

[bgausden]

Two implementation details for the where slm lookup in the proposed change, one of which would break the port if missed:

1. .cmd / .bat shims need call. npm installs slm as slm.cmd (pip/pipx give slm.exe). In a batch file, invoking another .cmd/.bat without call transfers control and never returns, so

"%SLM_BIN%" serve start 1>&2
"%SLM_BIN%" mcp

stops after serve start whenever %SLM_BIN% is a shim. Use call for both lines — it is harmless for .exe.

2. where returns every match, one per line. Take the first, and use where.exe (in PowerShell, bare where is an alias for Where-Object; .exe makes the intent unambiguous in either shell):

set "SLM_BIN="
for /f "delims=" %%i in ('where.exe slm 2^>nul') do if not defined SLM_BIN set "SLM_BIN=%%i"
if not defined SLM_BIN ( rem fall back to the plugin venv under auto )

where finds slm.exe/slm.cmd/slm.bat via PATHEXT, exits with errorlevel 1 and an INFO: line on stderr when nothing matches (hence 2^>nul), and searches the current directory before PATH — the same order cmd uses for a bare slm, so resolving to the full path adds no new risk.

Suggested extra acceptance criteria:

• With only an npm-style slm.cmd on PATH, the launcher runs both serve start and mcp (i.e. every non-venv invocation of the resolved binary uses call).
• With two slm entries on PATH, the first one reported by where.exe is used.

---

This comment was generated by an AI assistant (Claude) and reviewed by a human before posting.

[bgausden]

Correction to the premise of this issue — the .bat launcher may never be invoked. Before porting logic into slm-launch.bat, it's worth confirming Claude Code runs it at all. From the documented behaviour, it likely doesn't:

• MCP server. .mcp.json sets "command": "${CLAUDE_PLUGIN_ROOT}/scripts/slm-launch" (no extension), and the header of slm-launch.bat says "Windows picks .bat automatically". A direct process spawn on Windows (CreateProcess, e.g. Node child_process.spawn without shell: true) neither executes batch files nor applies PATHEXT, so an extensionless path does not resolve to slm-launch.bat. This is the same mechanism behind plugin MCP servers using bare npx failing with spawn ENOENT on Windows ([BUG] Windows: plugin-shipped MCP servers using bare npx fail with spawn ENOENT (LSP fix from #17312 missed the MCP spawn path) anthropics/claude-code#58510).
• Hooks. Per the Claude Code hooks docs, a command hook's shell "defaults to "bash", or to "powershell" on Windows when Git Bash isn't installed" — there is no cmd option. So on Windows the SessionStart command "${CLAUDE_PLUGIN_ROOT}/scripts/ensure-venv.sh" either runs the .sh under Git Bash (where its POSIX assumptions — python3, venv/bin/ rather than venv\Scripts\ — don't hold) or is handed to PowerShell, which can't run a .sh. ensure-venv.bat is not referenced. test_wf_windows_crossplatform.py already notes Windows hook invocation as "future work".

This hasn't been verified on a Windows host. A cheap check: add a line writing a marker file to slm-launch.bat and ensure-venv.bat, install the plugin on Windows with and without Git for Windows, and see whether either marker appears.

If they are unreachable, porting SLM_LAUNCHER into the .bat (including the call / where.exe details in my previous comment) fixes nothing on its own. Directions worth weighing instead:

1. One script set, Windows-aware under Git Bash. Hooks already run .sh there; teach ensure-venv.sh / slm-launch about Scripts\ vs bin/ and python vs python3, and document Git for Windows as a requirement (or add a PowerShell fallback via a hook with "shell": "powershell").
2. .ps1 rather than .bat for any Windows-native path. Hooks can target PowerShell directly, Windows PowerShell 5.1 ships with every supported Windows, and it avoids batch pitfalls (call for shims, for /f, delayed expansion). The catch is MCP: powershell -NoProfile -ExecutionPolicy Bypass -File … can't share one .mcp.json with POSIX.
3. Point the MCP command at something CreateProcess can launch, e.g. move binary selection into Python so the command is an .exe on Windows.

Suggested acceptance criterion to add ahead of the existing ones:

• On a Windows host, with and without Git for Windows installed, the plugin's MCP server starts and the SessionStart bootstrap runs (verified by a marker or log line), with the mechanism documented in plugin-src/MCP_JSON_NOTES.md.

---

This comment was generated by an AI assistant (Claude) and reviewed by a human before posting.