Codex CLI Needs Resource Budgets, Not Just Token Budgets

Official Sources

A Codex bug report hit Hacker News this week because it had the kind of number that makes developers stop scrolling: a local SQLite feedback log path that could, by the reporter's estimate, write hundreds of terabytes per year under sustained use.

The issue is openai/codex#28224. The exact number is a community measurement, not an OpenAI postmortem. That distinction matters. But the broader pattern is harder to dismiss because related Codex issues describe excessive logs_2.sqlite-wal growth, heavy local I/O, idle process churn, and desktop startup failures when local log databases grow too large.

This is not really a SQLite story. It is a local-agent operations story.

We already talk about token budgets. We write about Claude Code token burn, agent FinOps, and AI coding review queues because model calls are visible enough to become product complaints. But agent CLIs also spend disk, CPU, file descriptors, terminal sessions, background processes, log volume, and human trust.

Last updated: June 22, 2026

The Take

Agent CLIs need resource budgets as first-class product features.

Not only:

• how many tokens did this run spend?
• how many credits are left?
• how many model calls did the agent make?

Also:

• how much disk did the agent write?
• how large are its local databases and WAL files?
• how many background processes are still alive?
• how much I/O is happening while the app is idle?
• when will logs rotate, compact, or checkpoint?
• what command cleans up safely?

The local runtime is part of the product. If the local runtime can fill a disk, stall a workstation, or quietly chew through SSD endurance, that needs the same engineering attention as a flaky model response.

What Actually Appears To Be Happening

The public reports point at Codex's local SQLite-backed state and diagnostic logging.

In issue #28224, the reporter describes high write amplification from Codex feedback logs. In issue #17320, another report says streaming responses caused sustained writes to ~/.codex/logs_2.sqlite-wal, with observed rates in the MiB-per-second range. In issue #28997, the report narrows the symptom to unbounded logs_2.sqlite-wal growth under default-style state behavior.

There are adjacent reports too: #27911 describes write amplification around goals_1.sqlite, #22444 says deleting a WAL file did not immediately free disk because older suspended Codex processes still held deleted file descriptors open, and #20563 frames idle I/O as SQLite WAL churn rather than plain log appending.

That does not prove one root cause. It does prove a shape:

local agent process
  -> high-frequency state or trace writes
  -> SQLite database
  -> WAL growth or checkpoint pressure
  -> disk usage, I/O stalls, startup failures, or manual cleanup

The bug might be a logging-level problem. It might be checkpoint behavior. It might be multiple processes holding files open. It might be trace volume that made sense during early debugging and stopped making sense once Codex became a daily driver. The public thread does not need to settle that for the lesson to be useful.

The Opposing Take Is Fair

The obvious pushback is: this is a bug, not a category lesson.

That is partly true. OpenAI can fix the specific Codex behavior. SQLite WAL is not inherently bad. Write-ahead logging is a normal durability design. Local apps have used SQLite successfully for years. A scary write-rate estimate in a GitHub issue should not turn into "SQLite is broken" or "Codex will destroy your SSD."

The better critique is narrower: local agent products need bounded failure modes.

If a diagnostic sink goes noisy, it should rotate. If a WAL grows, it should checkpoint or alert. If deleted files are held open by suspended processes, the app should surface that. If background agents are still running, the user should be able to see and stop them. If telemetry is high volume by design, the product should explain the retention policy and disk budget.

That is why this belongs next to the permissions, logs, and rollback loop. Logs are only helpful when they are designed as operational receipts. When logs become unbounded side effects, they stop being observability and become another production incident.

The Local Agent Runtime Has More Budgets Than Tokens

Token spend is easy to talk about because it maps to money. Disk and I/O budgets are easier to ignore because they feel like local machine details.

That separation breaks once agents run for hours.

A serious local coding agent now has:

The Codex changelog shows how quickly the product surface has expanded: browser use, hooks, automations, mobile review, Computer Use, and Sites. That is useful product velocity. It also means Codex is no longer just a command that exits. It is a local runtime with state.

Local runtimes need runtime controls.

What I Would Add To Every Agent CLI

The minimum viable fix is not a beautiful dashboard. It is a boring doctor command that tells the truth.

agent doctor resources

