›_ Codex Issues
Codex Issues / #30405

Windows Codex 26.623.5546.0 still persists high-frequency TRACE logs to logs_2.sqlite WAL

Open 💬 6 comments Opened Jun 28, 2026 by fffire-oss
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, Codex Desktop 26.623.5546.0 still persists high-frequency TRACE logs into the local SQLite feedback log database (logs_2.sqlite) and its WAL during normal active use.

This appears related to existing reports such as #17320, #28224, #29532, #29832, and #30236, but I am filing this with fresh Windows data from 26.623.5546.0.

Environment

  • OS: Microsoft Windows NT 10.0.26200.0, x64
  • Codex app package: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0
  • App-server command: codex.exe app-server --analytics-default-enabled
  • Observed command runner: codex-command-runner-0.142.3.exe
  • Files observed:
  • C:\Users\<user>\.codex\logs_2.sqlite
  • C:\Users\<user>\.codex\logs_2.sqlite-wal
  • C:\Users\<user>\.codex\state_5.sqlite-wal
  • Current shell environment had RUST_LOG=warn; no user/machine RUST_LOG override was found.

Observed behavior

A 30-second local sample during normal Codex use showed continuous insert/prune churn in logs_2.sqlite:

logs.max(id):   21,156,392 -> 21,181,109
Delta ids:      +24,717 in 30 seconds
Approx rate:    ~824 inserted log ids/sec
Retained rows:  44,757 -> 44,852
Delta rows:     +95

Recent persisted rows after the sample were entirely TRACE-level:

Recent 1000 rows by level:
TRACE 1000

Recent 1000 rows by target:
TRACE log                                  949
TRACE codex_app_server::outgoing_message   51

File sizes and mtimes at the same point:

logs_2.sqlite       147,492,864 bytes
logs_2.sqlite-wal    25,206,192 bytes
state_5.sqlite-wal    4,243,632 bytes

A separate 30-second mtime sample showed logs_2.sqlite-wal, logs_2.sqlite, and state_5.sqlite-wal modification times advancing repeatedly while the .sandbox text log did not continue growing. This suggests the ongoing write pressure is mostly SQLite/WAL churn rather than simple text-log append growth.

Representative TRACE bodies were not included because they may contain private local/session data. Sanitized inspection showed low-level websocket/tokio/tungstenite style entries such as poll_read, poll_next, WouldBlock, frame metadata, and large frame payload logging.

Disk write / SSD endurance concern

A Windows Performance Counter sample over the same 30-second window reported the codex process at approximately:

Average process IO Write Bytes/sec: ~1,346,401 B/s (~1.35 MB/s)
Max process IO Write Bytes/sec:     ~15,324,126 B/s (~15.3 MB/s)

I understand Windows process IO counters are not identical to physical NAND writes and may include non-disk IO. The physical disk counter is also system-wide, not Codex-only. Still, the SQLite evidence above confirms that a large part of the churn is local persistence.

If the measured ~1.35 MB/s write rate were sustained, it would be approximately:

~116 GB/day
~42.5 TB/year

That is a meaningful fraction of common consumer SSD endurance ratings:

150 TBW drive:  ~28% of warranty TBW/year
300 TBW drive:  ~14% of warranty TBW/year
600 TBW drive:   ~7% of warranty TBW/year
1200 TBW drive:  ~3.5% of warranty TBW/year

Short bursts at the observed peak are not equivalent to sustained writes, but the issue is concerning because the churn is mostly diagnostic TRACE data and can recur throughout long Codex sessions.

Expected behavior

Production Codex Desktop builds should not persist high-frequency frame-level / dependency-level TRACE logs into logs_2.sqlite by default, especially when RUST_LOG=warn is in effect.

Expected improvements:

  • The SQLite log sink should honor the same effective log-level filter as the runtime logger, or have its own documented configuration.
  • Low-value TRACE target=log and websocket/tungstenite frame logs should be suppressed, sampled, summarized, or bounded.
  • Local diagnostic logs should have clear size/write caps, rotation, and WAL checkpoint/truncation behavior.
  • Users should have a documented option to disable or reduce persistent local diagnostic logging without disabling durable thread/state data.

