## Problem
`composio upgrade` from `0.3.4-beta.351` to `0.4.0-beta.359` looked hung
for several minutes:
```
◐ New version available: @composio/cli@0.4.0-beta.359 (current: @composio/cli@0.3.4-beta.351). Downloading.
```
Two independent defects behind that.
**No feedback.** `upgrade-binary.ts` printed that message once and then
said nothing until the download finished. The only byte-level signal was
a `logDebug`, invisible in a normal run, because the body was read with
a single buffered `response.arrayBuffer`.
**Mostly wasted payload.** The archive is 338 MB, and ~651 MB of what it
unpacks is `codex-acp` binaries for the three platforms the host cannot
execute. Measured on a darwin-arm64 install:
```
~/.composio 967 MB total
codex/darwin-arm64 180 MB ← the only one this Mac can run
codex/darwin-x64 190 MB ┐
codex/linux-arm64 208 MB ├─ 620 MB of dead weight
codex/linux-x64 222 MB ┘
```
## Changes
**Progress reporting.** The response is streamed and reported on a 250
ms interval: `Downloading... 42% (142.0 MB / 338.0 MB)`. The total comes
from the release asset's `size` (newly decoded — the field was being
dropped), falling back to `content-length`, and falling back again to a
plain byte count so an unknown size degrades instead of failing.
**Half the payload.** Each archive now carries real bytes only for the
`codex-acp` binary its own platform can execute.
The other three paths cannot simply be dropped — that is exactly the
break #4186 just repaired. A CLI released before 2026-08-18 verifies a
downloaded package against all four codex-acp paths and refuses one
missing any of them. So they ship as **empty placeholders**: the
existence check passes at zero bytes, and since no host ever executes a
foreign codex-acp, the placeholder is never read. Once no supported
client performs that check, placeholders become plain omissions —
`archiveCompanionEntries` is where that switch lives.
As a guard, codex adapter resolution now requires a non-empty file, so a
zero-byte binary resolves as absent and falls through to the existing
bundled → PATH → npx chain rather than trying to exec it.
Expected effect: download 338 MB → ~165 MB, install footprint 967 MB →
~347 MB.
## Verification
- Full CLI suite: **122 files, 1262 passed, 1 skipped**
- `pnpm --filter @composio/cli typecheck` — clean
- The existing `upgrade-binary` download tests run against a real HTTP
server and pass unchanged, covering the buffered → streamed rewrite
- New tests: progress formatting (known total, unknown total, zero
total, overshoot) and `archiveCompanionEntries` (all four paths named,
exactly one copied, three placeholdered, portable assets copied)
- `pnpm validate:changesets` — passes; note lands in
`ts/packages/cli/CHANGELOG.md`
Not verifiable locally: actual archive sizes and a real upgrade against
a pre-2026-08-18 client. Both need a beta build — worth confirming on
the beta cut from this branch before it goes near a stable promotion.
Independent of the `0.4.0` release in flight; `0.4.0-beta.359` is
unaffected.
https://claude.ai/code/session_01JkwtxPHfobZxzvAqe53x62
This PR:
- fixes https://github.com/ComposioHQ/composio/issues/3932
- replaces the private CLI package semver with the non-release
`0.0.0-development` sentinel
- injects the exact GitHub release tag version into every standalone
binary and verifies it during the build
- makes every push to `next` a beta, with explicit semver selection for
intentional minor or major betas and stable releases only through beta
promotion
- resolves skill installation, setup repair, companion repair, and
upgrades from packaged `release-tag.txt` metadata
- adds regression coverage for release selection, compiled version
identity, and packaged-tag asset lookup; all 1,009 CLI tests and the
monorepo typecheck pass
- updates the direct CLI changelog and release guidance; no Changeset is
added because CLI packages are excluded from Changesets
curl install.sh is now the only CLI install channel.
- INSTALL.md: drop npm/pnpm/yarn section; Windows guidance is WSL
- install.sh: Windows error no longer advises the dead npm package
- build-cli-binaries.yml: strip npm section from generated release INSTALL.md
- cli.install-health-check.yml: drop stale npm dist-tag/Homebrew comment
- cli.test-installation.yml: delete no-op npm-fallback job and its
toolchain-versions feeder job; prune summary references
- delete cli.bump-homebrew-tap.yml + bump-homebrew-formula.py (automation
never fired: GITHUB_TOKEN-published releases suppress release-triggered
workflows and HOMEBREW_TAP_TOKEN is dead)
- ts/packages/cli/package.json: drop unused publishConfig (package is private)
- cli-release skill + CLI AGENTS.md: remove Homebrew steps from release docs
- toolchain-versions.json: drop now-unused node_install_compat matrix
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## Summary
Permanently stops the recurring *"release published with zero assets →
install/upgrade 404s"* outage
(https://github.com/ComposioHQ/composio/issues/3408,
https://github.com/ComposioHQ/composio/issues/3269; regressions of
https://github.com/ComposioHQ/composio/issues/2625 and
https://github.com/ComposioHQ/composio/issues/1820 — 3 of the last 5
stable releases shipped empty).
**Root cause:** a concurrent-writer race. On a CLI version bump,
`changesets/action` creates an empty `@composio/cli@x.y.z` GitHub
Release in seconds, then the slower `build-cli-binaries.yml` fails its
`gh release create` because the release already exists — so binaries
never attach.
> 🥞 **Stacked on #3415** (`pi/exclude-cli-ts-release-42161920`), which
removes the *second writer* (changesets no longer creates CLI releases).
Review/merge #3415 first; this PR targets that branch. This PR hardens
the now-sole writer so a *partial* build can't publish either, and fixes
the monitoring that hid the failure.
## What changed (`build-cli-binaries.yml` + canary)
- **Draft → verify → publish.** The release is built as a **draft**,
then a gate asserts all 6 canonical assets are present **and** `state ==
"uploaded"` (loud `::error::` + fail otherwise), and only the final step
flips it to published. Drafts fire no `release: published` event and are
excluded from `/releases/latest`, so no install.sh / Homebrew / redirect
consumer can observe an incomplete release.
- **`fail-fast: false`** on the build matrix → a single platform failure
can never publish a partial set (`needs.build.result` is `success` only
if all legs pass).
- **Per-tag job-level `concurrency`** so re-runs / quick pushes can't
interleave uploads on the same tag, without serializing unrelated betas.
- **Beta-safe:** `--prerelease` is set on the draft so betas stay
prereleases through the publish flip.
- **`promote-stable` guard** uses `gh release view --json isDraft` (the
REST tags endpoint 404s on drafts) to resume an existing draft but
refuse an already-published tag.
- **Least privilege:** workflow defaults to `contents: read`; only the
release job opts up to `contents: write`.
- **Canary fix** (`cli.install-health-check.yml`): install the newest
stable **pinned** tag (`npm view @composio/cli version`) instead of the
asset-aware no-arg flow, which self-heals to the last good release and
kept the canary green through every outage.
## Idempotency note
Re-running a run that failed **before publish** is safe (reuse draft +
`--clobber`). An already-**published** tag is refused, not mutated — by
design.
## Testing
- Extended `test/release-workflow.test.ts` (run via `pnpm
test:release-workflow`) to lock in: draft→verify→publish ordering,
`fail-fast: false`, per-tag concurrency, preserved `--prerelease`, and
the pinned-tag canary. ✅ passes.
- `shellcheck` clean on the new `run:` scripts; YAML validated.
`actionlint` runs in CI.
- Runtime verification of the full green path happens on the next
release CI run.
## Out of scope (deferred to their own PRs)
Per reviewer consensus, these are real but *not this bug*: a per-release
npm↔GitHub asset auditor (needs a grace window), the Homebrew trigger
constraint (folds into #3355), `composio upgrade` missing-asset back-off
(https://github.com/ComposioHQ/composio/issues/3269), and a rollback
runbook.
---------
Co-authored-by: Rahul Tarak <cryogenicplanet@gmail.com>