1
00:00:00,500 --> 00:00:06,259
So, Ethan, I was sitting at my desk
yesterday, and my MacBook fan starts screaming.

2
00:00:06,559 --> 00:00:11,840
Like, really screaming, which is weird
because I'm just idling in a terminal window.

3
00:00:12,519 --> 00:00:16,219
So I pull up the activity monitor, then
run a quick lsof, and...

4
00:00:17,000 --> 00:00:19,819
oh my god, the write counters are spiking.

5
00:00:20,340 --> 00:00:23,239
Gigabytes of data just flying onto my SSD.

6
00:00:24,079 --> 00:00:26,420
And it turns out, it's Codex.

7
00:00:27,990 --> 00:00:30,429
The silent killer of solid state drives.

8
00:00:31,089 --> 00:00:33,489
Yeah, you are definitely not the only one
seeing this.

9
00:00:34,129 --> 00:00:39,409
There is this massive SQLite log write
loop in the macOS Desktop build

10
00:00:40,049 --> 00:00:46,209
26.721.41059 and the bundled codex-cli

11
00:00:46,569 --> 00:00:50,449
0.146.0-alpha.3.1.

12
00:00:51,189 --> 00:00:53,090
It is literally hammering drives.

13
00:00:53,426 --> 00:00:54,566
But why?

14
00:00:54,966 --> 00:00:57,806
I mean, I'm not even running a heavy agent
loop.

15
00:00:57,886 --> 00:00:58,306
I was just...

16
00:00:59,306 --> 00:00:59,966
coding.

17
00:01:01,306 --> 00:01:02,406
What is it writing?

18
00:01:02,951 --> 00:01:03,711
It's logging.

19
00:01:04,391 --> 00:01:04,972
Everything.

20
00:01:05,551 --> 00:01:10,272
Specifically, the developers left a
hardcoded LevelFilter TRACE fallback in the

21
00:01:10,351 --> 00:01:12,071
SQLite log sink.

22
00:01:12,151 --> 00:01:17,631
So even if you set your environment to
something like RUST_LOG equals warn to quiet

23
00:01:17,691 --> 00:01:20,812
things down, the app-server completely
ignores it.

24
00:01:21,411 --> 00:01:25,991
It's capturing every single Server-Sent
Event and local connection handshake.

25
00:01:26,651 --> 00:01:32,031
We are talking between 35 and 42 database
inserts every single second.

26
00:01:33,203 --> 00:01:35,462
Forty-two inserts a second?

27
00:01:35,922 --> 00:01:37,503
On a local dev machine?

28
00:01:38,742 --> 00:01:39,362
That is...

29
00:01:39,802 --> 00:01:43,023
I mean, that explains why my write
counters were going crazy.

30
00:01:43,622 --> 00:01:45,802
How much data are we actually talking
about here?

31
00:01:46,292 --> 00:01:51,412
It dumps up to 44 megabytes of transient
debug records into a file called

32
00:01:51,588 --> 00:01:56,052
logs_2.sqlite every 30 seconds.

33
00:01:56,265 --> 00:02:01,892
If you do the math on that, a heavy user
could end up silently writing terabytes of

34
00:02:01,952 --> 00:02:05,892
useless diagnostic junk to their drive
over a single year.

35
00:02:06,674 --> 00:02:07,994
My poor SSD.

36
00:02:08,694 --> 00:02:12,494
I actually went digging into that
logs_2.sqlite file.

37
00:02:13,315 --> 00:02:14,314
The WAL file...

38
00:02:14,394 --> 00:02:15,534
the write-ahead log...

39
00:02:16,114 --> 00:02:19,175
was sitting at 760 megabytes.

40
00:02:19,854 --> 00:02:22,815
But when I actually queried the database,
it was like...

41
00:02:22,854 --> 00:02:24,594
mostly empty space, right?

42
00:02:25,076 --> 00:02:25,856
Oh, totally.

43
00:02:26,216 --> 00:02:30,076
Because the app has this aggressive loop
where it inserts a row,

44
00:02:30,496 --> 00:02:31,756
then immediately prunes it.

45
00:02:32,256 --> 00:02:36,576
It's just churning through memory and disk
space, doing a dance of writing and

46
00:02:36,676 --> 00:02:41,917
erasing, leaving nothing but fragmented
empty space in the actual database file.

