When you use a coding agent every day, the usage meter is not the only thing worth watching. CLI version, codex doctor output, rollout history, and the size of the local SQLite log database all deserve an occasional look.
Codex stops being a tool you invoke and becomes a working environment with local state. Working environments get inspected.
Originally published in Japanese on June 24, 2026. This English version was written in September 2026.
This is what I found auditing mine on June 24, 2026 — not a summary of announcements, but what actually turned up. One finding has since been resolved upstream, and I have flagged it inline.
Note on versions: the version numbers below are the ones I was on in June 2026. Codex CLI has moved on considerably since — releases were in the 0.153.x range as of early September 2026 — so treat 0.142.0 as a timestamp on this record, not as a version to install. The commands and the order of operations are what carry over.
Upgrade first, then look
codex --version
npm install -g @openai/codex@0.142.0
codex --versionFrom codex-cli 0.133.0 to codex-cli 0.142.0. The changelog for 0.142.0 covered /usage and /plugins, rollout token budgets, multi-agent delegation, and a reduction in persistent-log churn.
A changelog entry does not guarantee the feature looks the same in your environment. App, CLI, plugins, feature flags, and account state all change what surfaces. Read the official information, then confirm locally.
Use doctor to separate “broken” from “different”
codex doctor is documented as a diagnostic report for local installation, config, auth, runtime, Git, terminal, app-server, and thread inventory issues. On June 24, 2026 mine returned:
17 ok · 1 idle · 2 notes · 0 warn · 0 fail
It did not pass cleanly the first time. The terminal check failed under TERM=dumb — which looks less like a Codex fault and more like an environment variable problem. So I tested that hypothesis directly:
codex doctor --summary
env TERM=xterm-256color codex doctor --summaryWith TERM=xterm-256color, doctor passed. No reinstall, no configuration surgery. That is what doctor is good for: telling you whether the problem is Codex or the environment you launched it from.
Rollout history is not cache
Active sessions were in the 9 GB range across roughly 230 files. Large — but deleting on size alone is the wrong instinct.
Rollouts and sessions relate to resume, fork, thread inventory, and past working context. So I split them:
| Target | Default decision |
|---|---|
| Active sessions | Keep |
| Archived sessions | Deletion candidate if unneeded |
| Clearly corrupted old files | Quarantine, then re-run doctor |
| SQLite log database | Watch size only; do not read contents |
In practice I quarantined only old scan-error rollouts, kept active sessions, and treated archived ones as candidates. The longer you use an agent, the more history accumulates — but “large” is not the same as “disposable.”
The SQLite log issue: check size, do not amplify
An upstream issue reported very heavy write volume from Codex’s SQLite feedback logs — around 37 TB written over 21 days on one machine, extrapolating to roughly 640 TB/year, enough to consume a consumer SSD’s rated endurance in under a year.
That is one environment’s report, and treating it as a general figure would be irresponsible. My own sizes on June 24, 2026:
logs_2.sqlite— about 980 MBlogs_2.sqlite-wal— about 84 MBlogs_2.sqlite-shm— about 64 KB
No extreme WAL growth. The main database near 1 GB. So my rule became: watch the size, do not read the contents.
ls -lh ~/.codex/logs_2.sqlite*SQLite contents can include material close to conversations and diagnostic logs. There is no reason to open the database for an article. Size is enough, and a sudden WAL jump or rapid database growth is the trigger to investigate further.
The issue thread carried a workaround that blocks log inserts with a trigger. I chose not to go that far, judging the 0.142.0 upgrade plus size monitoring sufficient.
Update for this English version: that issue is now closed as completed (July 12, 2026). Three merged pull requests — two released in 0.142.0 and one in 0.143.0 — cut the log volume by roughly 85% according to the reporter. He closed it himself in June; OpenAI reopened it the next day and finally closed it as fixed on July 12. If you are reading this on a current CLI, the workaround is unnecessary, and my “upgrade and watch the size” judgment turned out to be the right call by accident as much as design.
A five-line health check
Doing this by hand every time is tedious, so I wrote a small script.
#!/usr/bin/env bash
set -euo pipefail
echo "# Codex Health Check"
date
echo
echo "## CLI"
codex --version
echo
echo "## Doctor"
codex doctor --summary || true
echo
echo "## Local Sizes"
du -sh ~/.codex/sessions 2>/dev/null || true
du -sh ~/.codex/archived_sessions 2>/dev/null || true
ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null || trueThe point is not widening the scope. No .env, tokens, cookies, credential files, or SQLite contents. Version, doctor result, sizes. That is the right resolution for a routine check.
./codex_health_check.sh > codex-health-check-$(date +%F).mdRun weekly, that turns “it feels slow lately” into “the database grew since last time,” “rollouts increased,” “a doctor note changed.”
I later packaged this into a reusable CLI, codex-healthkit, with the same metadata-only boundary: it does not read credentials or session transcript contents. It has reached v0.4.1 as of August 2026.
Why I skipped local models for now
The CLI reference documents an --oss flag for using a local open source model provider — it uses --local-provider, your configured oss_provider, or prompts you to choose between LM Studio and Ollama.
I did not enable it here. Stabilising the app and CLI came first: usage, threads, plugins, doctor, rollouts, the log database. Local models are worth adding when there is a clear reason — confidentiality, offline work, cost control on light tasks — not as a general-purpose upgrade.
(I did eventually add one, on a separate machine and for a narrow class of repetitive work. That is a different article.)
Look before you delete
If you use a coding agent as an occasional chat, none of this matters. Open it daily, run multiple threads, and hand it WordPress work, development, and post-publication checks, and it becomes a working environment with local state.
codex --version
codex doctor --summary
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null || true
ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null || trueDo not start with deletions or workarounds. Look at the state first. That order is what kept an environment-variable problem from turning into a reinstall, and a scary upstream number from turning into a trigger I did not need.
References
- Command line options | Codex CLI reference —
codex doctorand--oss - Codex developer commands
- Codex changelog (ChatGPT Learn)
- openai/codex 0.142.0 release (June 22, 2026), and the current release list
- openai/codex issue #28224: SQLite feedback log write volume (closed July 2026)
- codex-healthkit: a local health check CLI