install.sh reports missing assets for valid releases when GitHub API rate limit is exhausted

[mkusaka]

What version of Codex CLI is running?

codex-cli 0.140.0 on an existing install.

What subscription do you have?

Pro

Which model were you using?

N/A

What platform is your computer?

macOS arm64

What terminal emulator and version are you using (if applicable)?

N/A

Codex doctor report

Not included because this appears to be an installer / GitHub release metadata issue.

What issue are you seeing?

The standalone installer reports that release assets are missing for multiple valid releases:

curl -fsSL https://chatgpt.com/codex/install.sh | sh -s -- --release 0.138.0-alpha.6
curl -fsSL https://chatgpt.com/codex/install.sh | sh -s -- --release 0.141.0-alpha.3
curl -fsSL https://chatgpt.com/codex/install.sh | sh -s -- --release 0.140.0

All of them fail with:

Could not find Codex package or platform npm release assets for Codex <version>.

These are valid versions, and their npm packages / GitHub releases exist. For example, 0.138.0-alpha.6 still has the expected release assets, including codex-package-aarch64-apple-darwin.tar.gz, codex-package_SHA256SUMS, and codex-npm-darwin-arm64-0.138.0-alpha.6.tgz.

The underlying problem appears to be that the installer uses unauthenticated GitHub REST API requests to inspect release metadata. When the unauthenticated API rate limit is exhausted, the API returns 403:

HTTP/2 403
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-resource: core

The installer then suppresses that API failure and reports it as missing release assets.

What steps can reproduce the bug?

1. Exhaust the unauthenticated GitHub REST API rate limit for the current IP.
2. Run the standalone installer for any valid release, for example:

curl -fsSL https://chatgpt.com/codex/install.sh | sh -s -- --release 0.140.0

3. Observe:

Could not find Codex package or platform npm release assets for Codex 0.140.0.

What is the expected behavior?

The installer should distinguish a GitHub API failure from genuinely missing release assets.

For example, it should report the GitHub API 403 / rate-limit condition directly, or support authenticated GitHub API requests when GITHUB_TOKEN or GH_TOKEN is set.

Additional information

The relevant installer path appears to call GitHub's release metadata API without authentication:

https://api.github.com/repos/openai/codex/releases/tags/rust-v<version>

Since release_asset_exists() suppresses the API failure, a rate-limited metadata request becomes a misleading "assets not found" error.

[MakenRosa]

I checked the installer path and the reported symptom matches the current control flow in scripts/install/install.sh.

Relevant path:

• release_asset_exists() calls release_asset_digest_or_empty() and discards all output/errors with >/dev/null 2>&1.
• release_asset_digest_or_empty() fetches https://api.github.com/repos/openai/codex/releases/tags/rust-v<version> through download_text().
• download_text() uses curl -fsSL, so an unauthenticated GitHub API 403 exits non-zero without a response body.
• Because release_asset_exists() treats any non-zero result as “asset does not exist”, the installer then falls through to:

Could not find Codex package or platform npm release assets for Codex $resolved_version.

So this does not appear to be an asset selection issue. It is an error-classification issue: release metadata fetch failure is being collapsed into the same branch as “metadata fetched successfully, but no matching asset was present”.

A narrow fix would be to separate these cases:

1. Fetch release metadata once for the resolved version.
2. If the metadata request fails, print a fetch-specific error that includes the GitHub status/rate-limit hint, e.g. Could not fetch GitHub release metadata for Codex <version>; GitHub API may be rate limited.
3. Only print the current “Could not find assets” message after a successful metadata fetch where the expected asset names are genuinely absent.

This would also avoid making multiple GitHub API requests for the same release during one install attempt, since the current package/checksum/legacy asset probes each call the release metadata endpoint separately.