SQLite Log Storms and the Alpha 5 Rollback

Maya

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.

Ethan Park

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.

Maya

But why? I mean, I'm not even running a heavy agent loop. I was just... coding. What is it writing?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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.

Ethan Park

Wait, a trigger? You're using an SQL trigger to block the app from talking to its own database?

Maya

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;

Ethan Park

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.

Maya

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.

Ethan Park

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?

Maya

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.

Ethan Park

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.

Maya

Wait, they are reverting a feature already? Which one?

Ethan Park

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.

Maya

Oh, interesting. Why would pagination break the startup sequence? Isn't it just... loading less data at once?

Ethan Park

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.

Maya

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.

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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.

Ethan Park

Catch you later, Maya.