You, you fire up a clean CI container, you run curl fsSL https
chatgpt com codex install dot sh piped into sh, and boom, it,
it just dies.
And the, the error message you get says Could not find Codex package or platform npm
release assets for Codex dollar resolved version.
Right, right, and then you check GitHub directly, and the release tag is right
there!
The npm assets are right there!
It makes you feel like you are, like you are losing your mind.
Totally.
But before we get into why automated deployments were breaking under heavy build
loads, a quick shoutout thanking Jellypod for making this daily show possible,
helping us bring you these deep dives every day.
So, so what was actually going on under the hood here?
Why was the installer lying to everyone?
Well, it turns out both install dot sh and install dot ps1 were making up to,
uh, up to four separate unauthenticated REST API requests to api dot github dot
com per single installation attempt.
They were querying release tags, checksum manifests, platform binaries,
all as separate lookups.
Four requests per install!
On a shared CI runner or a corporate NAT where hundreds of builds share one public
IP address?
Exactly.
GitHub limits unauthenticated IP addresses to sixty requests per hour.
So if three or four builds fire off at once, you hit that sixty request ceiling
almost instantly.
And, and here is the kicker, right?
The helper function, release asset exists, was piping stdout and stderr straight to
dev null!
It literally swallowed the HTTP 403 Forbidden response whole!
Exactly.
So instead of telling the user Hey, GitHub API rate limit exceeded,
try using a token, the script went, uh, well, the API call returned non zero,
so I guess the asset does not exist!
False diagnostic message, total confusion.
That is so brutal for DevOps and QA engineers.
You end up spending hours debugging internal package registries or checking if npm
is down, when in reality it was just a silent HTTP 403 from GitHub's rate limiter!
It really highlights why relying on unauthenticated API probes inside an install
script is such an architectural antipattern.
If your installer depends on external API calls to discover basic payload paths,
rate limits will always bite you at scale.
So how did the team fix it in PR 31056?
They completely overhauled the asset lookup.
Now, resolving the version and fetching release metadata is consolidated into a
single GitHub API request.
That single JSON payload gets parsed once and reused for package selection,
checksum verification, and legacy asset fallbacks.
So going from four unauthenticated requests down to just one?
That alone cuts API consumption by seventy five percent!
Right.
Plus, they fixed the silent error suppression.
The shell and PowerShell installers now explicitly check for HTTP 403 status codes
and print a clear error explaining that the rate limit was reached.
And, and they added support for environment variables, right?
Like GITHUB TOKEN and GH TOKEN?
Yes!
If GITHUB TOKEN or GH TOKEN is set in the environment, the installer passes it in
the Authorization header.
That instantly bumps your rate limit from sixty requests per hour to five thousand
requests per hour.
That is huge for automated CI pipelines.
You just export GITHUB TOKEN in your build step before running install dot sh,
and you completely bypass shared runner IP throttling!
Exactly.
Though honestly, for super busy pipelines, the best pattern is still to cache the
downloaded package tarballs locally rather than hitting installer network probes on
every single pipeline step.
Oh, definitely.
And there were a couple other nice quality of life fixes in this release cycle too,
right?
Yeah, they fixed issue 38740 where installed skill installer helper binaries were
losing their executable plus x permissions on Linux and macOS after installation.
Ah, the classic permission denied on binary execution after download!
Yep, fixed.
And they also fixed token propagation in Windows updater scripts so PowerShell
environments handle authenticated updates properly now too.
Solid fixes all around.
Good chatting about this one, Ethan.
Yeah, really good stuff.
Talk soon!