Codex Desktop 26.623 still writes high-volume TRACE records to ~/.codex/logs_2.sqlite on Windows

Summary

Codex on Windows is still producing high-volume persistent TRACE logging into ~/.codex/logs_2.sqlite. This continues after upgrading the CLI to 0.142.0 and after Codex Desktop updated to 26.623.13972.0.

A local SQLite trigger guard previously stopped the writes, but after the Desktop update the guard was no longer present and the database resumed growing.

Environment

• OS: Windows
• Codex CLI: codex-cli 0.142.0
• Codex Desktop app in PATH: OpenAI.Codex_26.623.13972.0
• Database: ~/.codex/logs_2.sqlite
• Journal mode: WAL

Related changelog context

The 0.142.0 changelog mentions reduced persistent-log churn by removing per-event WebSocket payload logging and filtering duplicated/noisy telemetry records. However, this Windows installation still reproduces high-volume TRACE writes.

Observed before Desktop update / previous verification

With CLI 0.142.0, temporarily removing a local guard trigger and sampling for 60 seconds produced:

• logs.MAX(id) delta: 5134
• TRACE rows: 3621
• DEBUG: 40
• INFO: 9
• WARN: 1
• WAL grew from 0 to 23,253,312 bytes

Sample excerpt:

t+5s  delta_id 161   levels [('TRACE', 158), ('DEBUG', 3)]
t+10s delta_id 511   levels [('TRACE', 507), ('DEBUG', 4)]
t+15s delta_id 659   levels [('TRACE', 659)]
t+20s delta_id 584   levels [('TRACE', 584)]
t+25s delta_id 412   levels [('TRACE', 412)]
t+30s delta_id 534   levels [('TRACE', 526), ('DEBUG', 5), ('INFO', 2), ('WARN', 1)]
t+60s delta_id 127   levels [('TRACE', 126), ('DEBUG', 1)]

Because this was still high-volume logging, the local trigger guard was restored and WAL was checkpointed/truncated.

Observed after Desktop update to 26.623

After the Desktop app updated to OpenAI.Codex_26.623.13972.0, the guard trigger was no longer present and logging resumed.

A 10-second read-only sample showed:

• trigger present: False
• MAX(id) increased from 53211466 to 53211778
• delta: 312 rows in 10 seconds
• WAL size at sample: 4,420,792 bytes

Recent last-1000-row level distribution before restoring the guard:

[('TRACE', 981), ('DEBUG', 15), ('INFO', 3), ('WARN', 1)]

Current local mitigation

A local SQLite trigger is being used again as a stopgap:

CREATE TRIGGER IF NOT EXISTS codex_block_logs_insert_20260623
BEFORE INSERT ON logs
BEGIN
  SELECT RAISE(IGNORE);
END;

After restoring the guard and checkpointing WAL:

• WAL: 4,420,792 -> 0
• 10-second follow-up sample: MAX(id) delta 0, WAL delta 0

Expected result

Codex should not write hundreds or thousands of mostly TRACE rows per minute into ~/.codex/logs_2.sqlite during normal/idle Desktop usage, and app updates should not require a user-maintained SQLite trigger to prevent database/WAL growth.

Notes

This may be coming from the Desktop app process or bundled app resource rather than only the npm-installed CLI, since the npm CLI is already 0.142.0 and the Desktop app path is also present in where codex.