1
00:00:00,580 --> 00:00:06,090
If you have ever found yourself mindlessly
slamming the enter key to approve yet

2
00:00:06,140 --> 00:00:09,460
another read-only file scan while using
Codex...

3
00:00:10,260 --> 00:00:11,390
yeah, you're not alone.

4
00:00:12,040 --> 00:00:16,190
I was doing this literally yesterday, just
hitting "allow, allow,

5
00:00:16,580 --> 00:00:20,630
allow" for basic search tasks until my
finger got tired.

6
00:00:21,959 --> 00:00:24,449
Oh, the classic authorization fatigue.

7
00:00:24,779 --> 00:00:29,309
It-it-it totally defeats the purpose of
having a security prompt in the first place

8
00:00:29,339 --> 00:00:33,549
because after the tenth time, you just
stop reading what the tool is actually doing.

9
00:00:34,323 --> 00:00:35,283
Exactly.

10
00:00:35,323 --> 00:00:42,043
Which is why this new update, version
0.144.0, is such a big deal.

11
00:00:42,063 --> 00:00:45,853
They've introduced a new app-approval mode
called "writes".

12
00:00:46,523 --> 00:00:50,483
And by the way, a quick shout-out to
Jellypod for helping make this daily show a

13
00:00:50,503 --> 00:00:51,043
reality.

14
00:00:51,743 --> 00:00:55,843
But yeah, this "writes" mode is designed
to solve exactly that problem.

15
00:00:56,502 --> 00:00:58,502
Okay, so "writes" mode.

16
00:00:59,082 --> 00:00:59,842
How does it work?

17
00:01:00,232 --> 00:01:03,362
Does it just, like, guess what's safe and
what isn't?

18
00:01:04,249 --> 00:01:05,770
Not quite guessing, no.

19
00:01:06,330 --> 00:01:08,270
It's an explicit configuration.

20
00:01:08,910 --> 00:01:15,630
You open up your config file at
~/.codex/config.toml and you set

21
00:01:16,010 --> 00:01:19,330
default_tools_approval_mode = "writes".

22
00:01:20,150 --> 00:01:22,950
What this does is it splits your tools
into two camps.

23
00:01:23,610 --> 00:01:28,560
If a tool is just doing a passive,
read-only task-like listing a directory,

24
00:01:29,010 --> 00:01:33,870
reading a file, searching a codebase-it
executes instantly.

25
00:01:33,950 --> 00:01:35,850
No prompt, no interruption.

26
00:01:36,523 --> 00:01:41,173
But the moment it tries to, say, modify a
file, run a build,

27
00:01:41,243 --> 00:01:42,883
or delete something...

28
00:01:42,943 --> 00:01:45,023
it stops and asks you?

29
00:01:45,147 --> 00:01:46,287
Precisely.

30
00:01:46,347 --> 00:01:50,217
It only prompts you when a tool attempts a
modifying action.

31
00:01:50,247 --> 00:01:55,267
So you get a seamless flow for
exploration, but a hard stop for actual changes.

32
00:01:55,864 --> 00:01:59,253
That sounds incredibly convenient, but...

33
00:01:59,313 --> 00:02:04,413
as someone who used to work in testing, my
immediate thought is: how does Codex

34
00:02:04,513 --> 00:02:06,983
actually *know* a tool is only reading?

35
00:02:07,633 --> 00:02:10,392
Is it inspecting the code, or...

36
00:02:10,472 --> 00:02:12,793
is it just relying on how the tool
describes itself?

37
00:02:13,541 --> 00:02:15,601
Ah, you hit the nail right on the head.

38
00:02:16,181 --> 00:02:17,761
And this is the security catch.

39
00:02:18,361 --> 00:02:21,761
It entirely relies on the tool's schema
and declarations.

40
00:02:22,501 --> 00:02:28,381
Codex looks at the Model Context Protocol,
or MCP, tool definition to see if it's

41
00:02:28,421 --> 00:02:30,380
flagged as a write operation.

42
00:02:30,461 --> 00:02:36,001
So, if you're using a third-party,
untrusted, or just a poorly written MCP server,

43
00:02:36,601 --> 00:02:39,241
and they misdeclare a write command as a
read...

44
00:02:39,981 --> 00:02:41,801
Codex might run it without asking you.

45
00:02:43,473 --> 00:02:43,833
Oh.

46
00:02:44,653 --> 00:02:50,873
That's a pretty massive loophole if you're
pulling in random community MCP servers.

47
00:02:50,933 --> 00:02:56,453
If a server says a tool called
delete_database is just a "query" tool...

48
00:02:56,513 --> 00:02:57,482
it just runs?

49
00:02:58,271 --> 00:03:03,120
Technically, yes, if the schema is
malformed or maliciously declared.

