Did Codex Almost Cook My SSD? I Checked It Seriously

Hi everyone, this is Guo Shu.

Yesterday I saw a pretty alarming claim: Codex local logs might have a write bug that keeps pushing large amounts of data to the SSD, and in more serious cases could even affect drive lifespan.

My first reaction was not panic.

My first reaction was: is this another small technical scare that got amplified inside the developer circle?

Normally, a Mac SSD is not that fragile. When you use a computer every day, the system naturally has swap, cache, and all kinds of log writes. Especially once memory pressure rises, macOS using SSD as swap is not exactly breaking news. If you say write activity wears an SSD, that is technically true, but it is also easy to make it sound scarier than it is.

The problem is that my usage pattern is not normal.

This machine is basically on 24 hours a day. I keep many automation tasks running for long periods, and Codex is often not something I open briefly and close. It runs as a resident work layer on the machine. Once that premise changes, I cannot judge the issue by feel alone.

So I checked it seriously.

The scary part is not file size, but write speed

I first looked at Codex local data directories.

On my machine, Codex Desktop uses this by default:

/Users/zixuansmac/.codex

Inside it, there is one especially important file:

~/.codex/logs_2.sqlite

The file itself does not look absurd. It is around 1.8 GB. The WAL file next to it was also a few hundred MB during sampling. If you only look at file size, it is easy to conclude: this is fine, just a local SQLite log database.

But there is a trap here.

SQLite is not a thing where the final file size tells you how much was written. A file can be written, updated, overwritten, and flushed through WAL again and again. The final size on disk may not be large, but the amount written during the process can be very large.

It is like wiping a blackboard and writing on it all day. At the end, only a few lines remain, but during the day you may have written hundreds of pages.

What I really measured was how much the running Codex app-server process wrote.

The result was a little ridiculous.

In a sample window of about two minutes, the process wrote around 846 MB. That works out to about 7.0 MB/s. Logical writes were also around 4.9 MB/s. If this only happens occasionally, it is not a big deal. But if you keep it running 24 hours a day like I do, the annualized write volume is roughly 222 TB.

What does 222 TB mean?

It does not necessarily kill the SSD immediately. SSDs have spare capacity and wear leveling, and they do not simply die the moment a number is reached. But for a daily work machine, this is no longer a tiny log that can be ignored.

I also checked SMART data while I was there.

My internal 500 GB Apple SSD had about 54.8 TB of Data Units Written. Health was still fine, and Percentage Used was around 2%. So this is not a horror story where the drive is about to fail.

But it reminded me of something important: if you treat Codex as a resident automation workbench for long periods, this write behavior is worth handling.

Ordinary users should not panic; always-on users should care

This topic is very easy to write badly.

Once people hear Codex is writing to SSD, they tend to fall into two extremes.

One is panic: oh no, did I use Codex for a few days and ruin my SSD?

The other is dismissal: it is just logs; SSDs do not fail that easily.

My own judgment is that both are off.

If you only open Codex for a few hours a day, write some code, fix bugs, ask questions, then close it, I do not think you need to be anxious. You should care more about whether your projects are backed up and whether important files are under version control than about staring at SSD write counters.

But if your usage is like mine, with the computer on 24 hours a day and Codex frequently running automation, background jobs, and long workflows, the situation changes.

The key is not whether Codex writes logs.

All software writes logs.

The key is whether, under some scenario, it continuously writes one type of local log at high frequency without enough need. That difference is big. The former is normal software behavior. The latter can turn a small issue into long-term wear.

In plain words: this is not a good topic for mass panic, but it is a very good reminder for heavy users to check their machines.

Especially people like us who use a local computer as half a server.

The first low-risk treatment is not dark magic

Let me draw a boundary first.

If you want a low-risk fix, the first priority should not be changing the SQLite database directly.

The safer approach is to turn off analytics first.

Add this to the Codex config file:

[analytics] enabled = false

The config path is usually:

~/.codex/config.toml

Then fully restart Codex and sample writes again.

Why do I put this first?

Because the Codex app-server itself starts with analytics enabled by default, but based on command help and local verification, setting [analytics] enabled = false in config looks more like the official low-risk switch. It is much gentler than adding a trigger directly to SQLite.

If you are not sure what you are doing, I recommend starting here.

Do not begin by copying some random command from the internet and firing it into SQLite.

Many computer problems are not caused by the original issue. They are caused by the person fixing the issue getting too excited.

I later used a harder method, but it has a cost

Because the write volume on my machine really was high, and because I clearly knew I wanted to block writes to the logs table inside logs_2.sqlite, I later used a harder method: adding a SQLite trigger that directly ignores inserts into the logs table.

The command was roughly this:

sqlite3 ~/.codex/logs_2.sqlite “PRAGMA busy_timeout=10000; CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;”

What this command does is simple and blunt.

