Bug Information
Good news: OpenAI has fixed this issue in Codex version 0.142.0. You can now use it without concern.
Recently, with its powerful features and smooth user experience, Codex's weekly active users have surpassed the 5 million milestone. More and more developers and tech enthusiasts have adopted it as a go-to assistant for high-frequency daily use.
However, as the user base grows, some users have reported that under certain streaming output or automated task scenarios, Codex continuously writes TRACE-level logs to the local disk.
An ISSUE on GitHub claims that this bug can generate 640GB/year of write operations, which is lethal for consumer-grade SSDs. For mainstream 1TB or 2TB consumer-grade SSDs (with rated lifespans typically around 600TBW to 1200TBW), this is indeed quite severe.
Furthermore, because the AI boom is at an unprecedented peak, the global demand for high-bandwidth, high-performance storage has erupted. This has driven up SSD prices, making storage costs quite expensive—especially on Mac devices where drives cannot be replaced. During this period when every gigabyte counts, we must be extra meticulous about every bit of wear and every gigabyte of space on our hard drives.
1-Minute Self-Check: Are You Affected?
If you are on Linux or macOS, you can run a couple of terminal commands to check your status.
First, check the log file size:
1 | ls -lh ~/.codex/logs_2.sqlite |
Then, analyze the distribution of log levels:
1 | sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC" |
How to judge:
If TRACE-level logs dominate the query results and the logs_2.sqlite file is quite large, it means Codex is indeed aggressively logging trivial tracking information in the background.
Reference Data:
My file size was 468MB:
1 | > ls -lh ~/.codex/logs_2.sqlite Jun 23 |
1 | > sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC" |
As we can see, TRACE|39961 account for nearly half of the logs, confirming the existence of the reported issue, mainly because OpenAI has not officially released a fix response at the time of writing.
A Permanent Solution: Intercept Directly in the Database
OpenAI has already fixed this issue, so no action is required anymore.
Here is a rather aggressive but most direct workaround: add an SQLite trigger to the log table to ignore new log writes. After all, this file only contains diagnostic logs and no conversation history.
It is recommended to exit Codex and backup the log database before executing:
1 | cp ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak |
Then execute:
1 | sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" |
Once set up, new log entries will be intercepted, thereby reducing subsequent write operations.
Note that this method will affect Codex's ability to generate diagnostic logs. If you need to report issues to the official support later or are concerned about compatibility with future versions, you should avoid this workaround and opt for periodic cleanups instead.
How to Restore
If you want to restore logging, simply drop the trigger. Exit Codex first, then run:
1 | sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;" |
After executing, check if it still exists:
1 | sqlite3 ~/.codex/logs_2.sqlite ".schema block_log_inserts" |
If there is no output, the trigger has been successfully deleted.
You can also run this command to inspect all current triggers:
1 | sqlite3 ~/.codex/logs_2.sqlite "SELECT name, tbl_name, sql FROM sqlite_master WHERE type='trigger';" |
Summary
The numbers in the GitHub issue are somewhat exaggerated; Codex's logging issue is not as scary as rumored on the web. Nonetheless, we are grateful that OpenAI has fixed the bug. Happy coding with Codex!
Comments