1
00:00:00,119 --> 00:00:03,619
You know, thanks to Jellypod for helping
us bring this show out daily,

2
00:00:04,259 --> 00:00:04,480
but...

3
00:00:05,139 --> 00:00:10,300
okay, if you have ever run a multi day
agentic refactoring session in Codex,

4
00:00:10,920 --> 00:00:13,399
you know the absolute horror of the
sidebar.

5
00:00:14,059 --> 00:00:18,219
It just turns into this endless, linear,
scrolling avalanche.

6
00:00:18,760 --> 00:00:23,459
And then, er, you try to open a transcript
with like a hundred plus turns,

7
00:00:23,920 --> 00:00:28,599
and your whole TUI just freezes solid
while it tries to render giant logs.

8
00:00:29,944 --> 00:00:32,044
Oh, I, I have been there!

9
00:00:32,544 --> 00:00:36,125
It is, uh, complete terminal paralysis.

10
00:00:36,625 --> 00:00:41,104
You sit there watching your screen freeze
while it loads every single line of text

11
00:00:41,144 --> 00:00:42,465
from three days ago.

12
00:00:43,030 --> 00:00:44,069
Exactly.

13
00:00:44,129 --> 00:00:49,469
But in Codex zero point one four seven
point zero, they finally addressed this head

14
00:00:49,549 --> 00:00:50,250
on.

15
00:00:50,349 --> 00:00:53,189
Maya, what did they actually change in the
sidebar state?

16
00:00:53,729 --> 00:00:59,529
Right, so pull requests thirty five seven
two two, thirty six zero zero seven,

17
00:00:59,849 --> 00:01:04,809
and thirty six three eight zero bring in
proper persistent thread sections.

18
00:01:04,889 --> 00:01:09,729
So instead of just sorting strictly by
recency or having a flat pinned list,

19
00:01:09,850 --> 00:01:14,750
you can actually organize conversations
into persistent, manually ordered sections

20
00:01:14,930 --> 00:01:16,149
right inside your sidebar.

21
00:01:16,621 --> 00:01:18,441
Wait, manually ordered sections?

22
00:01:19,002 --> 00:01:23,441
So I can, like, build a dedicated section
for my database migration agent,

23
00:01:23,982 --> 00:01:28,002
and another one for API refactoring, and
they just stay where I put them?

24
00:01:28,521 --> 00:01:29,181
Yes!

25
00:01:29,441 --> 00:01:30,742
Exactly that.

26
00:01:31,282 --> 00:01:35,901
They don't jump around every time an
automated background run pings a session.

27
00:01:36,521 --> 00:01:41,701
You drag or assign them into custom
groups, and those groups persist across

28
00:01:41,781 --> 00:01:42,781
restarts.

29
00:01:42,841 --> 00:01:45,621
It stops the sidebar chaos completely.

30
00:01:46,137 --> 00:01:48,557
Man, that is huge for long running
projects.

31
00:01:49,157 --> 00:01:52,938
But what about that TUI freeze when you
actually click into one of those huge

32
00:01:52,977 --> 00:01:53,958
threads?

33
00:01:54,017 --> 00:01:55,597
How did they fix the rendering lag?

34
00:01:56,004 --> 00:02:01,504
So that was pull requests thirty six nine
four eight, thirty six nine five zero,

35
00:02:02,065 --> 00:02:04,065
and thirty six nine eight three.

36
00:02:04,965 --> 00:02:09,465
Basically, they ripped out the old
behavior where the entire transcript was shoved

37
00:02:09,505 --> 00:02:10,984
into memory all at once.

38
00:02:11,645 --> 00:02:14,725
Now, you can browse long transcripts
incrementally.

39
00:02:15,223 --> 00:02:18,083
Wait, browse long transcripts
incrementally?

40
00:02:18,662 --> 00:02:21,362
How does that work under the hood with the
SQLite database?

41
00:02:21,776 --> 00:02:27,296
They implemented paginated queries using
includeTurns against the local SQLite state

42
00:02:27,357 --> 00:02:27,857
database.

