Linux/macOS installer ignores GH_TOKEN/GITHUB_TOKEN for release metadata

What version of Codex CLI is running?

Current main in scripts/install/install.sh (standalone installer behavior, not tied to a running CLI version).

What subscription do you have?

N/A (standalone installer issue)

Which model were you using?

N/A

What platform is your computer?

Linux and macOS standalone installs use the shared install.sh path. This report is based on the current source path and the confirmed Windows counterpart in #32953; I have not reproduced it on a live Linux/macOS machine.

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

N/A

Codex doctor report

N/A (installer release-metadata request)

What issue are you seeing?

install.sh fetches GitHub release metadata without authentication even when GH_TOKEN or GITHUB_TOKEN is exported.

resolve_release() calls:

release_json="$(download_text "$metadata_url")"

The two download_text() paths are currently:

curl -fsSL "$url"
wget -q -O - "$url"

Neither supplies an authorization header. Therefore, when the shared unauthenticated GitHub REST API quota for the current public IP is exhausted, a valid authenticated token with remaining quota cannot be used and the standalone install/update still fails.

This is the remaining follow-up to #28538 / #31056. That change reduced release metadata access to one request and improved the error message, but one exhausted unauthenticated request still blocks installation. The equivalent Windows behavior is tracked in #32953.

What steps can reproduce the bug?

Based on the current code path:

1. Exhaust the unauthenticated GitHub REST API core quota for the current public IP.
2. Authenticate GitHub CLI and export a token with remaining quota:

gh auth login
export GITHUB_TOKEN="$(gh auth token)"

1. Run the standalone installer:

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

1. The metadata call remains unauthenticated and fails with the existing GitHub availability/rate-limit error despite the authenticated quota being available.

What is the expected behavior?

For the GitHub API release-metadata request only, install.sh should prefer GH_TOKEN, fall back to GITHUB_TOKEN, and otherwise retain the current unauthenticated behavior.

The authorization header must not be reused for release asset downloads or arbitrary redirected download URLs. Both the curl and wget metadata paths should follow this boundary.

Additional information

A regression test should cover no token, GITHUB_TOKEN, GH_TOKEN precedence, and verify that credentials are not attached to asset-download requests.

Because external pull requests require an explicit maintainer invitation, I will not open an unsolicited PR. If a maintainer would like me to prepare and submit this change, please explicitly invite me here; otherwise, could the team pick up the fix?