This PR:
- closes#4284
- makes `mise.toml` the editable source of truth for Bun and pins
`1.4.1-canary.1+d9b769812`, the first Bun build whose compiled macOS
binaries carry strictly valid signatures
- maps that revision to the immutable per-platform `@oven/bun-*` npm
tarballs via mise's `http` backend, so mise extracts the exact
checksum-verified binary with no npm lifecycle, Node dependency, or
postinstall script
- installs Bun through mise in CI and Docker E2E images, removing the
independent `bun-version` input and the `oven-sh/setup-bun` channel
- updates the checksum-verified mise installer to `2026.8.15`, reuses it
in the Docker E2E images, and regenerates `mise.lock` with that release
- teaches the preinstall toolchain check to compare the full Bun
revision (via `Bun.version_with_sha`, in-process) when the pinned
version carries build metadata
- verifies the exact `bun --revision`, a strictly valid Bun-compiled
macOS signature, a Linux container install, the release-workflow
contract, and formatting/linting
EOF -R ComposioHQ/composio
## 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>
## What this fixes
This is a follow-up to #3770, not a second root-cause fix.
#3770 moved the docs data workflow from staging to production,
centralized the production API URL, removed staging hosts from the
committed data, and added the hostname guard. The committed toolkit
catalog still retained staging-derived `version` values, however,
because that PR intentionally did not regenerate the full catalog. After
#3770 merged, the scheduled production regeneration began failing with
`401 Unauthorized`: the repository's existing `COMPOSIO_API_KEY` secret
is staging-scoped.
The customer-visible result was that nearly every toolkit page showed
the internal staging version `20260703_00`; Gmail's production version
was `20260702_01`.
## Changes
- Correct every `version` in `docs/public/data/toolkits.json` from the
production toolkit changelog. Toolkits absent from that changelog
receive `null`, matching the full generator's semantics. No other JSON
field changes.
- Move production changelog fetching and version application into shared
`toolkit-versions.ts` logic used by the full catalog generator.
- Add `bun run generate:toolkit-versions` as the narrow, reproducible
generator for version-only repairs.
- Reject any non-production `COMPOSIO_API_BASE` in the toolkit and
meta-tool generators before a request is made.
- Keep the version-distribution check as a smoke signal for the known
whole-catalog staging-bump pattern, while testing the production source
boundary separately. The distribution heuristic is no longer described
as proof of provenance.
- Fail before writing when the production changelog response is
malformed or contains no versions.
## CI policy compatibility
- Replace the enterprise-blocked mise action with allowlisted tool setup
actions while continuing to resolve exact versions from mise.lock.
Install the existing pinned mise CLI release through a checksum-verified
repository script for lock freshness and preinstall validation.
- Run the existing GitHub Advanced Security alert check locally and
notify Slack through the already-allowlisted Slack action, avoiding the
central workflow dependency rejected by the enterprise action policy.
## Verification
- `bun test tests/static/` — 30 passed.
- Targeted ESLint for every changed script/test — passed.
- `bun run types:check` — passed.
- `bun run build` — passed.
- Explicit staging override of `generate-toolkits.ts` — rejected before
network access.
- Verified the JSON data change remains version-only; toolkit ordering,
tools, triggers, descriptions, and counts are unchanged.
## Remaining deployment action
An administrator still needs to replace `COMPOSIO_API_KEY` with a
production-scoped key. The scheduled `docs-update-data` workflow is
correctly pinned to production and therefore fails loudly with the
current staging credential instead of republishing staging data. Once
the secret is corrected, the normal full-catalog generator remains the
authoritative refresh path.
Triggered by: abhishek@composio.dev | Source: slack
Session: https://zen.corp.composio.io/dashboard/#/chat/zen-3a77f73eb146
---------
Co-authored-by: Zen Agent <zen@composio.dev>
Co-authored-by: abhishek <abhishek@composio.dev>
Co-authored-by: jkomyno <alberto@composio.dev>
## What
Adds a **report-only** `Dead Code` CI workflow that surfaces
likely-orphaned code on every PR, across all three surfaces —
TypeScript, Python, and GitHub Actions. Follow-up to the root
`Dockerfile` cleanup (#3783) and the dead-code sweep in #3786: instead
of finding this stuff by hand, catch it automatically.
| Surface | Tool | Wiring |
|---|---|---|
| TypeScript | [**knip**](https://knip.dev) | `knip.json`; runs via
`pnpm dlx knip@5`. Finds unused files, exports, types, and dependencies.
|
| Python | [**vulture**](https://github.com/jendrikseipp/vulture) |
`dead_code` nox session + `make dead-code`; allowlist at
`python/config/vulture_allowlist.py`. Finds unused
functions/classes/variables (complements Ruff's F401/F841). |
| GitHub Actions | small bash script |
`.github/scripts/check-orphan-ci.sh` — flags reusable workflows and
composite actions with no callers. |
## Why report-only (not blocking)
Every job writes findings to the run's **Step Summary** and **never
fails the build**. These tools carry unavoidable false positives on a
library monorepo — public API surface, dynamic imports, import-map
targets (e.g. core's `#platform`), framework entry points. A red ❌ on
false positives would just train everyone to ignore the check. Once a
job's config is refined enough that a clean run is the steady state, it
can be flipped to blocking.
## Validation (ran each locally)
- **knip**: 0 unused *files* after scoping out the e2e-test workspaces
(knip crashes traversing `ts/e2e-tests/**` — pre-existing knip bug,
filed via `ignoreWorkspaces`) and build/docs artifacts. Export/dep
categories surface advisory items.
- **vulture**: clean run (report-only); allowlist suppresses the 3
`TYPE_CHECKING` re-exports in `custom_tool.py`; `build/`/`dist/`
excluded. Surfaces 4 genuine minor items (`bases`, `desc`×3).
- **orphan-CI script**: finds none — the repo has no orphaned CI
plumbing today.
- **Pinning**: `jk actions check` clean for this workflow;
`actions/checkout` is SHA-pinned, the two local composite actions need
no pin.
Local usage is documented under **Dead code detection** in
`CONTRIBUTING.md`.
## Note on scope
These cover TS/Python/GHA — they would *not* have caught the root
`Dockerfile` itself (an arbitrary root file no tool tracks). That class
stays a manual-review concern; the orphan-CI script is the closest
analogue for the CI surface.
## Summary
- New workflow that auto-bumps the Homebrew formula in
[ComposioHQ/homebrew-tap](https://github.com/ComposioHQ/homebrew-tap)
whenever a stable CLI release is published.
- Triggers on `release: published` for tags matching `@composio/cli@*`.
Skips beta/rc/alpha tags. Also exposes `workflow_dispatch` for manual
replay.
- Pulls SHA256s from the release's `checksums.txt`, edits
`Formula/composio.rb` in the tap repo, and commits/pushes (no-op if
already current).
## Setup required before this can run
- Create a fine-grained PAT scoped to `ComposioHQ/homebrew-tap` only,
with `Contents: read/write`.
- Add it as a repo secret named `HOMEBREW_TAP_TOKEN` in this repo.
Without that secret the checkout step will fail; the workflow won't
break anything else.
## Test plan
- [ ] Land this PR
- [ ] Add `HOMEBREW_TAP_TOKEN` secret
- [ ] Manually run via `workflow_dispatch` with tag
`@composio/cli@0.2.28` — should be a no-op (formula already at 0.2.28)
- [ ] Verify next CLI release auto-bumps the formula
---------
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
Co-authored-by: jkomyno <alberto@composio.dev>
## 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>
Alberto Schiabel