[v0.9.0] install.ps1 expects codebase-memory-mcp.payload.exe missing from release archive

[GaboDot]

Version

codebase-memory-mcp v0.9.0

Platform

• OS: Windows 11 Pro
• Version: 10.0.26200
• Architecture: 64-bit (amd64)
• Build: 26100.1.amd64fre.ge_release.240331-1435

Install channel

GitHub release archive / install.ps1

Binary variant

standard

What happened, and what did I expect?

The install.ps1 script fails with the following error:

error: unsafe or incomplete release archive: archive must contain exactly one codebase-memory-mcp.payload.exe

The script validates that the zip contains 5 files:

• codebase-memory-mcp.exe
• codebase-memory-mcp.payload.exe
• LICENSE
• install.ps1
• THIRD_PARTY_NOTICES.md

However, the actual codebase-memory-mcp-windows-amd64.zip from v0.9.0 only contains 4 files:

• codebase-memory-mcp.exe
• LICENSE
• install.ps1
• THIRD_PARTY_NOTICES.md

The codebase-memory-mcp.payload.exe file is missing from the release archive.

Reproduction

1. Run install.ps1 on Windows
2. Script downloads codebase-memory-mcp-windows-amd64.zip
3. Script validates zip contents
4. Fails with archive must contain exactly one codebase-memory-mcp.payload.exe

Expected behavior

The release archive should contain codebase-memory-mcp.payload.exe as expected by the install script, OR the install script should be updated to match the v0.9.0 archive structure.

Root cause analysis

PR #1139 ("feat: coordinate concurrent CBM sessions") introduced a launcher/payload architecture for Windows. The install.ps1 on main branch expects this new structure, but the v0.9.0 release was published without including codebase-memory-mcp.payload.exe in the archive.

Suggested fix

Either:

1. Re-release v0.9.0 with the payload.exe included, OR
2. Update install.ps1 to handle the v0.9.0 archive structure, OR
3. Publish v0.9.1 with the complete archive

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[RithvikReddy0-0]

The v0.9.0 archive isn't missing a file : install.ps1 on main moved ahead of the latest release.

install.ps1 hardcodes a five-entry bundle contract:

$WindowsArchiveNames = @($BinName, $PayloadName, "LICENSE", "install.ps1", "THIRD_PARTY_NOTICES.md")

and downloads from:

$BaseUrl = ... else { "https://github.com/$Repo/releases/latest/download" }

Nothing couples the two. The script tracks main; the archive tracks the latest published release. Any change to the archive shape on main therefore breaks the documented Windows path (irm .../main/install.ps1) until the next release ships. Users running the install.ps1 bundled inside a release archive get a matched pair and are unaffected, only the raw-from-main path breaks, which is the one the README and docs site recommend.

Dated evidence that this is recent: the installer transcript in #1180 (filed ~Jul 19) runs main's install.ps1 against the same v0.9.0 archive on Windows amd64 and succeeds :

Downloading codebase-memory-mcp-windows-amd64.zip...
Checksum verified.
Extracting...
Installed: codebase-memory-mcp 0.9.0

Same script, same release, same platform, no allowlist failure. So the four-file archive was acceptable to main a few days ago and is not now; the archive itself never changed.

One thing worth separating in the error path: checksum verification runs before namespace validation and passes. By the time the allowlist check fails, the script has already proven the archive is the genuine published artifact, a tampered one would have exited at CHECKSUM MISMATCH. Reporting it as unsafe or incomplete release archive conflates "tampered" with "older bundle shape," which are opposite diagnoses needing opposite user responses. Worth a distinct, actionable message for the authenticated-but-stale case (still exiting non-zero, nothing relaxed).

The mismatch resolves itself once 0.9.1 ships with the launcher/payload archive, so the durable fix is probably a release-archive contract check in CI: extract the published archive, run the validation block from main's install.ps1 against it, fail the release job on divergence. That closes the class rather than this instance.

Happy to open a PR for the CI check, the error-path split, or both whichever fits. Is install.sh structured the same way (latest-release download against a hardcoded manifest)? If so the check should cover both platforms.

[dyy1991]

still happening

[DeusData]

Confirmed. The current install.ps1 consumes the latest release asset while enforcing the newer five-file payload contract, but the v0.9.0 Windows archive has the older four-file layout. A passing checksum only proves that the older archive is authentic; it does not make that archive compatible with the newer installer. We should keep the allowlist fail-closed and make the error distinguish authenticated-but-incompatible release layout from tampering. The Unix installer does not use this payload-launcher contract, but release-to-installer compatibility still needs coverage on every platform. High priority for 0.9.1-rc under #394.