Codex CLI 0.142.5 Fixes Log Leaks and Custom Model Reasoning
We break down a serious Codex CLI security issue that wrote raw WebSocket payloads, prompts, code, paths, and environment variables to local trace logs—and explain how 0.142.5 redacts them, where to find old logs, and how to remove them safely.
The episode also covers a custom model bug that ignored model_reasoning_effort for namespaced slugs, plus the model_catalog_json workaround for restoring reasoning support.
Chapter 1
Redacting Trace Logs in Codex CLI 0.142.5
Ethan Park
So, I was looking through my local disk space yesterday, and it- it turns out that Codex CLI's massive SSD-wear bug from June 24th... it was actually a whole lot worse than just wearing down our hardware. And, uh, before we dive into how bad it got, we have to thank Jellypod for making this daily show possible.
Maya
Wait, worse than writing gigabytes of junk telemetry to our NVMe drives? What- what else was it doing?
Ethan Park
It was writing raw, unredacted WebSocket payloads straight to the local trace logs in plaintext. We are talking about your actual proprietary code, prompt data, absolute file paths, and environment variables. Just sitting there in a flat file.
Maya
Oh, wow. So if you're working on a proprietary codebase, all of that was just being dumped onto the local drive without any encryption or masking?
Ethan Park
Exactly. If anyone got access to your machine, or if you had log-forwarding tools sweeping up your home directory, your secrets were out there. But, the good news is that version 0.142.5 is officially out, and it backports PR #30771 to finally, thank goodness, redact these raw payloads.
Maya
Okay, so PR #30771 basically acts as a filter. But what about the logs that are already sitting on our machines from before the patch? Do we have to go hunt them down manually?
Ethan Park
Yep, you definitely want to clean those out. If you're on macOS or Linux, you'll find them under ~/.codex/logs. If you're on Windows, check your AppData\Local\Codex\logs directory. Just run a recursive delete on those folders to wipe the slate clean.
Maya
Right, but what about the Windows users who are running portable environments? I- I remember some of them got stuck in a bizarre update loop on version 0.142.4 where it kept trying to pull the update and failing.
Ethan Park
Oh, yeah. The portable Windows environments had a path-resolution issue. If you're stuck in that loop, you have to manually grab the 0.142.5 zip, unpack it over your existing binary, and override the local executable. Don't rely on the auto-updater for that specific transition.
Chapter 2
Restoring Custom Model Reasoning via model_catalog_json
Maya
Okay, that makes sense. Now, speaking of weird bugs, what's the deal with issue #30697? I've seen a few issues on GitHub about model_reasoning_effort being completely ignored when people use custom model slugs.
Ethan Park
Ah, this one is a classic Rust-level edge case. It's hidden inside codex-rs/models-manager/src/manager.rs. Basically, if you route your CLI through a custom, third-party, OpenAI-compatible gateway, you might use a multi-segment model slug. Something like, uh, provider/group/gpt-4o-mini or whatever.
Maya
Right, because of how they namespace their models. So why does the Rust code care about the slashes?
Ethan Park
Well, inside manager.rs, there's a function called find_model_by_namespaced_suffix. It tries to split the model string to find the base model name. But because of those extra slashes in the multi-segment slug, the suffix matcher gets confused, fails to find a match, and quietly falls back to a default metadata profile. And that default profile assumes the model has zero reasoning capabilities.
Maya
So it just strips out the model_reasoning_effort parameter entirely before sending the request over the wire? It doesn't even tell you it's doing it?
Ethan Park
Exactly! It silently drops the payload property because it thinks the model doesn't support it. But there is a clean workaround if you don't want to wait for another patch. You can use the model_catalog_json configuration option in your local config file.
Maya
Oh, interesting. How do we declare that? Do we just define the slug manually?
Ethan Park
Yeah, you explicitly define the model schema. You add your multi-segment slug as the key, and inside that object, you set supports_reasoning to true. When the CLI loads your local catalog JSON, it bypasses that broken find_model_by_namespaced_suffix logic entirely and respects your reasoning-effort configurations over the wire.
Maya
That is a lifesaver for custom endpoints. Alright, I'm going to go update my config and clean out those old log files. Good chatting with you!
Ethan Park
Same here. Talk to you later.