So, Ethan, I was sitting at my desk yesterday, and my MacBook fan starts screaming.
Like, really screaming, which is weird because I'm just idling in a terminal window.
So I pull up the activity monitor, then run a quick lsof, and...
oh my god, the write counters are spiking.
Gigabytes of data just flying onto my SSD.
And it turns out, it's Codex.
The silent killer of solid state drives.
Yeah, you are definitely not the only one seeing this.
There is this massive SQLite log write loop in the macOS Desktop build
26.721.41059 and the bundled codex-cli
0.146.0-alpha.3.1.
It is literally hammering drives.
But why?
I mean, I'm not even running a heavy agent loop.
I was just...
coding.
What is it writing?
It's logging.
Everything.
Specifically, the developers left a hardcoded LevelFilter TRACE fallback in the
SQLite log sink.
So even if you set your environment to something like RUST_LOG equals warn to quiet
things down, the app-server completely ignores it.
It's capturing every single Server-Sent Event and local connection handshake.
We are talking between 35 and 42 database inserts every single second.
Forty-two inserts a second?
On a local dev machine?
That is...
I mean, that explains why my write counters were going crazy.
How much data are we actually talking about here?
It dumps up to 44 megabytes of transient debug records into a file called
logs_2.sqlite every 30 seconds.
If you do the math on that, a heavy user could end up silently writing terabytes of
useless diagnostic junk to their drive over a single year.
My poor SSD.
I actually went digging into that logs_2.sqlite file.
The WAL file...
the write-ahead log...
was sitting at 760 megabytes.
But when I actually queried the database, it was like...
mostly empty space, right?
Oh, totally.
Because the app has this aggressive loop where it inserts a row,
then immediately prunes it.
It's just churning through memory and disk space, doing a dance of writing and
erasing, leaving nothing but fragmented empty space in the actual database file.
It was eighty-six percent empty space when we analyzed it.
Unbelievable.
Okay, so before our listeners go and uninstall the whole thing,
there is a brilliant workaround that the community figured out.
And it's a database-level fix, which I love.
You don't have to wait for an official patch.
Wait, a trigger?
You're using an SQL trigger to block the app from talking to its own database?
Exactly!
You just open up your terminal, run sqlite3 on
~/.codex/logs_2.sqlite, and then you run this exact command: CREATE
TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN
SELECT RAISE(IGNORE); END; Oh, that is dirty.
I love it.
It just intercepts the insert statement before it ever hits the actual disk,
and silently throws it away.
Yep.
It intercepts it at the engine level.
No disk write, no SSD wear and tear.
The parent Rust process has absolutely no idea it's happening.
It doesn't crash, it doesn't throw errors.
It just thinks the write succeeded and goes on its merry way.
But wait, there's got to be a catch.
If the database is completely empty, what happens when you actually need to debug
something?
Or, say, use the slash feedback command?
Ah.
Yeah.
That's the major tradeoff.
If you run that trigger, your diagnostic tables are bone dry.
So if you try to submit feedback or export your local troubleshooting logs to the
developers, they are going to get a completely blank report.
But honestly?
For me, saving my hardware is worth losing the feedback feature for a bit.
Yeah, I'd make that trade too.
But speaking of bugs and rapid updates, OpenAI has been pushing out new alpha builds
on the v0.146.0 track like crazy.
We just got 0.146.0-alpha.5 on July 23,
2026, and its main job is to revert a feature they literally just introduced in
v0.145.0.
Wait, they are reverting a feature already?
Which one?
The experimental paginated chat history.
It was designed to keep the terminal UI nice and snappy when you have massive
threads.
But it ended up causing catastrophic agent boot loops and startup freezes.
Oh, interesting.
Why would pagination break the startup sequence?
Isn't it just...
loading less data at once?
You'd think so, but here's the architectural catch.
While paginating the chat is great for a human looking at a screen,
the background agent loop and your local Model Context Protocol...
the MCP servers...
they need to reconstruct the entire state tree when they boot up.
They need to see everything that happened before.
Oh!
Of course!
If you restrict the database query to just one page of history,
the boot sequence can't see the previous agent turns, or the child spawns,
or even the active handshake boundaries.
It's essentially blind.
Exactly.
And because it's blind, the CLI just hangs indefinitely on launch,
spitting out "MCP client failed to start" errors.
It was completely locking people out of their terminal sessions.
Wow.
Okay, so if someone is currently stuck on v0.145.0 or
0.145.2, and their terminal is just frozen, what are the recovery paths?
Well, you have two options.
You can either play it safe and downgrade to the stable v0.144.x line,
or you can leap forward to the alpha branch, specifically
0.146.0-alpha.5 or higher, where they cleanly ripped the
pagination code out.
Hmm.
Going to a bleeding-edge alpha branch to fix a boot loop sounds like jumping from
the frying pan into the fire.
Are there other bugs lurking in those alphas?
Oh, absolutely.
It is a bit of a minefield.
For example, in 0.146.0-alpha.3.1, if you use the
official Meta Ads MCP endpoint at mcp.facebook.com/ads,
the streamable HTTP handshake fails completely.
It returns Sse(None) on the initialized notification before any tools are even
exposed.
So you are totally locked out of your ad-campaign tools.
So, if you're managing Facebook ads via your CLI, maybe stick to the stable
downgrade for now.
Good to know.
Well, that's the bleeding edge for you!
Talk to you next time, Ethan.
Catch you later, Maya.