detectOne() ran the `--version` probe via execFile INSIDE a `new Promise`
executor but only handled the async error path. execFile can throw
SYNCHRONOUSLY (e.g. `spawn EPERM` when child-process creation is restricted),
and a synchronous throw in a Promise executor REJECTS the promise. Because
detectLocalAgents() used Promise.all, one agent's spawn failure rejected the
whole batch → GET /api/agents/local/detect returned 500 → the Settings "Local
Agents" card silently rendered "0/0 installed" even though all CLIs were on PATH.
- detectOne: wrap execFile in try/catch. The binary was already found on PATH
(resolveBin returned a path) so it IS installed; on a sync throw we resolve
installed:true with version '?' and filesystem-based auth, never rejecting.
- detectLocalAgents: Promise.allSettled instead of Promise.all, so one agent's
failure degrades to "not installed" for that agent only, never the batch.
Verified: /detect returns 200 with claude/codex/hermes installed+ready.
Typecheck clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Detection reported installed npm-global agents (Claude Code, Codex) as
'binary not found on PATH' on Windows, and an authed Hermes desktop as
'NOT AUTHED'. Two root causes:
1. resolvePath() used POSIX-only 'command -v'/'which', and
execFile/spawn('claude', ...) cannot resolve npm's .cmd shims via
PATHEXT -> ENOENT -> installed:false. Add resolveBin() (where.exe on
Windows, preferring .exe > .cmd > .bat) and route detection + both
spawn call sites through the resolved path.
2. Hermes desktop on Windows stores its login under %LOCALAPPDATA%\hermes not ~/.hermes/. Add localAppData() and check both (presence-only).
Windows .cmd shims are launched via a new spawnAgent() helper that invokes
cmd.exe with an argv ARRAY (shell:false) instead of shell:true, so the
untrusted prompt is never re-parsed by cmd.exe -> no command-injection surface.
No new deps; typecheck clean.
