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

Activity

1. github-actions

   added

   windowsWindows-specific issuesWindows-specific issues

   on Jul 23, 2026
2. RithvikReddy0-0 commented on Jul 23, 2026

   

   RithvikReddy0-0

   on Jul 23, 2026

   Contributor

   More actions

   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.
3. dyy1991 commented on Jul 24, 2026

   

   dyy1991

   on Jul 24, 2026

   More actions

   still happening
4. DeusData

   added

   bugSomething isn't workingSomething isn't working

   ux/behaviorDisplay bugs, docs, adoption UXDisplay bugs, docs, adoption UX

   securitySecurity vulnerabilities, hardeningSecurity vulnerabilities, hardening

   priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.

   on Jul 24, 2026
5. DeusData

   added this to the 0.9.1-rc milestone on Jul 24, 2026
6. DeusData

   added a parent issue on Jul 24, 2026

   • task: Windows platform issues (8 bugs) #394
7. DeusData commented on Jul 24, 2026

   

   DeusData

   on Jul 24, 2026

   Owner

   More actions

   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.

   👍React with 👍5Reacted by Zhenglei, Willis, cem alper çiftci, jonahaley and XXEN0SS
8. DeusData commented on Sep 26, 2026

   

   DeusData

   on Sep 26, 2026

   Owner

   More actions

   Thank you, @GaboDot, for the precise file listing, and @RithvikReddy0-0 for spotting that the script and the archive had drifted apart. That diagnosis was exactly right!

   We've since removed the Windows launcher/payload split entirely (a54ea95, released in v0.10.0). Windows now ships one binary, like Linux and macOS, and install.ps1 expects exactly the four files the release archive contains. The current install.ps1 and the v0.11.0 archive match. Could you confirm that irm .../install.ps1 | iex installs v0.11.0 cleanly? The archive check stays strict on purpose. Clearer wording that tells "genuine but older layout" apart from tampering is a fair follow-up.
9. DeusData

   added

   awaiting-reporterWaiting on the reporter for info/repro; stale bot will warn then closeWaiting on the reporter for info/repro; stale bot will warn then close

   on Sep 26, 2026
10. github-actions commented on Sep 26, 2026

    

    github-actionsBot

    on Sep 26, 2026 – with GitHub Actions

    More actions

    Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

    • the codebase-memory-mcp --version you're on
    • the exact steps or command you ran
    • a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

    Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.
11. DeusData commented on Oct 19, 2026

    

    DeusData

    on Oct 19, 2026

    Owner

    More actions

    Thank you again for separating authentic archive contents from an incompatible installer contract. The last update requested installation confirmation after removal of the launcher/payload split. I have no new result for your Windows environment; the strict archive validation is not being relaxed here.
12. DeusData commented on Oct 25, 2026

    

    DeusData

    on Oct 25, 2026

    Owner

    More actions

    Thank you again for the installer/archive comparison. Could you confirm installation after the launcher split was removed, as requested above? No new archive contents or full reproduction are needed.
13. RithvikReddy0-0 commented on Oct 25, 2026

    

    RithvikReddy0-0

    on Oct 25, 2026

    Contributor

    More actions

    Confirmed: current main install.ps1 (at 4a1e6d11) installs the latest release (v0.12.1) cleanly on Windows 11 (build 26200), under both Windows PowerShell 5.1.26100 and PowerShell 7.6.7. In both runs the checksum verified, the four-file archive passed the strict layout check, the candidate probe and the post-install --version both reported codebase-memory-mcp 0.12.1, and the installer exited 0.

    To keep it off my real profile I ran it with --skip-config and pointed --dir, LOCALAPPDATA, APPDATA, USERPROFILE and CBM_CACHE_DIR at a throwaway folder, so this exercised the same download, verify and install path as irm | iex, not a default-location install with agent registration.

    One thing I hit while doing this, separate from this issue: pwsh -File install.ps1 --dir=C:\some\path splits the argument at the colon, so the script receives --dir=C. It then installs into a relative C folder and adds C to the user PATH. Windows PowerShell 5.1 passes the argument through intact, and so does calling the script inside a pwsh session (& .\install.ps1 --dir=C:\some\path). Happy to open a separate issue if useful.

    The wording follow-up you mentioned (telling a checksum-verified layout mismatch apart from an unsafe archive) is in #2766.
14. DeusData

    added a commit that references this issue on Oct 25, 2026

    install.ps1: report checksum-verified layout mismatch separately from…

    ...

    2809f88
15. DeusData

    closed this as completedin #2766on Oct 25, 2026
16. DeusData commented on Oct 25, 2026

    

    DeusData

    on Oct 25, 2026

    Owner

    More actions

    The wording follow-up is now on main in 07e73a3 (#2766). When a checksum-verified archive has a different file set than the installer expects, install.ps1 now reports a layout mismatch and tells you how to fix it. Unsafe paths and duplicate entries are still reported as an unsafe archive. Validation stays strict, and both cases still exit 1. With the launcher/payload removal in a54ea95 (v0.10.0) and the clean v0.12.1 install confirmed above, this issue is resolved. Thank you, @GaboDot, for the precise report, and @RithvikReddy0-0 for the diagnosis, the install confirmation and the fix.
17. DeusData

    removed

    awaiting-reporterWaiting on the reporter for info/repro; stale bot will warn then closeWaiting on the reporter for info/repro; stale bot will warn then close

    on Oct 25, 2026