47
00:02:42,677 --> 00:02:45,917
It was eighty-six percent empty space when
we analyzed it.

48
00:02:46,238 --> 00:02:47,297
Unbelievable.

49
00:02:47,977 --> 00:02:51,777
Okay, so before our listeners go and
uninstall the whole thing,

50
00:02:52,137 --> 00:02:55,198
there is a brilliant workaround that the
community figured out.

51
00:02:55,597 --> 00:02:58,357
And it's a database-level fix, which I
love.

52
00:02:58,757 --> 00:03:00,497
You don't have to wait for an official
patch.

53
00:03:00,992 --> 00:03:01,892
Wait, a trigger?

54
00:03:02,492 --> 00:03:06,632
You're using an SQL trigger to block the
app from talking to its own database?

55
00:03:06,947 --> 00:03:07,986
Exactly!

56
00:03:08,446 --> 00:03:12,366
You just open up your terminal, run
sqlite3 on

57
00:03:12,446 --> 00:03:19,146
~/.codex/logs_2.sqlite, and then you run
this exact command: CREATE

58
00:03:19,186 --> 00:03:25,526
TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs BEGIN

59
00:03:26,026 --> 00:03:31,806
SELECT RAISE(IGNORE); END; Oh, that is
dirty.

60
00:03:31,907 --> 00:03:32,926
I love it.

61
00:03:32,986 --> 00:03:37,667
It just intercepts the insert statement
before it ever hits the actual disk,

62
00:03:37,706 --> 00:03:39,187
and silently throws it away.

63
00:03:39,649 --> 00:03:39,930
Yep.

64
00:03:40,289 --> 00:03:42,409
It intercepts it at the engine level.

65
00:03:42,909 --> 00:03:45,609
No disk write, no SSD wear and tear.

66
00:03:46,250 --> 00:03:50,189
The parent Rust process has absolutely no
idea it's happening.

67
00:03:50,649 --> 00:03:52,789
It doesn't crash, it doesn't throw errors.

68
00:03:53,210 --> 00:03:56,189
It just thinks the write succeeded and
goes on its merry way.

69
00:03:56,641 --> 00:03:58,881
But wait, there's got to be a catch.

70
00:03:59,481 --> 00:04:04,141
If the database is completely empty, what
happens when you actually need to debug

71
00:04:04,201 --> 00:04:04,561
something?

72
00:04:05,281 --> 00:04:07,842
Or, say, use the slash feedback command?

73
00:04:08,296 --> 00:04:08,676
Ah.

74
00:04:09,017 --> 00:04:09,236
Yeah.

75
00:04:09,537 --> 00:04:10,917
That's the major tradeoff.

76
00:04:11,456 --> 00:04:15,456
If you run that trigger, your diagnostic
tables are bone dry.

77
00:04:15,996 --> 00:04:20,016
So if you try to submit feedback or export
your local troubleshooting logs to the

78
00:04:20,076 --> 00:04:23,636
developers, they are going to get a
completely blank report.

79
00:04:24,296 --> 00:04:25,456
But honestly?

80
00:04:25,517 --> 00:04:29,417
For me, saving my hardware is worth losing
the feedback feature for a bit.

81
00:04:29,929 --> 00:04:31,389
Yeah, I'd make that trade too.

82
00:04:31,990 --> 00:04:37,309
But speaking of bugs and rapid updates,
OpenAI has been pushing out new alpha builds

83
00:04:37,349 --> 00:04:41,429
on the v0.146.0 track like crazy.

84
00:04:42,170 --> 00:04:48,649
We just got 0.146.0-alpha.5 on July 23,

85
00:04:49,029 --> 00:04:55,029
2026, and its main job is to revert a
feature they literally just introduced in

86
00:04:55,129 --> 00:04:57,529
v0.145.0.

87
00:04:57,942 --> 00:05:00,922
Wait, they are reverting a feature
already?

88
00:05:01,402 --> 00:05:01,862
Which one?

89
00:05:02,208 --> 00:05:04,928
The experimental paginated chat history.

90
00:05:05,088 --> 00:05:09,968
It was designed to keep the terminal UI
nice and snappy when you have massive

91
00:05:10,028 --> 00:05:10,808
threads.

92
00:05:10,898 --> 00:05:15,648
But it ended up causing catastrophic agent
boot loops and startup freezes.