Privacy note

I am not attaching logs_2.sqlite or raw feedback_log_body values because they may contain private session text, local paths, tool output, or protocol payload fragments.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 23 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30162
  • #29799
  • #29463
  • #29674
  • #30236

Powered by Codex Action

Nicolas0315 · 22 days ago

Additional 2026-06-29 JST sample after reducing active session JSONL load with official codex archive:

  • Codex Desktop version: 26.623.5546.0
  • Codex CLI: 0.142.3
  • ~/.codex/config.toml already has:
  • [analytics] enabled = false
  • [feedback] enabled = false
  • [otel] exporter = "none"
  • [otel] metrics_exporter = "none"
  • [otel] trace_exporter = "none"
  • [otel] log_user_prompt = false
  • 10s metadata-only SQLite sample, without reading feedback_log_body:
  • logs.id delta: 1,037 rows
  • WAL size delta: 0 bytes in this short window
  • Top targets:
  • TRACE log: 352 rows, estimated 352,063 bytes
  • DEBUG log: 140 rows, estimated 65,131 bytes
  • TRACE hyper_util::client::legacy::pool: 120 rows
  • TRACE hyper_util::client::legacy::client: 78 rows
  • TRACE codex_app_server::outgoing_message: 53 rows
  • 15s process CPU sample after session archive, excluding benchmark parse work:
  • total Codex/ssh/node_repl matched processes: 8.11% of one core
  • top Codex processes: 5.62%, 1.46%, 0.62%

So session JSONL load can be mitigated separately, but high-frequency TRACE/DEBUG persistence remains observable even with analytics/feedback/otel disabled in config.

Nicolas0315 · 22 days ago

Follow-up from the same Windows Codex Desktop profile (Codex Desktop 26.623.5546.0, CLI 0.142.3; 2026-06-29 03:40 JST):

Config/docs check:

  • local ~/.codex/config.toml has [analytics] enabled=false, [feedback] enabled=false, [otel] exporter="none", metrics_exporter="none", trace_exporter="none", log_user_prompt=false
  • current shell has RUST_LOG=warn; HKCU persistent user env has no RUST_LOG
  • fresh local Codex manual documents [analytics], [feedback], [otel], and RUST_LOG, but I did not find a documented knob specifically disabling local logs_2.sqlite TRACE persistence/retention beyond those settings
  • Desktop launches app-server as resources\codex.exe app-server --analytics-default-enabled

Read-only logs_2.sqlite aggregate, no log body/prompt fields read:

  • DB size: 102.5 MiB, rows: 26,317
  • all-time levels: TRACE 19,243; DEBUG 3,528; INFO 3,130; WARN 311; ERROR 100
  • last 5 minutes: 1,909 rows
  • last 5 minute top pairs: TRACE log 973; TRACE codex_mcp::connection_manager 494; TRACE codex_api::sse::responses 117; DEBUG codex_core::stream_events_utils 89

So TRACE persistence is still happening in normal Desktop usage even with analytics/feedback/OTel disabled in config. This continues to push the log DB past the local soft cap and adds SQLite/WAL pressure while the app is open.

Nicolas0315 · 22 days ago

Additional local mitigation to test on next Desktop restart (2026-06-29 04:19 JST):

Even after stopping idle MCP/plugin/node_repl helper processes, a 30s metadata-only sample still showed logs_2.sqlite writes at about 4.9 rows/s, led by TRACE log rows. The current shell had RUST_LOG=warn, but Codex Desktop launches app-server via Codex.exe, so the app-server likely did not inherit that transient shell env.

I persisted user-scope RUST_LOG=warn under HKCU:\Environment with restore metadata. Previous user value was absent. This should only take effect for future Codex Desktop/app-server launches. I will treat this as unverified until after a Desktop restart and another logs_2.sqlite write-rate sample.

