Repository navigation
Codex Desktop rapidly grows logs_2.sqlite / WAL during normal active use #24275
Description
Summary
Codex Desktop rapidly grew ~/.codex/logs_2.sqlite and ~/.codex/logs_2.sqlite-wal during a normal active session. The growth was visible over only a few minutes and coincided with noticeable UI slowdown.
This looks related to #21134, #20213, and #19109, but I am filing this with fresh data from codex-cli 0.133.0-alpha.1.
Environment
- Codex Desktop on macOS
codex-cli 0.133.0-alpha.1- macOS
15.7.4/ build24G517 - Default
$CODEX_HOME:~/.codex
Observed behavior
During an active Codex Desktop conversation, Finder showed:
- around
00:10:logs_2.sqlite-walwas already about63.4 MB - around
00:12:logs_2.sqlite-walwas about146.6 MB, andlogs_2.sqlitewas about131.2 MB
A later check while Codex was still running showed:
logs_2.sqlite 125M
logs_2.sqlite-shm 288K
logs_2.sqlite-wal 140M
SQLite-level data at the same time looked much smaller than the on-disk files:
rows: 2086
sum(estimated_bytes): 2404625
min ts: 2026-05-23 22:01:45
max ts: 2026-05-23 22:16:44
Top log targets by estimated bytes:
codex_api::endpoint::responses_websocket | 283 | 1196752
codex_otel.log_only | 290 | 408871
codex_otel.trace_safe | 287 | 376671
codex_api::sse::responses | 49 | 134714
log | 710 | 79236
codex_core::stream_events_utils | 33 | 51749
hyper_util::client::legacy::pool | 131 | 32141
codex_core_skills::loader | 48 | 32016
lsof showed several Codex processes holding the same logs_2.sqlite files open, including the Desktop app-server and several stdio app-server processes spawned under node_repl:
codex app-server --analytics-default-enabled
codex app-server --listen stdio://
codex app-server --listen stdio://
codex app-server --listen stdio://
RUST_LOG for the processes was already warn, so this does not appear to be caused by a locally enabled verbose logging env var.
Expected behavior
The local diagnostic log DB should not grow by hundreds of MB within a few minutes of normal use, especially when the logical estimated_bytes stored in logs is only a few MB.
The log sink should also not materially degrade Codex Desktop responsiveness.
Impact
The app became slower while the log DB/WAL grew quickly. Users may need to fully quit Codex and manually clear or rotate logs_2.sqlite* to recover disk space and responsiveness.
Suggested direction
The data points to the same general area as the linked issues:
- bound or disable high-volume websocket/SSE/OTel trace logging by default
- ensure WAL checkpoint/truncation works under normal Desktop multi-process usage
- avoid shared-log SQLite contention across multiple app-server processes
- make local log retention/rotation configurable or automatic
Activity
github-actions commentedon May 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
interfector18 commentedon May 29, 2026
I think this is part of the bug that caused about 30 TB of ssd write churn on my system, codex itself wrote 7 GB in 10 minutes from a quick iotop test, while the files themselves didn't get bigger than ~200MB
fix(cli): 沙箱 codex 日志写放大止血（改用 tmpfs） (#511)
martinmclee commentedon Jun 23, 2026
Testing with empty proxy.
martinmclee commentedon Jun 23, 2026
I can confirm this affects my setup too.
Environment: Windows 11,
%USERPROFILE%=C:\Users\User, codex CLI 0.142.0.I captured state from
C:\Users\User\.codextoday:logs_2.sqlite: 6,542.19 MBlogs_2.sqlite-wal: 101.82 MBlogsrows: 93,757 with high verbose logging volume (TRACEandDEBUGpresent; many internal targets).session/archived_sessionactivity is ongoing (several GB under.codex/sessionsand.codex/archived_sessions).CrystalDiskInfo snapshot (
CrystalDiskInfo_20260623102934.txt) shows:So this looks like the same app-level logging/WAL churn bug pattern (not clear SSD failure).
I also confirmed this workaround from issue discussions is available in my setup:
CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;(does not delete any sessions/log history, just blocks new log inserts).
Please confirm if any additional local traces would help.
RoyalBis commentedon Jun 26, 2026
I can confirm as well:
Platform:
Ubuntu Linux
Problem:
~/.codex/logs_2.sqlite-wal grew to 108G and filled the root filesystem.
Evidence:
df -h showed / at 100%:
/dev/mapper/ubuntu--vg-ubuntu--lv 155G 149G 0 100% /
/workspace is a separate filesystem and was not full:
/dev/sdb 157G 32G 117G 22% /workspace
du showed /home was the source:
136G /home
108G /home/ubuntu/.codex
Top-level ~/.codex files:
108G logs_2.sqlite-wal
214M logs_2.sqlite-shm
169M logs_2.sqlite
Impact:
Root filesystem filled completely, causing ENOSPC risk for unrelated system services.
Expected:
Codex log storage should be bounded, rotated, checkpointed, or configurable so it cannot consume the entire root filesystem.
Actual:
A SQLite WAL file under ~/.codex grew to 108G.
codex-cli 0.142.2
runminglu commentedon Jul 16, 2026
Additional sanitized data from macOS 26.4 (25E246), arm64:
codex-cli 0.144.526.707.91948(build 5440)~/.codex/logs_2.sqlite: 684,650,496 bytes (about 653 MiB)~/.codex/logs_2.sqlite-wal: 6,254,192 byteslog_diroroteloverride in~/.codex/config.tomlSQLite contents:
TRACE + DEBUG are about 80.7% of all rows and 77.2% of logical log bytes.
Largest targets by estimated bytes:
This is not currently a giant WAL case—the WAL has checkpointed down to about 6 MiB—but the main diagnostic database remains 653 MiB after roughly eight days, with most retained data at TRACE/DEBUG. This indicates that the high-volume persistent logging/retention behavior is still present in the 0.144.5 generation.