Stop the CLI launcher from re-downloading an already-installed binary on every launch

[picklem0b]

// markdown

Summary

Fixes a launcher bug where a healthy install re-downloads the full platform binary on every launch and hard-fails at startup when the release host is unreachable whenever /.config/manicode/freebuff-metadata.json is missing or unreadable, even though the correct binary is already installed at `/.config/manicode/freebuff

Original failure

The launcher decides "is a binary installed?" from getCurrentVersion()`, which reads the 'freebuff-metadata.json cache. When that file is missing or corrupt (cleaned config dir, interrupted install, lost cache):

• ensureBinaryReady() treated 'null' as "not installed" and re-downloaded the full platform binary on every launch.

• If the release host was unreachable at that moment, the launcher printed "Failed to determine latest version" and exited turning a lost cache file into a hard startup failure.

• The background update check had the same bug:
  currentVersion null meant "download now", so even an up-to-date install re-downloaded its binary once per session.

Root cause

The metadata file is only a cache of what was installed, but the launcher treated an unreadable cache as proof that nothing was installed. The binary itself the thing that actually matters was never checked on this path.

Solution

• ensureBinaryReady()` returns early when the metadata is missing/unreadable and the binary is present. Staleness is the background update check's job; startup only needs the binary to exist.

• checkForUpdates()` compares a "comparison version" that prefers the verified installed version, then falls back to the wrapper version (a wrapper and the binary it installs share a version) a lost cache no SO longer reads as "outdated", while genuine updates still download as soon as the registry is ahead.

• Fresh installs (no binary) are unchanged and still download on first launch.

• Added a 'CODEBUFF_NPM_REGISTRY_URL override (mirroring the existing NEXT_PUBLIC_CODEBUFF_APP_URL release-host override) so the version check can be answered by a controlled server in tests.

Tests

New cli/src/tests/release/launcher-installed-binary. test.ts (10 tests):

• installed binary + metadata present → no download
• installed binary + metadata lost → no download at startup, and no download in the background check when nothing is newer
• installed binary + metadata corrupt → no download
• background check still updates when the wrapper is genuinely behind the registry
• download fallback when the binary is missing (with and without metadata)
• the comparison-version helper (verified version > wrapper fallback > null)

Verified against the pre-fix launcher: 6 of the 10 tests fail (including the re-download and the Update available: null all 10 pass with output); the fix. Existing launcher/release suites still pass (cli/src/_tests_/release/^, launcher-avx2-fallback, wrapper-safety, proxy-http-get).

[codebuff-team]

Good find and clean root-cause analysis: getCurrentVersion() reading null on a missing/corrupt freebuff-metadata.json was conflated with "binary not installed," causing a full re-download every launch and a hard failure when the release host was unreachable. The fix — checking fs.existsSync(CONFIG.binaryPath) before falling back to a redownload in ensureBinaryReady(), and introducing getUpdateComparisonVersion() so the background check uses the wrapper version as a fallback record — is a sensible, minimal change (cli/release-core/launcher.js lines ~429-445, ~933-946, ~1029-1046).

The new test file (cli/src/__tests__/release/launcher-installed-binary.test.ts) is thorough: it exercises missing/corrupt metadata, background-check stand-down, and the fallback comparison-version helper directly, using real local HTTP servers rather than mocks. That's the kind of coverage this repo would expect for a launcher change, and the PR states it verified 6/10 tests fail against the pre-fix code.

One thing worth double-checking before porting: the fix trusts fs.existsSync(binaryPath) as proof the binary is good, with no integrity check. That's consistent with the existing behavior when metadata is present but the binary is corrupt, so it's not a regression, but it's worth confirming there isn't a checksum/verification step elsewhere in the install flow that this path now skips in the missing-metadata case. Also worth checking whether CONFIG.binaryPath existing but being for the wrong target (e.g., avx2 fallback) is handled elsewhere, since this path bypasses target verification.

Overall this reads as a genuine, scoped bug fix with tests, not churn. Recommending it for porting review; a maintainer should just confirm the integrity/target assumptions above hold.