1
00:00:00,060 --> 00:00:04,080
If you're upgrading your local setup
today, you might want to hold off on...

2
00:00:04,680 --> 00:00:11,680
well, specifically on the 0.142.5 Codex
CLI release if you're on Windows

3
00:00:11,700 --> 00:00:12,520
or macOS.

4
00:00:13,240 --> 00:00:17,259
And thanks to Jellypod for helping make
this daily show a reality.

5
00:00:17,900 --> 00:00:23,140
But seriously, if you've already pulled
down 0.142.5 on Windows,

6
00:00:23,640 --> 00:00:28,520
you're probably seeing your sandbox tasks
throw "program not found" or,

7
00:00:28,740 --> 00:00:33,620
worse, completely locking up your local
file system deletions if you're on a Dev

8
00:00:33,680 --> 00:00:34,040
Drive.

9
00:00:34,540 --> 00:00:34,800
It's...

10
00:00:35,340 --> 00:00:36,000
it's a mess.

11
00:00:37,184 --> 00:00:39,114
Wait, "program not found"?

12
00:00:39,774 --> 00:00:40,114
Is this...

13
00:00:40,554 --> 00:00:44,494
are we talking about the actual runner
executable just vanishing,

14
00:00:44,734 --> 00:00:46,594
or is it a path resolution thing?

15
00:00:47,214 --> 00:00:50,794
Because my Windows sandbox setup
completely choked this morning.

16
00:00:51,590 --> 00:00:53,330
It's literally a packaging error.

17
00:00:53,990 --> 00:00:57,490
Issue #30856 on the repo.

18
00:00:57,550 --> 00:01:00,830
What happened is the build pipeline
misplaced the critical helper

19
00:01:00,910 --> 00:01:06,970
binaries--specifically
codex-windows-sandbox-setup.exe and

20
00:01:07,030 --> 00:01:08,990
codex-command-runner.exe.

21
00:01:09,710 --> 00:01:13,590
Instead of putting them in the bin/
directory where the CLI expects them,

22
00:01:14,150 --> 00:01:17,130
they got dumped into the codex-resources/
folder.

23
00:01:17,850 --> 00:01:22,270
So when the main process tries to spin up
the sandbox, you get this ugly

24
00:01:22,530 --> 00:01:29,150
CreateProcessWithLogonW failed: 2 error,
which is just Windows-speak for

25
00:01:29,510 --> 00:01:31,410
"I have no idea where this file is."

26
00:01:32,731 --> 00:01:35,880
Ah, error code 2, file not found.

27
00:01:36,460 --> 00:01:36,960
Classic.

28
00:01:37,920 --> 00:01:42,650
Okay, so if they're just in the wrong
folder, the manual workaround should be pretty

29
00:01:42,740 --> 00:01:43,960
simple, right?

30
00:01:44,060 --> 00:01:44,210
Just...

31
00:01:44,800 --> 00:01:47,900
I don't know, copy-paste them back where
they belong?

32
00:01:47,948 --> 00:01:48,598
Exactly.

33
00:01:49,108 --> 00:01:54,888
You have to manually grab those two files
from codex-resources/ and drop them into

34
00:01:54,928 --> 00:01:56,228
your active bin directory.

35
00:01:56,888 --> 00:02:01,688
It works, but here's the catch: the second
the CLI triggers an automatic

36
00:02:01,768 --> 00:02:06,248
self-update, it wipes that directory and
you're right back to a broken state.

37
00:02:07,028 --> 00:02:07,667
But...

38
00:02:07,728 --> 00:02:11,268
that's not even the most frustrating part
of this release for Windows users.

39
00:02:11,848 --> 00:02:18,008
There's a much nastier bug, #30840,
affecting anyone using

40
00:02:18,128 --> 00:02:22,198
ReFS--the Resilient File System--on their
Dev Drives.

41
00:02:22,847 --> 00:02:24,437
Wait, Dev Drives?

42
00:02:25,267 --> 00:02:30,367
Microsoft specifically designed those with
ReFS to make package restoration and file

43
00:02:30,447 --> 00:02:32,047
IO faster for developers.

44
00:02:32,747 --> 00:02:34,607
What's Codex doing to break that?

45
00:02:35,408 --> 00:02:41,308
So, when you run Codex in workspace-write
sandbox mode, it uses virtualized file

46
00:02:41,348 --> 00:02:41,668
layers.

47
00:02:42,408 --> 00:02:44,828
On NTFS, this works fine.

48
00:02:44,868 --> 00:02:49,688
But on ReFS, the way the sandbox driver
hooks into the filesystem filter...

