Codex still writes TRACE-level records into ~/.codex/logs_2.sqlite in desktop app 26.623.31921

Summary

Codex desktop still writes TRACE-level records into the local SQLite log database (~/.codex/logs_2.sqlite).

I verified this on June 26, 2026 with:

• Codex desktop version: 26.623.31921
• Build: 4452
• macOS: Apple Silicon macOS

This appears related to the earlier logging change introduced in #12969.

Why this is still a problem

I understand newer builds now seem to include retention / checkpoint logic, so this may no longer be an unbounded-growth bug in the exact same form.

However, the core issue still exists:

• TRACE logs are still being persisted into ~/.codex/logs_2.sqlite
• even very small CLI actions generate a large number of TRACE rows
• this still creates unnecessary local disk writes

Minimal reproduction

Preconditions

If you previously added any local mitigation like a SQLite trigger that suppresses TRACE rows, remove it first.

For example, I had a local trigger named:

ignore_trace_logs

Repro steps

1. Quit Codex desktop completely.
2. Ensure ~/.codex/logs_2.sqlite is available.
3. Run a very small Codex CLI command:

/Applications/Codex.app/Contents/Resources/codex features list

1. Inspect the SQLite database:

sqlite3 ~/.codex/logs_2.sqlite \
' select level, count(*), sum(estimated_bytes) from logs group by level order by level;'

1. Or inspect only recent TRACE rows:

sqlite3 ~/.codex/logs_2.sqlite \
' select ts, level, target, thread_id, process_uuid, estimated_bytes from logs where level = "TRACE" order by id desc limit 20;'

Actual result

Running only:

codex features list

produced 1095 new TRACE rows in my local logs_2.sqlite.

Observed aggregate for those new rows:

• level: TRACE
• row count: 1095
• summed estimated_bytes: 1719179

Example observed targets included:

• log
• codex_api::sse::responses

Expected result

For normal desktop / CLI usage, Codex should not persist TRACE-level records into the local SQLite log DB by default.

At minimum, default persisted local log level should be reduced to something like INFO, WARN, or ERROR, or TRACE should be gated behind an explicit debug flag.

Additional notes

The current binary does appear to contain log-maintenance logic, including strings consistent with:

• DELETE FROM logs WHERE ts < ?
• PRAGMA wal_checkpoint(PASSIVE)

So this may already be partially mitigated from the original worst-case SSD-growth behavior.

But the persistence of TRACE rows itself is still reproducible in current builds.

Related

• Original change likely connected to: #12969