1
00:00:00,100 --> 00:00:06,490
We- we have to look at what just broke in
the v0.144.1 release of Codex because it-

2
00:00:06,760 --> 00:00:12,300
it completely exposes the fragility of
relying on external platform APIs for

3
00:00:12,320 --> 00:00:13,900
bootstrap packaging.

4
00:00:13,980 --> 00:00:18,540
This update was supposed to be a standard
point release, but it- it instantly

5
00:00:18,550 --> 00:00:24,320
uncovered this weird architectural split
between the core codex CLI and the

6
00:00:24,380 --> 00:00:26,400
companion code-mode host binary.

7
00:00:27,948 --> 00:00:29,228
Oh, it- it was a mess.

8
00:00:29,448 --> 00:00:32,488
Especially if you were trying to run
standalone installations.

9
00:00:33,548 --> 00:00:38,128
Before we dive into the actual schema
failure, quick shout-out to Jellypod for

10
00:00:38,208 --> 00:00:40,188
sponsoring the breakdown today.

11
00:00:40,208 --> 00:00:45,428
So, Ethan, the- the underlying issue here
is how the installer parsed GitHub's

12
00:00:45,488 --> 00:00:46,658
release payload, right?

13
00:00:47,555 --> 00:00:48,795
Right, exactly.

14
00:00:48,815 --> 00:00:54,435
GitHub rolled out this- this new, highly
compacted JSON format for their release

15
00:00:54,515 --> 00:00:55,455
metadata endpoint.

16
00:00:56,104 --> 00:01:01,855
The- the previous parser in the Codex
bootstrap script was expecting a very specific

17
00:01:01,995 --> 00:01:05,655
nested structure to locate the code-mode
host tarball.

18
00:01:06,415 --> 00:01:10,315
When GitHub stripped the- the redundant
keys to optimize payload size,

19
00:01:10,755 --> 00:01:15,845
the strict schema validation inside the
installer threw an unhandled exception.

20
00:01:16,455 --> 00:01:17,075
It just...

21
00:01:17,115 --> 00:01:17,685
it aborted.

22
00:01:18,647 --> 00:01:24,247
Which meant if a dev was setting up a
clean machine, the installer fetched the core

23
00:01:24,287 --> 00:01:29,047
codex CLI, failed to find the helper
binary because of that metadata schema

24
00:01:29,127 --> 00:01:34,307
mismatch, and- and then just halted the
entire bootstrap process.

25
00:01:34,347 --> 00:01:36,187
It didn't even gracefully degrade.

26
00:01:37,129 --> 00:01:39,109
Exactly, it- it was a hard block.

27
00:01:39,649 --> 00:01:45,669
And the irony is, on macOS, the code-mode
host isn't even strictly necessary for

28
00:01:45,749 --> 00:01:48,689
every local agent execution context.

29
00:01:48,709 --> 00:01:51,469
But the installer treated it as a hard
dependency.

30
00:01:52,139 --> 00:01:58,969
So, to resolve this in 0.144.1, the team
had to rewrite the- the runtime resolution

31
00:01:59,009 --> 00:01:59,369
logic.

32
00:02:00,100 --> 00:02:06,020
So instead of just fixing the JSON parser
to handle the new GitHub metadata format,

33
00:02:06,030 --> 00:02:09,539
they actually changed the execution
fallback?

34
00:02:09,585 --> 00:02:11,145
They did both, actually.

35
00:02:11,165 --> 00:02:15,485
But the- the more robust fix is the new
embedded runtime fallback.

36
00:02:16,185 --> 00:02:20,665
Now, if the code-mode host binary is
completely missing from the expected path--

37
00:02:21,285 --> 00:02:27,745
say, because of a network timeout or
another API schema change-- the core codex CLI

38
00:02:27,825 --> 00:02:33,274
catches that specific file-not-found error
and immediately spins up an internal,

39
00:02:33,645 --> 00:02:35,205
lightweight fallback agent.

40
00:02:35,893 --> 00:02:38,352
That's a massive improvement for
resilience.

41
00:02:39,023 --> 00:02:44,083
As a tester, I- I always hate when a
secondary helper binary completely tanks the

42
00:02:44,123 --> 00:02:45,632
primary application execution.

43
00:02:46,443 --> 00:02:51,523
Having that embedded fallback means macOS
devs aren't blocked by external API

44
00:02:51,643 --> 00:02:54,063
contract changes they have zero control
over.

45
00:02:54,837 --> 00:02:58,457
But that's- that's actually nothing
compared to what's been happening on the Windows

46
00:02:58,517 --> 00:02:58,797
side.

47
00:02:59,437 --> 00:03:04,547
There is a newly documented bug in Codex
Desktop running on Windows 11 that is

48
00:03:04,737 --> 00:03:09,697
literally bringing systems down to their
knees by exhausting the non-paged kernel

49
00:03:09,737 --> 00:03:10,937
memory pool.

50
00:03:11,515 --> 00:03:16,585
Wait, a desktop developer tool is
triggering kernel-level pool exhaustion?

51
00:03:17,065 --> 00:03:20,065
That- that is incredibly rare for a
user-space agent.

52
00:03:20,605 --> 00:03:23,185
How is it bypassing the OS boundaries like
that?

