Windows: claude-cli fallback and opencode reuse probing fail with spawn EINVAL (.CMD shims)

[StarChen-Cycler]

Environment

• @liustack/modlens 3.16.4 (installed as the dsh plugin), Windows, Node v23.11.1

Problem

On Windows the CLI-based providers / reuse probing fail to spawn, so the claude-cli fallback (and the opencode reuse probe) never work:

• doctor Reuse section reports: opencode: no vision models, via none, 62ms, error: spawnSync C:\...\opencode.CMD EINVAL
• When a read falls back it reports: claude-cli: spawn EINVAL

Both CLIs are installed and on PATH, but on Windows they resolve to .CMD shims (e.g. claude.CMD, opencode.CMD). Spawning a .cmd file directly with Node's spawnSync/spawn (without going through the shell) fails with EINVAL on Windows — which matches the observed errors exactly.

Expected

• The claude-cli provider should run on Windows when claude is on PATH.
• Reuse discovery should be able to probe opencode on Windows.

Possible fixes: spawn with shell: true on win32 (or explicitly cmd.exe /c), or resolve the shim to the underlying .exe/.js before spawning.

Notes

• findOnPath succeeds (the binaries are found — the failures are at spawn time), so this is the spawn step, not path discovery.
• Reporting with evidence only; no patch submitted for this one.

[StarChen-Cycler]

Self-note after filing: this is a follow-up to #31 (Windows spawn EINVAL, closed after the 3.16.2 fix). Still reproducing on 3.16.4 in two places: (1) claude-cli fallback → spawn EINVAL — PATH resolves to \claude.CMD\ (pnpm), which matches the still-unhandled native .exe shim shape described in #31's follow-up (shim points at a native claude.exe, resolver only accepts node/python interpreters); (2) \doctor\ Reuse section → \opencode: ... spawnSync C:\...\opencode.CMD EINVAL\ — the reuse probe hits the same class. Keeping this open as a current-version tracker for both; happy to have it closed in favor of #31 if preferred.