49
00:02:50,348 --> 00:02:54,788
it-it basically locks the file handles
during write-sandbox executions.

50
00:02:55,508 --> 00:02:59,308
When Codex tries to clean up and delete
temporary files after a run,

51
00:03:00,068 --> 00:03:03,688
ReFS blocks the deletion with an Access
Denied error.

52
00:03:04,448 --> 00:03:08,328
You literally can't clean up your
workspace without restarting the entire

53
00:03:08,348 --> 00:03:12,048
workstation or resorting to a full sandbox
bypass flag.

54
00:03:13,242 --> 00:03:17,862
That completely defeats the purpose of
having a high-performance Dev Drive if you

55
00:03:17,902 --> 00:03:22,682
have to bypass the sandbox or go back to
NTFS just to delete a temp file.

56
00:03:23,532 --> 00:03:25,772
And it's not just a Windows party either.

57
00:03:26,912 --> 00:03:33,892
macOS developers on 0.142.5 are facing
their own hurdles with silent hook

58
00:03:33,992 --> 00:03:34,472
failures.

59
00:03:35,052 --> 00:03:41,902
If you rely on ~/.codex/hooks.json to run
local file-probe automation,

60
00:03:42,392 --> 00:03:47,792
both codex exec and the interactive TUI
are completely ignoring that config file

61
00:03:47,832 --> 00:03:48,492
now.

62
00:03:48,512 --> 00:03:51,032
It's issue #30835.

63
00:03:51,572 --> 00:03:56,232
Even if you force trust bypasses, the
hooks simply do not load.

64
00:03:56,652 --> 00:03:59,052
It's like the discovery logic just went
dark.

65
00:04:00,128 --> 00:04:00,848
That's wild.

66
00:04:01,368 --> 00:04:06,988
So any custom pre-commit hooks or local
analysis scripts you have bound to the TUI

67
00:04:07,028 --> 00:04:08,608
lifecycle are just...

68
00:04:09,478 --> 00:04:10,157
dead in the water?

69
00:04:10,495 --> 00:04:11,115
Yep.

70
00:04:11,575 --> 00:04:13,175
Completely silent.

71
00:04:13,655 --> 00:04:18,335
No warnings, no log output, just zero
execution.

72
00:04:19,235 --> 00:04:19,975
But...

73
00:04:20,035 --> 00:04:25,395
look, if there is a silver lining to all
of this, it's that relief is finally coming

74
00:04:25,435 --> 00:04:31,395
for everyone dealing with Codex's infamous
SSD-killing TRACE logs.

75
00:04:31,475 --> 00:04:36,835
Remember back on our June 24 episode, we
dug into those insane NVMe write wear

76
00:04:36,895 --> 00:04:37,275
issues?

77
00:04:38,289 --> 00:04:40,349
Oh, the SQLite WAL log growth!

78
00:04:40,729 --> 00:04:41,149
Yes!

79
00:04:41,669 --> 00:04:46,049
The community was tracking database writes
that were literally wearing out developer

80
00:04:46,149 --> 00:04:50,959
SSDs by writing gigabytes of TRACE logs
every single hour.

81
00:04:51,818 --> 00:04:52,447
Right!

82
00:04:52,547 --> 00:04:57,667
Well, they finally merged the fix for the
upcoming 0.143.0 release.

83
00:04:58,167 --> 00:05:05,027
It's PR #29599, and the title says it all:
"Stop persisting bridged log events."

84
00:05:05,727 --> 00:05:10,287
What was happening was that the bridged
logger was constantly writing every single

85
00:05:10,347 --> 00:05:15,887
trace-level event to the local database,
forcing the WAL file to grow exponentially.

86
00:05:15,927 --> 00:05:19,147
This new patch stops that persistence loop
entirely.

87
00:05:19,627 --> 00:05:24,427
TRACE logs will stay in memory or stream
out, but they won't be hammering your NVMe

88
00:05:24,527 --> 00:05:25,507
write limits anymore.

89
00:05:26,283 --> 00:05:27,743
That is a massive win.

90
00:05:28,323 --> 00:05:33,523
I mean, saving physical hardware from
unnecessary wear is about as high-stakes as a

91
00:05:33,563 --> 00:05:35,013
CLI bug fix gets.

92
00:05:35,763 --> 00:05:42,023
Let's hope they package those Windows
helper binaries correctly in 0.143.0 too,

93
00:05:42,663 --> 00:05:45,343
or we're going to be copying files
manually for a while.

94
00:05:46,083 --> 00:05:47,093
Catch you on the next update.