93
00:05:16,026 --> 00:05:17,147
Oh, interesting.

94
00:05:17,806 --> 00:05:20,806
Why would pagination break the startup
sequence?

95
00:05:21,546 --> 00:05:22,526
Isn't it just...

96
00:05:22,746 --> 00:05:24,706
loading less data at once?

97
00:05:25,182 --> 00:05:28,282
You'd think so, but here's the
architectural catch.

98
00:05:28,941 --> 00:05:32,221
While paginating the chat is great for a
human looking at a screen,

99
00:05:32,821 --> 00:05:36,761
the background agent loop and your local
Model Context Protocol...

100
00:05:37,321 --> 00:05:38,661
the MCP servers...

101
00:05:39,361 --> 00:05:43,161
they need to reconstruct the entire state
tree when they boot up.

102
00:05:43,222 --> 00:05:45,461
They need to see everything that happened
before.

103
00:05:45,901 --> 00:05:46,162
Oh!

104
00:05:46,301 --> 00:05:47,361
Of course!

105
00:05:47,901 --> 00:05:51,701
If you restrict the database query to just
one page of history,

106
00:05:52,261 --> 00:05:57,141
the boot sequence can't see the previous
agent turns, or the child spawns,

107
00:05:57,201 --> 00:05:59,821
or even the active handshake boundaries.

108
00:05:59,882 --> 00:06:01,501
It's essentially blind.

109
00:06:02,152 --> 00:06:03,172
Exactly.

110
00:06:03,212 --> 00:06:07,152
And because it's blind, the CLI just hangs
indefinitely on launch,

111
00:06:07,632 --> 00:06:11,152
spitting out "MCP client failed to start"
errors.

112
00:06:11,772 --> 00:06:14,753
It was completely locking people out of
their terminal sessions.

113
00:06:15,191 --> 00:06:15,711
Wow.

114
00:06:15,971 --> 00:06:22,171
Okay, so if someone is currently stuck on
v0.145.0 or

115
00:06:22,571 --> 00:06:28,012
0.145.2, and their terminal is just
frozen, what are the recovery paths?

116
00:06:28,292 --> 00:06:30,092
Well, you have two options.

117
00:06:30,162 --> 00:06:37,092
You can either play it safe and downgrade
to the stable v0.144.x line,

118
00:06:37,145 --> 00:06:40,532
or you can leap forward to the alpha
branch, specifically

119
00:06:40,692 --> 00:06:47,572
0.146.0-alpha.5 or higher, where they
cleanly ripped the

120
00:06:47,637 --> 00:06:48,852
pagination code out.

121
00:06:49,152 --> 00:06:49,672
Hmm.

122
00:06:50,172 --> 00:06:55,333
Going to a bleeding-edge alpha branch to
fix a boot loop sounds like jumping from

123
00:06:55,352 --> 00:06:56,952
the frying pan into the fire.

124
00:06:57,572 --> 00:06:59,912
Are there other bugs lurking in those
alphas?

125
00:07:00,250 --> 00:07:01,530
Oh, absolutely.

126
00:07:01,637 --> 00:07:03,210
It is a bit of a minefield.

127
00:07:03,350 --> 00:07:10,330
For example, in 0.146.0-alpha.3.1, if you
use the

128
00:07:10,383 --> 00:07:17,370
official Meta Ads MCP endpoint at
mcp.facebook.com/ads,

129
00:07:17,410 --> 00:07:20,810
the streamable HTTP handshake fails
completely.

130
00:07:20,970 --> 00:07:27,530
It returns Sse(None) on the initialized
notification before any tools are even

131
00:07:27,610 --> 00:07:28,250
exposed.

132
00:07:28,490 --> 00:07:31,930
So you are totally locked out of your
ad-campaign tools.

133
00:07:33,716 --> 00:07:39,056
So, if you're managing Facebook ads via
your CLI, maybe stick to the stable

134
00:07:39,096 --> 00:07:39,816
downgrade for now.

135
00:07:40,396 --> 00:07:40,837
Good to know.

136
00:07:41,616 --> 00:07:43,116
Well, that's the bleeding edge for you!

137
00:07:43,616 --> 00:07:44,556
Talk to you next time, Ethan.

138
00:07:44,917 --> 00:07:45,957
Catch you later, Maya.