43
00:02:28,397 --> 00:02:31,556
So when you open a session with a hundred
or two hundred turns,

44
00:02:32,016 --> 00:02:36,256
it only fetches and renders the slice of
history you are actively viewing.

45
00:02:36,816 --> 00:02:40,556
As you scroll up or down, it pulls the
next chunk incrementally.

46
00:02:41,337 --> 00:02:42,976
Zero terminal redraw lag.

47
00:02:43,471 --> 00:02:44,931
Wow, that is...

48
00:02:44,971 --> 00:02:48,991
that is night and day compared to forcing
the terminal buffer to parse three

49
00:02:49,031 --> 00:02:52,052
megabytes of raw json text instantly.

50
00:02:52,132 --> 00:02:57,351
But, uh, speaking of that SQLite database,
aren't there a few caveats with how state

51
00:02:57,391 --> 00:02:58,052
locks work now?

52
00:02:58,442 --> 00:02:59,522
Oh, absolutely.

53
00:03:00,022 --> 00:03:03,382
That is pull request thirty six three
eight nine.

54
00:03:04,302 --> 00:03:09,643
The local state DB now strictly enforces
single writer thread history constraints.

55
00:03:10,182 --> 00:03:14,862
So if you have multiple agent subprocesses
trying to write back to the exact same

56
00:03:15,003 --> 00:03:19,943
thread state simultaneously, you will hit
lock exceptions unless they queue up

57
00:03:19,982 --> 00:03:20,442
properly.

58
00:03:21,136 --> 00:03:22,756
Right, single writer locks.

59
00:03:23,256 --> 00:03:28,336
And what happens when someone upgrades to
zero point one four seven point zero and

60
00:03:28,417 --> 00:03:31,177
opens a legacy session file from an older
version?

61
00:03:31,590 --> 00:03:32,789
They thought of that too.

62
00:03:33,430 --> 00:03:39,389
Pull request thirty seven one seven five
adds an automatic legacy rollout migration.

63
00:03:40,069 --> 00:03:43,309
The first time you launch zero point one
four seven point zero,

64
00:03:43,869 --> 00:03:48,969
it detects your older pre upgrade session
files and migrates their schema into the

65
00:03:49,170 --> 00:03:52,369
new persistent section format in the
background.

66
00:03:52,449 --> 00:03:57,569
It is pretty seamless, but if you have
custom scripts mutating the raw DB,

67
00:03:58,069 --> 00:04:00,109
you need to be aware of that schema shift.

68
00:04:00,557 --> 00:04:05,297
Now, beyond the thread history stuff,
there is a massive security update in zero

69
00:04:05,477 --> 00:04:10,557
point one four seven point zero that I
think every developer needs to know about.

70
00:04:11,157 --> 00:04:16,237
Especially if you share terminal
recordings or replay conversation logs publicly.

71
00:04:16,611 --> 00:04:19,591
Ah, you mean the secret filtering changes?

72
00:04:20,182 --> 00:04:20,602
Yes!

73
00:04:20,981 --> 00:04:25,821
Pull requests thirty six eight nine three
and thirty six nine zero eight introduce

74
00:04:26,042 --> 00:04:27,961
automatic redaction across the board.

75
00:04:28,561 --> 00:04:33,281
The engine will now redact secrets and
complete bearer tokens from displayed

76
00:04:33,382 --> 00:04:35,801
commands and replayed conversation
history.

77
00:04:36,834 --> 00:04:39,774
Wait, complete bearer tokens?

78
00:04:40,474 --> 00:04:45,934
So if an agent executes a curl command
with a authorization header containing a raw

79
00:04:46,014 --> 00:04:50,234
OAuth token or an API key, it gets
scrubbed automatically?

80
00:04:50,824 --> 00:04:55,264
Scrubbed completely before it ever hits
your stdout rendering or your persistent

81
00:04:55,324 --> 00:04:56,105
replay logs.

82
00:04:56,764 --> 00:05:02,065
In earlier versions, if an agent echoed a
command, that full bearer token was saved