Rollback is removing user RUST_LOG. If TRACE rows continue after restart, the local SQLite TRACE persistence is not controlled by RUST_LOG and needs product-side filtering/retention.

martinrodriguezr93-cloud · 22 days ago

Additional affected Windows machine data point from Codex Desktop 26.623.5546.0.

Environment:

  • OS: Windows, x64
  • Codex Desktop package: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0
  • Microsoft Store / winget reports no newer Store package available
  • Active Desktop app-server command: resources\codex.exe app-server --analytics-default-enabled
  • Local command runner present: codex-command-runner-0.142.3.exe
  • I also downloaded and verified the official GitHub prerelease CLI rust-v0.143.0-alpha.29 separately:
  • codex-cli 0.143.0-alpha.29
  • SHA256 codex.exe: EEA11264DFA89B7E6C4ECF45C0DC159D638929218DAF035D3EC31485CAC1555A
  • This does not update the Microsoft Store Desktop app-server path, so Desktop remains affected.

SSD / SMART context:

  • Disk: WD_BLACK SN850X 1000GB NVMe
  • SMART Data Units Written: 5,583,445
  • Converted host writes: about 2.859 TB decimal / 2.60 TiB
  • Power on hours: 225
  • SMART Percentage Used: 0
  • Media errors: 0
  • The disk is new and used mostly for Codex work, so avoidable diagnostic write churn is meaningful even though lifetime wear is still low.

Before local mitigation, metadata-only SQLite samples against C:\Users\<user>\.codex\logs_2.sqlite showed continuing insert/prune churn:

DB size: ~2.13 GiB
logs_2.sqlite-wal: ~95.23 MiB
retained rows: ~415k
max(id): >328M

20s sample:
delta_count: +51
delta_max_id: +8,442

30s sample:
delta_count: -129
delta_max_id: +4,868
ids_per_sec: ~162.3

60s sample:
delta_count: +1
delta_max_id: +8,976
ids_per_sec: ~149.6

Recent retained rows were still dominated by TRACE, with top pairs including:

TRACE log
TRACE codex_api::sse::responses
TRACE codex_mcp::connection_manager
TRACE codex_core::client

Windows process I/O counters during the affected run also showed large cumulative Codex writes since process start:

codex.exe app-server process: ~219 GB written since process start
Codex matched processes total: ~295 GB written since process start

I understand process I/O counters are not the same as physical NAND writes, but the SQLite metadata confirms real local persistence churn.

Local workaround applied:

  • Backed up logs_2.sqlite, logs_2.sqlite-wal, and logs_2.sqlite-shm
  • Added a SQLite trigger:
CREATE TRIGGER IF NOT EXISTS codex_block_logs_insert_ssd_mitigation_20260628
BEFORE INSERT ON logs
BEGIN
  SELECT RAISE(IGNORE);
END;
  • Ran PRAGMA wal_checkpoint(TRUNCATE)

After workaround:

60s sample:
delta_count: 0
delta_max_id: 0
delta_estimated_mb: 0
wal_delta_mb: 0

logs_2.sqlite-wal: 95.23 MB -> 0 MB

Conclusion:

Codex Desktop 26.623.5546.0 on Windows still appears to persist or attempt high-frequency diagnostic TRACE rows into logs_2.sqlite during ordinary Desktop use. The local trigger stops SQLite inserts, but this is only a defensive workaround. The product still needs an upstream fix: production Desktop should not persist high-frequency TRACE/DEBUG transport/dependency logs by default, and there should be a documented user-facing kill switch or bounded persistent-log policy for local diagnostic SQLite logs.

Privacy note: I did not attach logs_2.sqlite or raw feedback_log_body values because they may contain private prompts, local paths, tool output, or protocol payload fragments.

martinrodriguezr93-cloud · 22 days ago

Follow-up from the same Windows machine after testing the official alpha binary: