1 00:00:00,099 --> 00:00:06,159 You, you fire up a clean CI container, you run curl fsSL https 2 00:00:06,379 --> 00:00:12,559 chatgpt com codex install dot sh piped into sh, and boom, it, 3 00:00:12,619 --> 00:00:13,539 it just dies. 4 00:00:14,099 --> 00:00:20,919 And the, the error message you get says Could not find Codex package or platform npm 5 00:00:21,000 --> 00:00:24,279 release assets for Codex dollar resolved version. 6 00:00:25,433 --> 00:00:30,952 Right, right, and then you check GitHub directly, and the release tag is right 7 00:00:30,992 --> 00:00:31,333 there! 8 00:00:31,752 --> 00:00:34,012 The npm assets are right there! 9 00:00:34,532 --> 00:00:38,552 It makes you feel like you are, like you are losing your mind. 10 00:00:38,917 --> 00:00:39,477 Totally. 11 00:00:39,597 --> 00:00:43,717 But before we get into why automated deployments were breaking under heavy build 12 00:00:43,770 --> 00:00:48,677 loads, a quick shoutout thanking Jellypod for making this daily show possible, 13 00:00:48,717 --> 00:00:51,557 helping us bring you these deep dives every day. 14 00:00:52,001 --> 00:00:55,341 So, so what was actually going on under the hood here? 15 00:00:56,161 --> 00:00:58,482 Why was the installer lying to everyone? 16 00:00:58,833 --> 00:01:04,913 Well, it turns out both install dot sh and install dot ps1 were making up to, 17 00:01:05,126 --> 00:01:11,713 uh, up to four separate unauthenticated REST API requests to api dot github dot 18 00:01:11,873 --> 00:01:14,913 com per single installation attempt. 19 00:01:14,977 --> 00:01:20,193 They were querying release tags, checksum manifests, platform binaries, 20 00:01:20,273 --> 00:01:21,793 all as separate lookups. 21 00:01:22,851 --> 00:01:24,871 Four requests per install! 22 00:01:25,391 --> 00:01:30,951 On a shared CI runner or a corporate NAT where hundreds of builds share one public 23 00:01:31,031 --> 00:01:31,712 IP address? 24 00:01:32,042 --> 00:01:33,242 Exactly. 25 00:01:33,311 --> 00:01:38,362 GitHub limits unauthenticated IP addresses to sixty requests per hour. 26 00:01:38,415 --> 00:01:43,002 So if three or four builds fire off at once, you hit that sixty request ceiling 27 00:01:43,071 --> 00:01:44,202 almost instantly. 28 00:01:44,567 --> 00:01:47,007 And, and here is the kicker, right? 29 00:01:47,567 --> 00:01:54,307 The helper function, release asset exists, was piping stdout and stderr straight to 30 00:01:54,407 --> 00:01:55,067 dev null! 31 00:01:56,048 --> 00:02:01,128 It literally swallowed the HTTP 403 Forbidden response whole! 32 00:02:01,557 --> 00:02:02,116 Exactly. 33 00:02:02,657 --> 00:02:06,936 So instead of telling the user Hey, GitHub API rate limit exceeded, 34 00:02:07,456 --> 00:02:13,536 try using a token, the script went, uh, well, the API call returned non zero, 35 00:02:14,056 --> 00:02:15,877 so I guess the asset does not exist! 36 00:02:16,536 --> 00:02:19,136 False diagnostic message, total confusion. 37 00:02:19,486 --> 00:02:23,206 That is so brutal for DevOps and QA engineers. 38 00:02:23,706 --> 00:02:29,127 You end up spending hours debugging internal package registries or checking if npm 39 00:02:29,167 --> 00:02:35,526 is down, when in reality it was just a silent HTTP 403 from GitHub's rate limiter! 40 00:02:35,974 --> 00:02:41,474 It really highlights why relying on unauthenticated API probes inside an install 41 00:02:41,554 --> 00:02:44,894 script is such an architectural antipattern. 42 00:02:45,594 --> 00:02:50,714 If your installer depends on external API calls to discover basic payload paths, 43 00:02:51,314 --> 00:02:53,494 rate limits will always bite you at scale. 44 00:02:54,044 --> 00:02:57,884 So how did the team fix it in PR 31056? 45 00:02:58,208 --> 00:03:00,688 They completely overhauled the asset lookup. 46 00:03:00,848 --> 00:03:06,368 Now, resolving the version and fetching release metadata is consolidated into a 47 00:03:06,425 --> 00:03:08,768 single GitHub API request. 48 00:03:08,912 --> 00:03:15,088 That single JSON payload gets parsed once and reused for package selection, 49 00:03:15,150 --> 00:03:18,928 checksum verification, and legacy asset fallbacks. 50 00:03:19,336 --> 00:03:23,996 So going from four unauthenticated requests down to just one? 51 00:03:24,676 --> 00:03:28,476 That alone cuts API consumption by seventy five percent! 52 00:03:28,833 --> 00:03:29,553 Right. 53 00:03:29,601 --> 00:03:31,953 Plus, they fixed the silent error suppression. 54 00:03:32,093 --> 00:03:38,433 The shell and PowerShell installers now explicitly check for HTTP 403 status codes 55 00:03:38,553 --> 00:03:42,193 and print a clear error explaining that the rate limit was reached. 56 00:03:42,527 --> 00:03:46,067 And, and they added support for environment variables, right? 57 00:03:46,407 --> 00:03:48,967 Like GITHUB TOKEN and GH TOKEN? 58 00:03:49,250 --> 00:03:49,890 Yes! 59 00:03:49,970 --> 00:03:55,650 If GITHUB TOKEN or GH TOKEN is set in the environment, the installer passes it in 60 00:03:55,670 --> 00:03:56,930 the Authorization header. 61 00:03:57,058 --> 00:04:02,290 That instantly bumps your rate limit from sixty requests per hour to five thousand 62 00:04:02,352 --> 00:04:03,410 requests per hour. 63 00:04:03,776 --> 00:04:07,157 That is huge for automated CI pipelines. 64 00:04:07,216 --> 00:04:11,677 You just export GITHUB TOKEN in your build step before running install dot sh, 65 00:04:12,076 --> 00:04:15,516 and you completely bypass shared runner IP throttling! 66 00:04:15,917 --> 00:04:16,997 Exactly. 67 00:04:17,048 --> 00:04:21,917 Though honestly, for super busy pipelines, the best pattern is still to cache the 68 00:04:21,961 --> 00:04:27,117 downloaded package tarballs locally rather than hitting installer network probes on 69 00:04:27,170 --> 00:04:28,717 every single pipeline step. 70 00:04:28,988 --> 00:04:29,987 Oh, definitely. 71 00:04:30,507 --> 00:04:34,327 And there were a couple other nice quality of life fixes in this release cycle too, 72 00:04:34,447 --> 00:04:34,707 right? 73 00:04:35,042 --> 00:04:41,522 Yeah, they fixed issue 38740 where installed skill installer helper binaries were 74 00:04:41,579 --> 00:04:47,122 losing their executable plus x permissions on Linux and macOS after installation. 75 00:04:48,985 --> 00:04:54,304 Ah, the classic permission denied on binary execution after download! 76 00:04:54,750 --> 00:04:55,870 Yep, fixed. 77 00:04:55,990 --> 00:05:01,390 And they also fixed token propagation in Windows updater scripts so PowerShell 78 00:05:01,439 --> 00:05:04,670 environments handle authenticated updates properly now too. 79 00:05:05,186 --> 00:05:06,826 Solid fixes all around. 80 00:05:07,266 --> 00:05:08,606 Good chatting about this one, Ethan. 81 00:05:08,958 --> 00:05:10,318 Yeah, really good stuff. 82 00:05:10,414 --> 00:05:11,358 Talk soon!