83
00:05:02,104 --> 00:05:05,604
verbatim in the TUI replay buffer.

84
00:05:05,684 --> 00:05:09,885
If you replayed that session on a stream
or attached it to a bug report,

85
00:05:10,424 --> 00:05:12,404
boom, your secret was leaked.

86
00:05:13,104 --> 00:05:15,944
Now, it detects those patterns and masks
them fully.

87
00:05:17,360 --> 00:05:22,420
That is going to save so many people from
accidentally revoking their API keys on

88
00:05:22,460 --> 00:05:23,639
live streams!

89
00:05:23,699 --> 00:05:25,579
That is a massive safety net.

90
00:05:26,182 --> 00:05:27,081
It really is.

91
00:05:27,501 --> 00:05:33,261
And on top of security, they also squashed
some extremely annoying TUI input bugs

92
00:05:33,621 --> 00:05:35,002
that were driving people crazy.

93
00:05:36,602 --> 00:05:40,262
Oh, like the dreaded terminal freeze when
switching windows?

94
00:05:40,802 --> 00:05:41,462
Exactly!

95
00:05:41,943 --> 00:05:46,402
Pull requests thirty five six four nine,
thirty five nine five seven,

96
00:05:46,862 --> 00:05:48,362
and thirty six eight three four.

97
00:05:49,222 --> 00:05:54,043
If you were using Ghostty or certain
multiplexers, clicking away from the terminal

98
00:05:54,102 --> 00:05:59,322
and coming back would often cause lost
keypresses, or stick the TUI input in a

99
00:05:59,442 --> 00:06:03,382
frozen state where it ignored keyboard
focus completely.

100
00:06:03,462 --> 00:06:08,062
That, plus background MCP server startup
hangs, are all resolved now.

101
00:06:09,222 --> 00:06:12,543
That Ghostty shortcut handling bug was
brutal.

102
00:06:13,222 --> 00:06:14,302
Glad that is fixed.

103
00:06:15,122 --> 00:06:17,883
Now, what about opening unfamiliar
projects?

104
00:06:18,242 --> 00:06:20,463
I saw something about directory trust?

105
00:06:21,113 --> 00:06:27,092
Right, pull requests thirty six nine six
zero and thirty seven one three two.

106
00:06:27,932 --> 00:06:33,532
Codex now enforces an explicit directory
trust guard when you open or target an

107
00:06:33,572 --> 00:06:34,933
unfamiliar repository.

108
00:06:35,552 --> 00:06:40,513
Before it reads workspace configuration or
executes any local tools,

109
00:06:40,572 --> 00:06:43,833
it prompts you to confirm that you trust
the repository root.

110
00:06:44,354 --> 00:06:50,375
So an agent cannot just silently execute
malicious workspace settings embedded in an

111
00:06:50,434 --> 00:06:52,074
untrusted repo you just cloned?

112
00:06:52,596 --> 00:06:53,296
Precisely.

113
00:06:53,856 --> 00:06:58,397
It halts execution until you explicitly
grant trust for that folder path.

114
00:06:58,836 --> 00:07:02,596
So if we sum this up for someone updating
their environment today...

115
00:07:03,496 --> 00:07:07,516
set up your persistent thread sections in
the sidebar to clean up your workspace,

116
00:07:08,297 --> 00:07:13,096
rest easy knowing long transcripts browse
incrementally without crashing your TUI,

117
00:07:13,816 --> 00:07:18,796
and make sure your team verifies their
SQLite state locks if they run parallel agent

118
00:07:18,837 --> 00:07:19,636
orchestrations.

119
00:07:20,156 --> 00:07:20,896
Spot on.

120
00:07:21,397 --> 00:07:25,897
That is zero point one four seven point
zero in a nutshell.

121
00:07:25,996 --> 00:07:27,296
Good stuff as always, Maya.

122
00:07:28,595 --> 00:07:29,314
Definitely.

123
00:07:29,835 --> 00:07:30,914
Talk to you tomorrow, Ethan!