install.ps1 accepts a recorded MCP command that exists but does not work

[MongLong0214]

Raised from a public thread on r/ClaudeCode, where kantorcodes1 also proposed the fix evaluated below.

install.ps1 decides whether an existing commitlore MCP entry is healthy by asking whether its recorded path exists.

# install.ps1:881
if ($existingCmd -ne '' -and -not (Test-Path -LiteralPath $existingCmd)) {
    Add-Skipped $AgentName "$ConfigPath names commitlore at ""$existingCmd"", which does not exist -- left unchanged, so this host has no working server; remove that entry and rerun to wire it to $dest"
    return
}
Add-Skipped $AgentName "$ConfigPath already mentions commitlore -- left unchanged"

Two states, one of them silent:

state	what the installer says
recorded path is gone	names the dead path, says the host has no working server, gives the remedy
recorded path exists but the server does not start	already mentions commitlore -- left unchanged

The first is a good diagnostic. The second covers a recorded command that is a stale build, a wrong-version bundle, a file that is not executable, or an entry pointing into another installation — every one of which leaves the host with a config that looks wired and a server that never answers. Existence is not evidence of function, and the installer's own message reads as reassurance.

The proposed fix, and why it is smaller than it looks

i'd make install.ps1 reuse the shared MCP health check instead of path existence if the latency is tolerable

Adopted in substance — and the shared check already exists and is already used on this exact decision, by the enumeration the CLI runs:

// src/commands/installer-hosts.ts:149
const problem = await probeMcp(existing.command, existing.args);
// :210  "...to fix, so \"already installed\" is not success."

src/core/mcp-probe.ts performs a real initialize handshake and checks the advertised tool set (MCP_READ_TOOLS, MCP_CAPTURE_TOOLS), so a present-but-broken command fails there rather than passing.

So the divergence is not that the project checks existence — it is that install.ps1 duplicates host wiring and its copy is the one that never learned to probe. Adding a probe to the PowerShell side would mean writing a second implementation of a check that already exists, which is how the two sides drifted in the first place (#697 was the same shape: a host both sides handled, one missing a step).

The fix is therefore #691's step 2 — delete install.ps1's wiring blocks and let the enumeration do it — and this issue is the user-visible consequence of not having done it yet. They should close together.

Latency, since it was the stated condition

Measured on this machine from doctor --json timings, where unattended-initiator is a full probeMcp handshake through the installed launcher:

mcp-lifecycle          23 ms
mcp-runtime-identity   34 ms
unattended-initiator  337 ms   <- the probe

~0.34 s per probe against a 15 s ceiling (DEFAULT_INITIALIZE_TIMEOUT_MS). Hosts that are absent short-circuit at detection and are never probed, so the realistic added cost is a few tenths of a second per present host. That is tolerable by any reading.

The number is macOS with a warm cache; Windows process start is slower and this has not been measured there. It bounds the order of magnitude, not the Windows figure.

Not covered by existing issues

#693 was the hook recording a version-pinned path, #695 the upgrade not reaching a host. Both are about a path that becomes wrong. This is about a path that is right and a server that does not run — the state neither of those checks distinguishes.

[MongLong0214]

Withdrawing this. The code I quoted never runs.

# install.ps1:817-820
$hostSummary = & $dest installer-hosts --wrapper $dest --data-root $dataRoot --home $env:USERPROFILE --json
$hostExit = $LASTEXITCODE
$hostSummary | Write-Output
exit $hostExit          # <- unindented, unconditional

Everything from line 822 to the end of the file — 350 lines, including the Test-Path check at :881 I filed this about — sits after that exit. It has been unreachable since 0d60c75 (#624, 2026-08-14). A Windows install has not taken that path for three days.

So the behaviour I described does not occur. installer-hosts does the wiring, and it probes: src/commands/installer-hosts.ts:149 runs probeMcp(existing.command, existing.args) against an existing entry, with :210 recording that "already installed" is not success. kantorcodes1's suggestion is already the shipped behaviour — not a change to make, which is a better answer than the one I gave.

I read a line, asserted what it does, and did not check whether control flow reaches it. The deciding artifact was the exit four hundred lines above, not the line itself.

What survives, and where it goes

Nothing user-facing. What survives is that the dead block answers questions wrongly, which is #691's exact thesis — its body notes two people who read that code as authoritative on the same day. I am the third, and I filed a public issue on the strength of it.

Recorded on #691. The measured probe latency (~0.34 s per present host, against a 15 s ceiling) is recorded there too, since it is the number anyone evaluating the enumeration path would want and it remains true.