v2.18.7 published with no release assets — get.livekit.io/cli installs it and 404s

[vgerasymenko]

v2.18.7 was published as a normal release (not draft, not prerelease) with no release assets, so the install script installs it and then 404s.

$ gh api repos/livekit/livekit-cli/releases/tags/v2.18.7 --jq '"draft=\(.draft) prerelease=\(.prerelease) assets=\(.assets|length)"'
draft=false prerelease=false assets=0

For comparison, v2.18.6 and earlier each carry 7 assets plus checksums.txt.

Effect

https://get.livekit.io/cli resolves the version from releases/latest, so it picks 2.18.7 and derives a download URL that does not exist:

Installing livekit-cli 2.18.7
Downloading from https://github.com/livekit/livekit-cli/releases/download/v2.18.7/lk_2.18.7_linux_amd64.tar.gz...
curl: (22) The requested URL returned error: 404

Any fresh install via the documented installer fails, including in CI. In our case it broke agent deploys (lk agent deploy) from 2026-09-15 20:30 UTC — the release timestamp — until we stopped using the installer.

Why there is no user-side workaround with the script

The version is not overridable — the script assigns it unconditionally:

VERSION=$(curl -fsSL ... https://api.github.com/repos/livekit/$REPO/releases/latest \
  | jq -r '.tag_name' | sed 's/^v//')

So pinning requires bypassing the installer and fetching a specific release asset directly, which is what we have done (v2.18.6, verified against that release's checksums.txt).

Suggestions

1. Attach the assets to v2.18.7, or mark it draft / remove the tag until the binaries are published.
2. Two changes to the installer that would each have prevented the outage, if useful:
   • honour a version override (e.g. LIVEKIT_CLI_VERSION), so consumers can pin;
   • and/or resolve to the latest release that actually has assets, rather than the latest tag.

Happy to send a PR for either if that would help.