It should report:

state directory: ~/.codex
database files: 842 MB
wal files: 1.7 GB
largest hot file: logs_2.sqlite-wal
current write rate: 0.0 MB/s idle, 3.2 MB/s active
active agent processes: 2
deleted files still held open: 0
log retention: 7 days or 2 GB
last checkpoint: 2026-06-22 14:12
safe cleanup: agent doctor resources --compact

Then add hard limits:

[resources]
max_log_bytes = "2gb"
max_wal_bytes = "512mb"
max_idle_write_rate = "1mb/min"
max_background_processes = 4
warn_at_disk_free = "10gb"

And wire those limits into the agent loop:

• warn before a run starts if local state is already unhealthy
• stop optional telemetry before it can fill the disk
• rotate logs by default
• checkpoint SQLite WAL files intentionally
• expose a safe compaction command
• include local resource stats in bug reports
• show a run-level receipt when an agent exits

This is the same argument behind long-running agent harnesses. A harness is not just "keep trying until green." A harness owns the budget envelope around the work.

What Developers Should Do Today

Until agent CLIs expose better resource controls, treat local agent state like build artifacts: useful, inspectable, and disposable only when you understand what you are deleting.

Practical steps:

1. Know where your agent stores state. For Codex, current reports point at ~/.codex, but verify on your machine and platform.
2. Check disk usage before and after long runs.
3. Fully quit the app before deleting SQLite or WAL files, especially if disk does not free immediately.
4. Use Activity Monitor, lsof, or platform equivalents when disk appears full after deleting logs.
5. Keep Codex updated and read the changelog before assuming an old workaround is still valid.
6. Avoid leaving many suspended local agent sessions open indefinitely.
7. File bug reports with version, platform, active processes, file sizes, write rate, and reproduction steps.

The goal is not to babysit every CLI. The goal is to make abnormal resource use visible enough that you can stop it before it becomes a machine problem.

The Bigger Product Lesson

The agent tools that win will not only generate better code. They will make their side effects legible.

That includes:

• model calls
• file edits
• shell commands
• browser sessions
• local state
• logs
• background processes
• CI jobs
• review load

This is why terminal agents need a portable runtime surface. Once a terminal agent becomes a persistent work environment, it needs the boring controls that mature runtimes have: health checks, limits, rotation, compaction, and receipts.

Codex is moving fast. That is good. The point of writing about this bug is not to dunk on the product. It is to name the next layer of maturity for every coding agent, Codex included.

Token budgets were the first obvious meter. Resource budgets are next.

FAQ

Is the Codex SQLite WAL issue confirmed by OpenAI?

The public GitHub issues are open user reports, not an OpenAI postmortem. The reports are still useful because several independent issues describe related local SQLite, WAL, disk-growth, and I/O symptoms.

Does this mean SQLite is a bad choice for agent logs?

No. SQLite is a reasonable local-state store. The issue is not SQLite itself; it is unbounded write volume, WAL growth, checkpoint behavior, process lifecycle, and missing user-facing resource controls.

Should I delete ~/.codex/logs_2.sqlite-wal?

Do not blindly delete live SQLite or WAL files while Codex processes are running. Fully quit Codex first, verify no related processes are holding file descriptors, and prefer an official cleanup or compaction command when available.

What should agent CLIs expose for disk usage?

At minimum: state directory, database size, WAL size, current write rate, active process count, log retention policy, last checkpoint time, and a safe cleanup command.

Why does this matter if token cost is the main agent budget?

Token cost is only one budget. Long-running local agents also consume disk, CPU, I/O, battery, network calls, CI capacity, and human review time. Serious agent workflows need visibility across all of them.

Sources

• GitHub: Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance
• Hacker News: Discussion of the Codex SQLite feedback log issue
• GitHub: Excessive SQLite WAL writes during streaming due to TRACE logs
• GitHub: goals_1.sqlite write amplification on long-running sessions
• GitHub: logs_2.sqlite-wal grows without bound into tens of GB
• GitHub: logs_2.sqlite-wal grows indefinitely and remains allocated after deletion
• GitHub: Heavy I/O activity from idle Codex processes
• OpenAI Developers: Codex app troubleshooting
• OpenAI Developers: Codex changelog