install.ps1 rejects v0.9.0 windows-arm64 UI archive: 'archive must contain exactly one codebase-memory-mcp.payload.exe'

[skbs-eng]

Title

install.ps1 rejects v0.9.0 codebase-memory-mcp-ui-windows-arm64.zip — "archive must contain exactly one codebase-memory-mcp.payload.exe"

Environment

• OS: Windows 11 on ARM64
• Installer: install.ps1 from main branch (raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1)
• Release: v0.9.0 (latest)
• Command:

  Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
  Unblock-File .\install.ps1
  .\install.ps1 --ui --skip-config

Output

codebase-memory-mcp installer (Windows)
  variant: ui
  arch:    arm64
  target:  C:\Users\srini\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe

Downloading codebase-memory-mcp-ui-windows-arm64.zip...
Checksum verified.
error: unsafe or incomplete release archive: archive must contain exactly one codebase-memory-mcp.payload.exe

Expected

Archive passes layout validation, installer stages the binary and the bundled install.ps1 to the target directory, and exits 0.

Actual

Installer exits non-zero after the layout check. The downloaded archive contents are:

codebase-memory-mcp.exe      274,818,560 bytes
install.ps1                       6,450 bytes
LICENSE                           1,128 bytes
THIRD_PARTY_NOTICES.md          570,451 bytes

I confirmed the windows-amd64 UI archive has the same flat layout (codebase-memory-mcp.exe at the root, not *.payload.exe), so this is consistent across Windows builds, not specific to ARM64.

Root cause (observed)

The installer archive-layout check expects a *.payload.exe wrapper, but the actual release zips for v0.9.0 Windows builds do not contain that wrapper — only a flat codebase-memory-mcp.exe. The checksum itself passes; the failure is purely the layout assertion.

Workaround

--skip-config is already requested, so manually extracting the archive into %LOCALAPPDATA%\Programs\codebase-memory-mcp\ and launching codebase-memory-mcp.exe --ui=true --port=9749 works fine. The binary itself is healthy (0/72 on VirusTotal, UI responds 200 on http://localhost:9749).

Suggested fix

Either:

1. Update the layout check in install.ps1 to accept codebase-memory-mcp.exe (or codebase-memory-mcp-ui.exe) at the archive root as a valid Windows layout, or
2. Rebuild the Windows release zips to include the *.payload.exe wrapper that the current check requires.

Option 1 is preferable — the wrapper name appears to be a leftover from a self-extracting-installer design and adds no value when the binary is already static.

SHA-256

• windows-arm64 binary from release page: a299150de19bb4da9a880a6139757076bd4139b2f6a7e7cf31bdd431d53aed9c
• installer-printed SHA matched the downloaded archive before the layout check rejected it.

[skbs-eng]

cc @DeusData/maintainers — filing under bug + windows + priority/normal per the v0.9.0 release regression. Label application from my side is blocked (403 "Must have admin rights to Repository"), so this is a heads-up rather than a self-triage.

For context: this blocks fresh --ui installs on Windows ARM64 and Windows x64. Workaround (extract zip manually into %LOCALAPPDATA%\Programs\codebase-memory-mcp\, run codebase-memory-mcp.exe --ui=true --port=9749) is end-to-end verified: SHA-256 a58c9696267ac96e04d82c874c9e7637202986c33946680a1f5bc55ab4a83cf9 matches checksums.txt for the v0.9.0 codebase-memory-mcp-ui-windows-arm64.zip asset.

Suggested fix in the body (option 1: accept codebase-memory-mcp.exe at archive root) is a 3-line change in install.ps1 and removes the *.payload.exe wrapper-name coupling entirely.

[DeusData]

Thanks for the detailed archive inventory and checksum validation.

This is fixed on current main by a54ea95. Windows releases now use a single codebase-memory-mcp.exe, and install.ps1 validates that exact root allowlist (install.ps1:188-227); smoke coverage explicitly requires the old payload wrapper to be absent.

I am closing this as fixed on main. It will be included in the next release candidate. The workaround and cross-architecture confirmation were both useful, thank you.