Codex logging bug may write TBs to local SSDs

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert

Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance

Issue

Codex is continuously writing a large amount of data to the local SQLite feedback log database:

~/.codex/logs_2.sqlite

~/.codex/logs_2.sqlite-wal

~/.codex/logs_2.sqlite-shm

On my machine, after about 21 days of uptime, the main SSD has written about 37 TB. Process/file-level checks show Codex SQLite logs are the main continuous writer.

That extrapolates to roughly 640 TB/year. On a 1 TB SSD, that is about 640 full-drive writes per year. Some consumer SSDs are rated around 600 TBW, so this could consume roughly a full drive's warranted write endurance in less than a year.

Evidence

Current retained rows in logs_2.sqlite:

metric

value

retained rows

681,774

estimated retained log content

1,035.6 MiB

Level distribution:

level

estimated MiB

byte %

TRACE

732.5

70.7%

INFO

266.5

25.7%

DEBUG

30.6

3.0%

WARN

5.9

0.6%

Largest target+level pairs:

target

level

estimated MiB

codex_api::endpoint::responses_websocket

TRACE

527.4

codex_otel.log_only

INFO

141.2

codex_otel.trace_safe

INFO

121.2

log

TRACE

97.4

codex_client::transport

TRACE

60.1

codex_core::stream_events_utils

DEBUG

27.5

codex_api::sse::responses

TRACE

19.1

The top sources are mostly global TRACE logs, mirrored telemetry logs, and raw websocket/SSE payload logging. TRACE alone is about 70.7% of retained bytes. codex_otel.log_only + codex_otel.trace_safe add another 25.3%. Filtering these categories should remove roughly 96% of retained log bytes in this sample without fully disabling feedback logs.

Sanitized examples from the most frequent TRACE source: target=log

These are high-frequency retained samples. Raw websocket/SSE payload bodies are intentionally not included because they may contain private conversation content.

The dominant INFO sources are mostly repeated OpenTelemetry mirror events. IDs are redacted.

843x INFO codex_client::custom_ca: using system root certificates because no CA override environment variable was selected ... 334x INFO codex_otel.trace_safe: session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<redacted> codex.op="user_input"}:turn{otel.name="session"}