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.
Wait, worse than writing gigabytes of junk telemetry to our NVMe drives?
What- what else was it doing?
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.
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?
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.
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?
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.
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.
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.
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.
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.
Right, because of how they namespace their models.
So why does the Rust code care about the slashes?
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.
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?
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.
Oh, interesting.
How do we declare that?
Do we just define the slug manually?
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.
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!
Same here.
Talk to you later.