50
00:03:03,731 --> 00:03:08,671
So, while setting
default_tools_approval_mode = "writes" is a massive

51
00:03:08,751 --> 00:03:13,991
quality-of-life upgrade, you really only
want to do it if you trust the MCP servers

52
00:03:14,031 --> 00:03:15,391
you have active.

53
00:03:15,451 --> 00:03:18,731
If you're running experimental servers
from random GitHub repos,

54
00:03:19,231 --> 00:03:22,091
you might want to stick to the strict
"always ask" mode.

55
00:03:23,448 --> 00:03:27,147
Right, keep those guardrails up if you're
playing in the wild west.

56
00:03:27,707 --> 00:03:32,647
But speaking of things breaking, let's
talk about the immediate follow-up patch,

57
00:03:32,987 --> 00:03:39,807
v0.144.1, because they had to fix a rather
nasty macOS packaging bug

58
00:03:39,968 --> 00:03:41,487
right after releasing this, didn't they?

59
00:03:42,217 --> 00:03:48,987
Yeah, v0.144.1 was basically an emergency
rescue mission for macOS users.

60
00:03:49,687 --> 00:03:56,327
In the 144.0 release, the companion host
binary was completely missing from the

61
00:03:56,367 --> 00:03:57,967
macOS package.

62
00:03:58,047 --> 00:04:02,987
So, if you tried to run in code-mode, the
whole thing would just crash instantly

63
00:04:03,027 --> 00:04:05,167
because it couldn't find its partner
process.

64
00:04:05,833 --> 00:04:06,753
Oh no!

65
00:04:07,253 --> 00:04:09,873
That's a pretty terminal bug for a
release.

66
00:04:10,917 --> 00:04:12,497
Yeah, it-it-it wasn't great.

67
00:04:13,097 --> 00:04:19,956
But what's cool about the fix in
144.1-specifically PR #31913-is

68
00:04:19,997 --> 00:04:22,617
they didn't just repackage the binary.

69
00:04:22,637 --> 00:04:25,327
They actually added an automatic runtime
fallback.

70
00:04:25,837 --> 00:04:31,517
So now, if the companion binary is ever
missing or fails to launch for some reason,

71
00:04:31,557 --> 00:04:36,517
Codex automatically falls back to an
embedded runtime inside the main process.

72
00:04:37,217 --> 00:04:40,077
It prevents the crash entirely and keeps
you working.

73
00:04:40,707 --> 00:04:42,327
That's incredibly resilient.

74
00:04:42,967 --> 00:04:47,197
It's always nice when a bug fix actually
makes the architecture better instead of

75
00:04:47,247 --> 00:04:49,447
just patching over the hole.

76
00:04:49,467 --> 00:04:53,947
Were there other things in 144.1, or was
it just that macOS rescue?

77
00:04:54,791 --> 00:04:58,801
No, they actually snuck in some really
nice quality-of-life updates.

78
00:04:59,451 --> 00:05:05,131
For one, interactive authentication for
MCP tools is now fully supported without

79
00:05:05,171 --> 00:05:07,591
needing any experimental flags.

80
00:05:07,651 --> 00:05:12,391
They also polished up how usage credits
are handled-now you can see granular

81
00:05:12,511 --> 00:05:18,531
usage-limit resets with explicit
expiration dates, so you know exactly when your API

82
00:05:18,591 --> 00:05:19,991
limits reload.

83
00:05:20,098 --> 00:05:21,818
Oh, that's huge.

84
00:05:21,898 --> 00:05:24,278
I hate guessing when my token bucket
resets.

85
00:05:25,018 --> 00:05:26,298
What about the terminal rendering?

86
00:05:26,898 --> 00:05:29,548
I saw something in the changelog about
control characters.

87
00:05:30,368 --> 00:05:34,488
Right, they fixed a terminal rendering bug
where raw control characters were

88
00:05:34,548 --> 00:05:38,088
slipping through and messing up the TUI
display.

89
00:05:38,108 --> 00:05:42,748
They're now sanitizing those control
sequences so your terminal stays clean and

90
00:05:42,808 --> 00:05:46,708
readable instead of getting filled with
ANSI escape code garbage.

91
00:05:48,085 --> 00:05:49,045
Thank goodness.

92
00:05:49,485 --> 00:05:53,205
No more weird broken progress bars taking
over the screen.

93
00:05:53,925 --> 00:05:58,145
Alright, I'm going to go update my config
file to "writes" mode now.

94
00:05:58,925 --> 00:05:59,665
Catch you later, Ethan.

95
00:06:00,485 --> 00:06:01,095
Sounds good.

96
00:06:01,465 --> 00:06:02,045
Talk soon.