53
00:03:23,930 --> 00:03:26,890
It's doing it through a runaway process
spawning loop.

54
00:03:27,550 --> 00:03:33,180
What happens is, if Codex Desktop
encounters an empty or a- a corrupted .git

55
00:03:33,181 --> 00:03:38,010
directory in the active workspace, it- it
tries to identify the current branch

56
00:03:38,090 --> 00:03:38,350
state.

57
00:03:39,090 --> 00:03:45,270
To do that, it calls out to the local git
installation by executing git.exe

58
00:03:45,370 --> 00:03:49,080
rev-parse --abbrev-ref HEAD in the
background.

59
00:03:49,817 --> 00:03:53,257
Okay, calling git rev-parse is standard.

60
00:03:53,817 --> 00:03:55,797
But why does that leak kernel memory?

61
00:03:56,217 --> 00:03:56,457
Is it...

62
00:03:56,857 --> 00:03:58,957
is it not closing the process handles?

63
00:03:59,872 --> 00:04:01,692
It's- it's a combination of two things.

64
00:04:02,252 --> 00:04:08,812
First, the- the folder state causes
git.exe to fail and return an exit code 128

65
00:04:08,832 --> 00:04:11,472
because there's no valid repository
configuration.

66
00:04:12,142 --> 00:04:15,232
But the Codex event loop doesn't back off
on that failure.

67
00:04:15,832 --> 00:04:18,072
It immediately schedules another check...

68
00:04:18,732 --> 00:04:19,322
and another...

69
00:04:20,052 --> 00:04:23,452
looping infinitely, thousands of times a
minute.

70
00:04:23,883 --> 00:04:24,523
Oh, wow.

71
00:04:24,723 --> 00:04:27,753
So it's- it's a tight loop of process
creation.

72
00:04:28,519 --> 00:04:31,469
Yes, and- and here is the Windows-specific
kicker.

73
00:04:32,259 --> 00:04:38,008
Every single time a new git.exe process is
spawned, the Windows kernel allocates a

74
00:04:38,039 --> 00:04:43,649
set of security tokens, specifically Token
objects, which show up in diagnostic

75
00:04:43,719 --> 00:04:45,539
tools under the Toke pool tag.

76
00:04:46,159 --> 00:04:50,819
Because of the sheer velocity of these
spawns, and- and how the handle inheritance

77
00:04:50,879 --> 00:04:55,299
was configured in the node-based desktop
wrapper, the kernel can't release those

78
00:04:55,339 --> 00:04:56,879
Toke allocations fast enough.

79
00:04:57,692 --> 00:05:03,232
Right, so the handle count in the system
just climbs exponentially until the

80
00:05:03,252 --> 00:05:08,152
non-paged pool is entirely filled with
these dead, but unreleased,

81
00:05:08,292 --> 00:05:09,492
Toke pool allocations.

82
00:05:10,152 --> 00:05:14,512
And once the non-paged pool is dry,
Windows 11 just...

83
00:05:14,532 --> 00:05:15,162
bugchecks.

84
00:05:15,772 --> 00:05:16,622
Blue screen of death.

85
00:05:17,449 --> 00:05:18,469
Exactly.

86
00:05:18,479 --> 00:05:21,489
You get a POOL_LIMIT_EXCEEDED or a
system-wide freeze.

87
00:05:21,589 --> 00:05:25,779
And developers were looking at their task
manager seeing thousands of orphaned

88
00:05:25,889 --> 00:05:29,649
zombie git.exe processes before the crash.

89
00:05:30,360 --> 00:05:31,660
That is wild.

90
00:05:32,300 --> 00:05:37,020
So, if someone is experiencing this right
now, what's the immediate workaround

91
00:05:37,060 --> 00:05:37,960
before they can update?

92
00:05:38,320 --> 00:05:40,260
Is there a way to break the loop manually?

93
00:05:41,085 --> 00:05:44,605
Yeah, it's actually incredibly simple once
you know what's triggering it.

94
00:05:45,045 --> 00:05:49,305
You just have to make the repository valid
or remove the broken reference.

95
00:05:50,045 --> 00:05:55,505
Running a clean git init inside that empty
folder, or- or just completely deleting

96
00:05:55,515 --> 00:06:00,715
the empty .git subdirectory, immediately
stops the background watcher from failing.

97
00:06:01,385 --> 00:06:06,245
The moment the watcher gets a successful
return code or sees no directory at all,

98
00:06:06,785 --> 00:06:09,465
the process execution drops back down to
zero.

99
00:06:10,968 --> 00:06:13,268
It's always the simplest things.

100
00:06:13,748 --> 00:06:18,608
A tiny, corrupt .git folder causing a full
kernel-level crash.

101
00:06:19,348 --> 00:06:20,928
Good to know there's an instant fix.

102
00:06:21,788 --> 00:06:22,228
Definitely.

103
00:06:22,628 --> 00:06:28,768
Well, that's- that's the state of the
v0.144.1 release and the Windows kernel

104
00:06:28,808 --> 00:06:29,198
issues.

105
00:06:29,708 --> 00:06:30,548
Good chatting, Maya.

106
00:06:31,249 --> 00:06:32,409
Yeah, talk soon, Ethan.