1
00:00:00,091 --> 00:00:04,800
So, I was looking through my local disk
space yesterday, and it- it turns out that

2
00:00:04,840 --> 00:00:09,020
Codex CLI's massive SSD-wear bug from June
24th...

3
00:00:10,090 --> 00:00:13,520
it was actually a whole lot worse than
just wearing down our hardware.

4
00:00:14,300 --> 00:00:18,740
And, uh, before we dive into how bad it
got, we have to thank Jellypod for making

5
00:00:18,800 --> 00:00:20,040
this daily show possible.

6
00:00:20,873 --> 00:00:26,702
Wait, worse than writing gigabytes of junk
telemetry to our NVMe drives?

7
00:00:27,702 --> 00:00:28,682
What- what else was it doing?

8
00:00:29,423 --> 00:00:36,192
It was writing raw, unredacted WebSocket
payloads straight to the local trace logs

9
00:00:36,232 --> 00:00:37,032
in plaintext.

10
00:00:37,612 --> 00:00:41,912
We are talking about your actual
proprietary code, prompt data,

11
00:00:42,572 --> 00:00:45,592
absolute file paths, and environment
variables.

12
00:00:46,292 --> 00:00:48,212
Just sitting there in a flat file.

13
00:00:48,923 --> 00:00:49,943
Oh, wow.

14
00:00:50,223 --> 00:00:55,443
So if you're working on a proprietary
codebase, all of that was just being dumped

15
00:00:55,483 --> 00:00:59,283
onto the local drive without any
encryption or masking?

16
00:01:00,224 --> 00:01:01,424
Exactly.

17
00:01:01,504 --> 00:01:06,524
If anyone got access to your machine, or
if you had log-forwarding tools sweeping up

18
00:01:06,564 --> 00:01:09,034
your home directory, your secrets were out
there.

19
00:01:09,844 --> 00:01:15,194
But, the good news is that version 0.142.5
is officially out,

20
00:01:15,864 --> 00:01:22,644
and it backports PR #30771 to finally,
thank goodness, redact these

21
00:01:22,684 --> 00:01:23,424
raw payloads.

22
00:01:24,204 --> 00:01:29,944
Okay, so PR #30771 basically acts as a
filter.

23
00:01:30,584 --> 00:01:34,284
But what about the logs that are already
sitting on our machines from before the

24
00:01:34,354 --> 00:01:34,674
patch?

25
00:01:35,114 --> 00:01:36,914
Do we have to go hunt them down manually?

26
00:01:37,668 --> 00:01:40,048
Yep, you definitely want to clean those
out.

27
00:01:40,108 --> 00:01:46,448
If you're on macOS or Linux, you'll find
them under ~/.codex/logs.

28
00:01:46,528 --> 00:01:53,007
If you're on Windows, check your
AppData\Local\Codex\logs directory.

29
00:01:53,568 --> 00:01:57,128
Just run a recursive delete on those
folders to wipe the slate clean.

30
00:01:57,984 --> 00:02:02,534
Right, but what about the Windows users
who are running portable environments?

31
00:02:02,994 --> 00:02:07,224
I- I remember some of them got stuck in a
bizarre update loop on version

32
00:02:07,624 --> 00:02:12,804
0.142.4 where it kept trying to pull the
update and failing.

33
00:02:14,138 --> 00:02:14,678
Oh, yeah.

34
00:02:15,218 --> 00:02:18,478
The portable Windows environments had a
path-resolution issue.

35
00:02:19,198 --> 00:02:24,438
If you're stuck in that loop, you have to
manually grab the 0.142.5 zip,

36
00:02:25,078 --> 00:02:29,328
unpack it over your existing binary, and
override the local executable.

37
00:02:30,098 --> 00:02:33,318
Don't rely on the auto-updater for that
specific transition.

38
00:02:34,368 --> 00:02:35,698
Okay, that makes sense.

39
00:02:36,388 --> 00:02:42,348
Now, speaking of weird bugs, what's the
deal with issue #30697?

40
00:02:42,948 --> 00:02:48,028
I've seen a few issues on GitHub about
model_reasoning_effort being completely

41
00:02:48,068 --> 00:02:50,628
ignored when people use custom model
slugs.

42
00:02:51,397 --> 00:02:54,517
Ah, this one is a classic Rust-level edge
case.

43
00:02:55,157 --> 00:02:56,117
It's hidden inside

44
00:02:56,177 --> 00:03:03,717
codex-rs/models-manager/src/manager.rs.

45
00:03:04,357 --> 00:03:08,226
Basically, if you route your CLI through a
custom, third-party,

46
00:03:08,597 --> 00:03:13,457
OpenAI-compatible gateway, you might use a
multi-segment model slug.

47
00:03:14,017 --> 00:03:19,957
Something like, uh,
provider/group/gpt-4o-mini or whatever.

48
00:03:20,771 --> 00:03:23,541
Right, because of how they namespace their
models.

49
00:03:24,201 --> 00:03:26,751
So why does the Rust code care about the
slashes?

50
00:03:27,573 --> 00:03:33,983
Well, inside manager.rs, there's a
function called find_model_by_namespaced_suffix.

51
00:03:34,033 --> 00:03:37,233
It tries to split the model string to find
the base model name.

52
00:03:37,833 --> 00:03:41,173
But because of those extra slashes in the
multi-segment slug,

53
00:03:41,653 --> 00:03:47,273
the suffix matcher gets confused, fails to
find a match, and quietly falls back to a

54
00:03:47,313 --> 00:03:48,893
default metadata profile.

55
00:03:50,693 --> 00:03:55,113
And that default profile assumes the model
has zero reasoning capabilities.

56
00:03:56,296 --> 00:04:01,596
So it just strips out the
model_reasoning_effort parameter entirely before sending

57
00:04:01,616 --> 00:04:02,646
the request over the wire?

58
00:04:03,396 --> 00:04:06,056
It doesn't even tell you it's doing it?

59
00:04:06,105 --> 00:04:06,755
Exactly!

60
00:04:07,225 --> 00:04:11,815
It silently drops the payload property
because it thinks the model doesn't support

61
00:04:11,845 --> 00:04:12,605
it.

62
00:04:12,625 --> 00:04:16,065
But there is a clean workaround if you
don't want to wait for another patch.

63
00:04:16,705 --> 00:04:21,605
You can use the model_catalog_json
configuration option in your local config file.

64
00:04:22,587 --> 00:04:23,416
Oh, interesting.

65
00:04:23,976 --> 00:04:25,096
How do we declare that?

66
00:04:25,516 --> 00:04:27,456
Do we just define the slug manually?

67
00:04:28,298 --> 00:04:30,778
Yeah, you explicitly define the model
schema.

68
00:04:31,378 --> 00:04:35,458
You add your multi-segment slug as the
key, and inside that object,

69
00:04:35,758 --> 00:04:38,238
you set supports_reasoning to true.

70
00:04:39,018 --> 00:04:43,578
When the CLI loads your local catalog
JSON, it bypasses that broken

71
00:04:43,918 --> 00:04:49,158
find_model_by_namespaced_suffix logic
entirely and respects your reasoning-effort

72
00:04:49,238 --> 00:04:50,838
configurations over the wire.

73
00:04:52,024 --> 00:04:54,174
That is a lifesaver for custom endpoints.

74
00:04:54,794 --> 00:04:58,634
Alright, I'm going to go update my config
and clean out those old log files.

75
00:04:59,054 --> 00:04:59,774
Good chatting with you!

76
00:05:00,669 --> 00:05:01,109
Same here.

77
00:05:01,629 --> 00:05:02,229
Talk to you later.