If you're upgrading your local setup today, you might want to hold off on...
well, specifically on the 0.142.5 Codex CLI release if you're on Windows
or macOS.
And thanks to Jellypod for helping make this daily show a reality.
But seriously, if you've already pulled down 0.142.5 on Windows,
you're probably seeing your sandbox tasks throw "program not found" or,
worse, completely locking up your local file system deletions if you're on a Dev
Drive.
It's...
it's a mess.
Wait, "program not found"?
Is this...
are we talking about the actual runner executable just vanishing,
or is it a path resolution thing?
Because my Windows sandbox setup completely choked this morning.
It's literally a packaging error.
Issue #30856 on the repo.
What happened is the build pipeline misplaced the critical helper
binaries--specifically codex-windows-sandbox-setup.exe and
codex-command-runner.exe.
Instead of putting them in the bin/ directory where the CLI expects them,
they got dumped into the codex-resources/ folder.
So when the main process tries to spin up the sandbox, you get this ugly
CreateProcessWithLogonW failed: 2 error, which is just Windows-speak for
"I have no idea where this file is."
Ah, error code 2, file not found.
Classic.
Okay, so if they're just in the wrong folder, the manual workaround should be pretty
simple, right?
Just...
I don't know, copy-paste them back where they belong?
Exactly.
You have to manually grab those two files from codex-resources/ and drop them into
your active bin directory.
It works, but here's the catch: the second the CLI triggers an automatic
self-update, it wipes that directory and you're right back to a broken state.
But...
that's not even the most frustrating part of this release for Windows users.
There's a much nastier bug, #30840, affecting anyone using
ReFS--the Resilient File System--on their Dev Drives.
Wait, Dev Drives?
Microsoft specifically designed those with ReFS to make package restoration and file
IO faster for developers.
What's Codex doing to break that?
So, when you run Codex in workspace-write sandbox mode, it uses virtualized file
layers.
On NTFS, this works fine.
But on ReFS, the way the sandbox driver hooks into the filesystem filter...
it-it basically locks the file handles during write-sandbox executions.
When Codex tries to clean up and delete temporary files after a run,
ReFS blocks the deletion with an Access Denied error.
You literally can't clean up your workspace without restarting the entire
workstation or resorting to a full sandbox bypass flag.
That completely defeats the purpose of having a high-performance Dev Drive if you
have to bypass the sandbox or go back to NTFS just to delete a temp file.
And it's not just a Windows party either.
macOS developers on 0.142.5 are facing their own hurdles with silent hook
failures.
If you rely on ~/.codex/hooks.json to run local file-probe automation,
both codex exec and the interactive TUI are completely ignoring that config file
now.
It's issue #30835.
Even if you force trust bypasses, the hooks simply do not load.
It's like the discovery logic just went dark.
That's wild.
So any custom pre-commit hooks or local analysis scripts you have bound to the TUI
lifecycle are just...
dead in the water?
Yep.
Completely silent.
No warnings, no log output, just zero execution.
But...
look, if there is a silver lining to all of this, it's that relief is finally coming
for everyone dealing with Codex's infamous SSD-killing TRACE logs.
Remember back on our June 24 episode, we dug into those insane NVMe write wear
issues?
Oh, the SQLite WAL log growth!
Yes!
The community was tracking database writes that were literally wearing out developer
SSDs by writing gigabytes of TRACE logs every single hour.
Right!
Well, they finally merged the fix for the upcoming 0.143.0 release.
It's PR #29599, and the title says it all: "Stop persisting bridged log events."
What was happening was that the bridged logger was constantly writing every single
trace-level event to the local database, forcing the WAL file to grow exponentially.
This new patch stops that persistence loop entirely.
TRACE logs will stay in memory or stream out, but they won't be hammering your NVMe
write limits anymore.
That is a massive win.
I mean, saving physical hardware from unnecessary wear is about as high-stakes as a
CLI bug fix gets.
Let's hope they package those Windows helper binaries correctly in 0.143.0 too,
or we're going to be copying files manually for a while.
Catch you on the next update.