Codex CLI 0.142.5 Breaks Windows, Mac Hooks, and Dev Drives

Ethan Park

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.

Maya

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.

Ethan Park

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."

Maya

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?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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.

Maya

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.

Ethan Park

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?

Maya

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?

Ethan Park

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.

Maya

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.

Ethan Park

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.