1
00:00:00,100 --> 00:00:04,820
So, you pull down the Codex CLI using the
standalone curl install script,

2
00:00:05,380 --> 00:00:10,270
everything feels fast, but then you
realize your local agent is silently crawling

3
00:00:10,280 --> 00:00:14,780
through directories instead of screaming
through them with the bundled ripgrep

4
00:00:14,800 --> 00:00:15,250
binary.

5
00:00:15,960 --> 00:00:19,500
And thanks to Jellypod for helping make
this daily show a reality.

6
00:00:20,460 --> 00:00:25,020
Maya, this- this whole issue came down to
a really quiet, really annoying

7
00:00:25,180 --> 00:00:30,260
architectural split between the npm launch
path and the native Rust side,

8
00:00:30,780 --> 00:00:34,280
specifically in PR #26189.

9
00:00:36,248 --> 00:00:41,248
Oh, the classic "it works on npm but not
on standalone" trap.

10
00:00:41,968 --> 00:00:47,668
Let me guess, codex.js was doing some
manual lifting that the native Rust executable

11
00:00:47,748 --> 00:00:48,638
just didn't know about?

12
00:00:49,499 --> 00:00:50,639
Exactly.

13
00:00:50,679 --> 00:00:56,959
If you ran via npm or npx, this legacy
JavaScript wrapper, codex.js,

14
00:00:57,419 --> 00:01:00,819
was manually rewriting your PATH
environment variable.

15
00:01:00,859 --> 00:01:05,879
It prepended the internal codex-path
directory where all the high-performance helper

16
00:01:05,959 --> 00:01:10,519
binaries, like rg-ripgrep-actually live.

17
00:01:11,199 --> 00:01:15,469
But if you bypassed npm and used the
standalone binary from the shell installer,

18
00:01:16,179 --> 00:01:22,599
that Rust launcher in codex-rs/arg0 didn't
have that prepend logic.

19
00:01:22,619 --> 00:01:25,319
It just inherited your raw system shell
path.

20
00:01:26,807 --> 00:01:32,987
Which means the standalone CLI literally
couldn't find its own bundled tools.

21
00:01:33,527 --> 00:01:37,817
It would fall back to slow, native JS
search methods, or worse,

22
00:01:38,087 --> 00:01:43,607
pop up prompts asking the developer to
manually install ripgrep on their machine.

23
00:01:43,617 --> 00:01:47,327
That's a terrible developer experience for
a tool that's supposed to be

24
00:01:47,367 --> 00:01:48,157
self-contained.

25
00:01:49,049 --> 00:01:51,419
Right, completely defeats the point of
bundling.

26
00:01:52,109 --> 00:01:59,109
So, PR #26189 fixes this by migrating the
path-prepending logic entirely out

27
00:01:59,149 --> 00:02:03,289
of the JavaScript wrapper and directly
into the core Rust startup code.

28
00:02:04,049 --> 00:02:09,019
Now, when the Rust binary boots, it
resolves the helper path dynamically using

29
00:02:09,069 --> 00:02:14,909
InstallContext::current ()
.package_layout.path_dir and injects it right into the

30
00:02:14,949 --> 00:02:15,449
environment.

31
00:02:16,122 --> 00:02:21,552
Okay, so whether you're running the npm
package or the standalone curl-installed

32
00:02:21,622 --> 00:02:25,872
binary, they both hit that same Rust-side
path resolution.

33
00:02:26,663 --> 00:02:31,983
But wait-how does this interact with
subshells or when Codex spins up user-shell

34
00:02:32,003 --> 00:02:33,043
runtimes?

35
00:02:33,082 --> 00:02:36,543
Do those child processes actually see the
updated PATH?

36
00:02:37,258 --> 00:02:39,498
They do, and that's the crucial part.

37
00:02:40,058 --> 00:02:46,888
The fix uses explicit_env_overrides to
guarantee that the modified PATH gets passed

38
00:02:46,918 --> 00:02:51,078
down the chain to any subshell or unified
execution runtime.

39
00:02:51,738 --> 00:02:53,618
But they had to be careful here.

40
00:02:53,678 --> 00:02:58,358
For remote unified execution-where the
agent is running tasks on a remote

41
00:02:58,368 --> 00:03:03,358
target-they explicitly bypass these local
path prepends.

42
00:03:03,438 --> 00:03:08,278
You don't want to pollute a remote
target's environment with local paths that don't

43
00:03:08,318 --> 00:03:09,638
exist over there.

44
00:03:10,198 --> 00:03:10,938
Mm, that makes sense.

45
00:03:11,448 --> 00:03:16,408
You don't want a local macOS ripgrep path
being pushed to a remote Linux container.

46
00:03:17,128 --> 00:03:20,268
But on the local side, there is one catch,
right?

47
00:03:20,868 --> 00:03:26,078
If Codex is now prepending its own bundled
tools to the very front of the PATH,

48
00:03:26,608 --> 00:03:31,458
it means the CLI's internal toolchain is
always going to take precedence over

49
00:03:31,488 --> 00:03:34,588
whatever the developer has installed
globally on their system.

50
00:03:35,398 --> 00:03:37,218
Yes, it's a total override.

51
00:03:37,818 --> 00:03:42,318
If you have a custom version of ripgrep
installed globally with specific compile

52
00:03:42,398 --> 00:03:47,018
flags, Codex is going to ignore it and use
its own bundled rg.

53
00:03:47,798 --> 00:03:53,258
For 99% of developers, that's exactly what
they want because it guarantees a stable

54
00:03:53,358 --> 00:03:53,838
baseline.

55
00:03:54,518 --> 00:03:58,198
But if you're a power user with a highly
customized local toolchain,

56
00:03:58,738 --> 00:04:02,238
you need to be aware that inside the Codex
execution context,

57
00:04:02,758 --> 00:04:04,758
Codex's bundled versions win.

58
00:04:06,617 --> 00:04:11,907
Speaking of the installer, we also need to
talk about PR #31056.

59
00:04:12,457 --> 00:04:16,717
If you've ever tried to run the standalone
install script inside a corporate network

60
00:04:16,757 --> 00:04:21,517
or as part of a busy CI/CD pipeline, you
might have run into these weird,

61
00:04:21,557 --> 00:04:26,637
silent 403 errors where the installer
suddenly claims that a release simply doesn't

62
00:04:26,657 --> 00:04:27,317
exist.

63
00:04:29,150 --> 00:04:33,650
Oh yeah, the classic "release not found"
lie when GitHub is actually just

64
00:04:33,850 --> 00:04:34,610
rate-limiting you.

65
00:04:35,536 --> 00:04:36,376
Exactly!

66
00:04:36,876 --> 00:04:42,796
The installer script was making four
separate, unauthenticated HTTP requests to the

67
00:04:42,876 --> 00:04:48,016
GitHub REST API just to resolve a single
release's metadata and pull down the

68
00:04:48,096 --> 00:04:48,556
assets.

69
00:04:49,216 --> 00:04:53,456
If you're behind a corporate NAT where
hundreds of devs share an external IP,

70
00:04:53,936 --> 00:04:58,556
or if you have dozens of runner VMs
spinning up at once, you hit GitHub's

71
00:04:58,636 --> 00:05:03,956
unauthenticated limit of 60 requests per
hour almost instantly.

72
00:05:03,995 --> 00:05:08,375
Four calls per install is just asking for
trouble under a shared IP.

73
00:05:09,015 --> 00:05:10,275
How did they slim that down?

74
00:05:12,266 --> 00:05:13,716
They completely redesigned the metadata
retrieval.

75
00:05:14,236 --> 00:05:20,996
PR #31056 condenses those four API calls
into a single, highly optimized

76
00:05:21,056 --> 00:05:21,496
request.

77
00:05:21,996 --> 00:05:25,206
It fetches the unified release payload,
processes it locally,

78
00:05:25,556 --> 00:05:27,856
and pulls the correct asset in one go.

79
00:05:28,436 --> 00:05:31,886
That single-call optimization drastically
reduces the footprint,

80
00:05:32,296 --> 00:05:36,436
making CI pipelines and corporate
enterprise setups way more resilient to

81
00:05:36,456 --> 00:05:37,736
rate-limiting.

82
00:05:37,789 --> 00:05:40,489
That's a massive relief for DevOps teams.

83
00:05:40,509 --> 00:05:44,729
And speaking of keeping developers
informed, there's also some interesting work on

84
00:05:44,769 --> 00:05:49,369
the terminal UI side in PR #31064.

85
00:05:50,049 --> 00:05:53,789
They've introduced streamed buffering
payload metadata.

86
00:05:53,849 --> 00:05:58,709
Essentially, when the CLI is waiting for
model responses or transitioning between

87
00:05:58,749 --> 00:06:02,889
processing states, it can now stream
real-time buffering indicators.

88
00:06:03,569 --> 00:06:07,319
No more frozen terminal cursors making you
wonder if the agent crashed.

89
00:06:08,218 --> 00:06:12,587
Right, it gives you that visual feedback
that things are actually happening behind

90
00:06:12,607 --> 00:06:13,127
the scenes.

91
00:06:14,007 --> 00:06:17,367
Oh, and they also did some housekeeping in
that same PR.

92
00:06:17,907 --> 00:06:23,727
The experimental child_agents_md feature
was completely removed from the schema.

93
00:06:24,327 --> 00:06:27,757
It looks like they're consolidating how
agent metadata is handled,

94
00:06:28,227 --> 00:06:32,127
stripping out features that didn't
graduate from the experimental phase to keep the

95
00:06:32,167 --> 00:06:33,027
codebase clean.

96
00:06:33,877 --> 00:06:36,477
Yeah, keeping the schema lean is always a
good move.

97
00:06:37,037 --> 00:06:38,737
Well, that's a wrap on this Quick Take.

98
00:06:39,137 --> 00:06:40,177
We'll catch you in the next one.

99
00:06:41,503 --> 00:06:41,514
See ya!