When Codex tries to insert a new log row into the logs table, the SQLite trigger makes that insert ignored.

After running it, I measured again.

The difference was obvious.

The max(id) of the logs table stopped increasing. The sizes of logs_2.sqlite, logs_2.sqlite-wal, and logs_2.sqlite-shm all changed by 0. Process writes dropped from about 846 MB per 120 seconds to about 29 MB per 120 seconds, a drop of roughly 96.5%.

Annualized, that went from the 200 TB range to roughly 7.7 TB to 10 TB.

That is much more normal.

This does not mean 7 TB is perfectly precise, and it does not mean every machine will behave the same way. It is only an estimate from my machine, my usage pattern, and this sampling window. But it does show that the high write volume was mainly related to this log table, and blocking it had a very clear effect.

However, this method has a cost.

The cost is that your local Codex logs will be incomplete.

If Codex crashes later, behaves strangely, or needs local troubleshooting, you may have less diagnostic material. Especially after Codex upgrades, migrations, or local database schema changes, this kind of trigger may also create small unpredictable problems.

So who is this method for?

It is for people who clearly know what they are doing, clearly understand the risk, and clearly know how to roll it back.

It is not for people who see the words protect SSD and immediately copy-paste.

Keep the rollback command nearby

I have a habit with these operations: whenever a command changes local database behavior, the rollback command must sit right next to it.

Otherwise, when a real problem appears, you will have forgotten what you changed.

The rollback command for this trigger is:

sqlite3 ~/.codex/logs_2.sqlite “DROP TRIGGER IF EXISTS block_log_inserts;”

If you want to check whether a trigger currently exists, run:

sqlite3 ~/.codex/logs_2.sqlite “SELECT name, sql FROM sqlite_master WHERE type=‘trigger’;”

There is another important point.

Deleting the Codex app itself does not necessarily remove this trigger. User data lives in:

~/.codex

If you uninstall /Applications/Codex.app, it usually will not delete the SQLite database in that directory.

So if you truly want to restore behavior, use DROP TRIGGER first. Do not assume reinstalling the app will solve it.

Of course, if you want to fully reset Codex local state, you can back up the entire ~/.codex directory and rebuild it. But that affects auth, config, skills, sessions, memory, plugins, and many other local states. That is a much larger action and should not be treated as an ordinary fix.

The real lesson is not just about SSDs

Honestly, the most interesting part of this problem is not whether Codex can wear out an SSD.

The more interesting part is that AI tools are moving from apps you open occasionally into local work systems that stay online for long periods.

In the past, much software was human-driven. You opened it, clicked a few things, and closed it. Even if it had background behavior, the scale was limited.

Now it is different.

Codex, Claude Code, agents, and automation scripts increasingly behave like resident workers on your computer. They read files, write files, open databases, remember logs, run jobs, generate caches, and store state.

Once you turn them into 24-hour workflows, many small costs that were previously invisible become amplified.

A few MB/s of writes is nothing over one minute.

Over one day, it becomes hundreds of GB.

Over one year, it becomes hundreds of TB.

That is the reverse side of automation.

Automation is not costless. Automation only turns human actions into continuous machine actions. The machine does not complain, but the disk, power, network, API, tokens, and database all keep accounting quietly.

So I increasingly feel that the real capability in the AI era is not just whether you can prompt, or whether you can install a new tool.

More importantly, you need to know what these tools are doing inside your machine.

What did they write?

What did they store?

Are they continuously consuming resources somewhere you cannot see?

If something goes wrong, can you roll it back?

This is the basic skill heavy AI tool users will slowly need to build.

My advice is simple

If you only use Codex casually for a few hours a day, do not be too anxious. Use it normally and do not get dragged around by technical scares.

If, like me, you treat Codex as half an automation workbench and keep the machine on 24 hours a day, I recommend doing at least three things.

First, check whether ~/.codex/logs_2.sqlite and the WAL file are unusually large.

Second, sample the actual write speed of the Codex app-server process. Do not only look at file size.

Third, try the low-risk analytics-off setting first. If writes are still excessive, then consider a hard stop such as a SQLite trigger, and make sure you keep the rollback command written down.

This is not mysterious, and it does not need superstition.

It is a very typical side effect of AI tools becoming local and persistent: tools become stronger, resident processes become more common, background state becomes more complex, and some previously minor logging and database behavior begins to affect your hardware and work environment.

I will say it again.

AI tools can amplify productivity, but they will not automatically absorb system costs for you.

If you let them work 24 hours a day, you need to occasionally open the lid and see how they are working.

Do not wait until the SSD actually starts warning you before remembering that there is a long-running work layer sitting on your computer.

With some caution, I can say I stepped into this pit first for everyone.

If you are also a heavy Codex user, especially the kind who runs automation on a Mac like it is a server, take a moment to check your write behavior.

There may be no problem.

But taking one look gives you a baseline.

That is enough.