›_ Codex Issues
Codex Issues / #29814

Codex 0.142.0 still writes high-volume TRACE logs into ~/.codex/logs_2.sqlite after restart

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

Summary:
I am still seeing very high-volume TRACE logging into ~/.codex/logs_2.sqlite on codex-cli 0.142.0, even though the 0.142.0 release notes mention reduced persistent-log churn.

Environment:

  • Date observed: 2026-06-24
  • Codex version: codex-cli 0.142.0
  • Surface: Codex app / local desktop usage
  • OS: macOS
  • RUST_LOG in shell: warn

What I observed:

  1. After a clean restart, the first normal conversation immediately recreated high-frequency TRACE writes.
  2. Within about 60 seconds, recent logs included 1042 TRACE rows.
  3. The WAL file quickly regrew to about 4.1-4.2 MB.
  4. Recent entries were still websocket/frame-level TRACE records, e.g. tokio-tungstenite frame parsing / received frame / parsed headers / received message.

Evidence collected before workaround:

  • logs_2.sqlite had previously grown to about 198 MB before vacuuming.
  • After conservative maintenance, a restart reproduced the issue immediately.
  • First post-restart sample:
  • logs_2.sqlite-wal: ~4.1 MB
  • recent 60s levels: TRACE 1042, DEBUG 20, INFO 19, WARN 2
  • 6 seconds later:
  • recent 10s levels: TRACE 373, DEBUG 8, INFO 4, WARN 1

Mitigation that worked locally:
I added a local SQLite trigger as a temporary workaround:

CREATE TRIGGER block_trace_logs_before_insert
BEFORE INSERT ON logs
WHEN NEW.level = 'TRACE'
BEGIN
  SELECT RAISE(IGNORE);
END;

After restarting Codex with that trigger in place:

  • TRACE stopped appearing in recent samples.
  • Recent logs became DEBUG / INFO / WARN / ERROR only.
  • Example follow-up sample over 10 seconds:
  • DEBUG 10, INFO 7, WARN 1, TRACE 0
  • WAL still grew normally, but no longer at the previous TRACE-heavy rate.

Why I think this is still a bug:

  • The issue reproduces on 0.142.0.
  • It reproduces even with RUST_LOG=warn.
  • The trigger workaround strongly suggests some TRACE-path writes are still reaching the persistent SQLite log store.

If helpful, I can provide:

  • exact sampled SQL queries
  • before/after file sizes
  • representative recent rows from the logs table

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 26 days ago

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

  • #29612
  • #29532
  • #29589
  • #29799
  • #29674

Powered by Codex Action

Internal-Tide · 26 days ago

Same as you

juzt-dev · 26 days ago

Same as you, how to fix it ?

shaoliang-ai · 26 days ago

Temporary workaround that worked for me on macOS / Codex 0.142.0:
Quit Codex completely.
Back up:~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

Add this SQLite trigger:
CREATE TRIGGER IF NOT EXISTS block_trace_logs_before_insert
BEFORE INSERT ON logs
WHEN NEW.level = 'TRACE'
BEGIN
SELECT RAISE(IGNORE);
END;
Then run:
sqlite3 ~/.codex/logs_2.sqlite "PRAGMA wal_checkpoint(TRUNCATE);"
This is only a local workaround, not an official fix. In my case it stopped new TRACE rows from being persisted and greatly reduced the log churn / WAL growth.
I’m keeping this trigger in place until Codex 0.143.0+ is available, since PR #29599 says that part of the fix is expected there.

Hisakuras · 26 days ago

Additional Analysis: SSD Wear Impact & RAM Disk Mitigation

I've conducted a deeper analysis of this issue and found that the impact is more severe than just log volume:

🔴 Severity Assessment

The TRACE logging causes significant SSD wear:

| Metric | Value |
|--------|-------|
| Write speed | ~5MB/s sustained |
| Annual writes | ~640TB |
| SSD impact | Can exhaust 600TBW consumer SSD in <1 year |
| Root cause | ~/.codex/logs_2.sqlite with WAL mode |

📊 My Environment

  • OS: macOS 15.7.5
  • Codex version: 26.616.81150 (desktop app)
  • Surface: Codex Desktop App
  • Log location: ~/.codex/logs_2.sqlite

✅ Verified Mitigation: RAM Disk

I've implemented a RAM disk solution that completely eliminates SSD wear:

Steps:

  1. Create 256MB RAM disk: diskutil erasevolume HFS+ 'CodexRAM' $(hdiutil attach -nomount ram://524288)
  2. Migrate logs: cp ~/.codex/logs_2.sqlite /Volumes/CodexRAM/
  3. Create symlink: ln -s /Volumes/CodexRAM/logs_2.sqlite ~/.codex/logs_2.sqlite
  4. Configure auto-create on boot via launchd

Results:

  • ✅ SSD writes eliminated (0TB/year)
  • ✅ Logs persist in RAM only
  • ✅ Auto-cleared on reboot (acceptable for logs)
  • ✅ ~36% reduction in TRACE logs observed after update

💡 Recommendations for Official Fix

  1. Reduce TRACE frequency: Current rate of ~1,000+ TRACE/hour is excessive
  2. Batch writes: Instead of immediate WAL flush, batch every 5-10 seconds
  3. Log rotation: Implement automatic cleanup (keep only last 7 days)
  4. Async logging: Use async channels to decouple logging from main thread
  5. Optional RAM mode: Provide official option to store logs in RAM

📎 References

  • Related: #29832 (Windows disk writes)
  • My analysis shows codex_api::sse::responses generates ~90% of TRACE logs

Happy to provide more detailed logs or testing if needed.

Oops-maker · 25 days ago

I can also reproduce this on Linux with codex-cli 0.142.0.

## Environment

  • Codex version: codex-cli 0.142.0
  • OS: Linux
  • Filesystem location: ~/.codex/logs_2.sqlite
  • Usage surface: local Codex desktop/app-server/CLI sessions
  • Date observed: 2026-06-25

## What I observed

After normal Codex usage, ~/.codex/logs_2.sqlite continues to receive high-volume TRACE rows.

Current file sizes:

``text
~/.codex/logs_2.sqlite 277 MiB
~/.codex/logs_2.sqlite-wal 5.6 MiB
~/.codex/logs_2.sqlite-shm 32 KiB
``
Recent sample from the logs table:

``text
last_1_min rows=3006 trace_rows=2817
last_10_min rows=5248 trace_rows=4867
newest 2026-06-25 12:00:16
``

So this instance was still writing roughly 47 TRACE rows/sec at the time of sampling.
The dominant recent targets were:

```text
log TRACE
codex_api::sse::responses TRACE
hyper_util::client::legacy::pool TRACE
hyper_util::client::legacy::client TRACE


  Earlier samples from the same machine also showed websocket/tungstenite-related TRACE entries, for example tokio-tungstenite frame/read polling records.

  ## Disk impact

  This is not just retained log volume in SQLite; the WAL file is actively updated. During one short sample window, the system disk write counter increased by roughly 31 MB over 20 seconds, around 1.5 MB/s. Multiple running codex processes were also holding logs_2.sqlite / logs_2.sqlite-wal open.

  ## Why this still looks like a bug

  The 0.142.0 release notes mention reduced persistent-log churn, but in this environment TRACE rows still reach the persistent SQLite log store at high frequency.

  This also appears independent of normal user-facing log level expectations: these are internal TRACE-level records being persisted into ~/.codex/logs_2.sqlite, not just emitted to a terminal.

  ## Temporary mitigation: move the SQLite log DB to tmpfs

  A possible local workaround is to put the log database on tmpfs and symlink Codex’s expected path to it:

 ```bash
  mkdir -p /dev/shm/codex-logs

  mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak.$(date +%s)
  rm -f ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm

  ln -s /dev/shm/codex-logs/logs_2.sqlite ~/.codex/logs_2.sqlite
  ln -s /dev/shm/codex-logs/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-wal
  ln -s /dev/shm/codex-logs/logs_2.sqlite-shm ~/.codex/logs_2.sqlite-shm

On many Linux systems /dev/shm is tmpfs, so this keeps the SQLite churn in memory instead of on the SSD.

### Pros

  • Avoids high-frequency TRACE/WAL writes to the SSD.
  • Automatically clears logs after reboot.
  • Does not require modifying Codex binaries.
  • Easy to revert by removing the symlinks and restoring the .bak file.

### Cons / risks

  • Logs are lost on reboot, which can make debugging harder.
  • Existing Codex processes that already opened the old SQLite file may keep writing to the old inode until restarted.
  • /dev/shm has limited capacity; if the logging bug gets worse, it could consume RAM-backed tmpfs space.
  • This only mitigates disk wear and space churn. It does not fix the underlying issue that TRACE records are still being generated and inserted.
  • It may not be portable to macOS or Windows as written.

## Preferred product-side fix

Ideally, Codex should prevent TRACE-level records from entering the persistent SQLite log store by default, especially high-frequency transport/frame/polling logs.

Possible fixes:

  1. Apply a persistent-log minimum level filter, e.g. do not persist TRACE unless an explicit debug flag is enabled.
  2. Separate diagnostic transport logs from durable user/session logs.
  3. Rate-limit or sample repeated websocket/SSE/hyper TRACE events.
  4. Make the persistent log level configurable in config.toml.
  5. Add a size/retention cap for logs_2.sqlite and its WAL.

The tmpfs workaround helps users avoid SSD churn, but the better fix is to stop high-volume TRACE records from reaching persistent storage in normal usage.

gm-fire · 25 days ago

<img width="380" height="264" alt="Image" src="https://github.com/user-attachments/assets/b25813cb-cf31-4c12-89bf-9baf3e1faf98" />

补充一个脱敏的 macOS 数据点：

  • 观测到 ~/.codex/logs_2.sqlite 仍在高频写入 TRACE。
  • 10 秒窗口内新增 178 行，其中 176 行是 TRACE。
  • 60 秒窗口内 TRACE 为 21,964 行，约占该窗口 65%。
  • 5 秒 live sample 中新增 59 行，其中 49 行是 TRACE。
  • 最近写入的 TRACE 热点主要是 codex_mcp::connection_manager、log、hyper_util::client::legacy::client、hyper_util::client::legacy::pool、codex_client::transport。

我刻意没有贴原始 feedback_log_body、本机路径、会话 ID 或其他可识别信息。

这和 issue 里描述的 persistent TRACE / WAL churn 现象一致。

taogezhizun · 25 days ago

Additional macOS Desktop data point, still reproducible on the current desktop build I have today.

Environment:

  • Date observed: 2026-06-25 14:44 CST
  • Codex Desktop: 26.616.81150
  • Bundle: 4306
  • Bundled CLI: codex-cli 0.142.0
  • Surface: Codex Desktop app-server
  • Writer process: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
  • RUST_LOG=warn
  • [analytics] enabled = false is set in ~/.codex/config.toml

Observed from ~/.codex/logs_2.sqlite after normal Desktop usage:

Recent 1 minute levels:
TRACE 1126  (~1.232 MiB estimated_bytes)
INFO    25
DEBUG   22
WARN     4

Top TRACE targets in that 1-minute window:

log                                       1019 rows  ~0.407 MiB
codex_api::sse::responses                   71 rows  ~0.071 MiB
codex_mcp::connection_manager               20 rows  ~0.016 MiB
codex_app_server::outgoing_message           7 rows  ~0.001 MiB
codex_api::endpoint::responses_websocket     4 rows  ~0.734 MiB
codex_core::session::turn                    3 rows  ~0.003 MiB

Short live sample over about 12 seconds:

rows:   52153 -> 52280
TRACE:  28578 -> 28678
max(id): 25762595 -> 25764867
last_10s_trace stayed around 1100-1300 for most samples
WAL mtime kept updating during the sample

This suggests the Desktop app-server path is still persisting high-frequency TRACE rows even with RUST_LOG=warn and analytics disabled. The volume is not only raw row count: a small number of codex_api::endpoint::responses_websocket TRACE rows can still account for a large share of bytes.

I also compared this with an isolated CLI run using a separate CODEX_SQLITE_HOME; codex exec --ephemeral left the isolated logs_2.sqlite logs table at 0 rows. So the remaining issue appears to be specific to the Desktop/app-server path rather than the codex exec path in my local test.

No raw feedback_log_body, session IDs, thread IDs, or machine-specific home paths included here.

denispol · 25 days ago

Confirming this on codex-cli 0.142.2, pinned to source tag rust-v0.142.2 (390b0d25). It's platform-independent (same as the Windows reports #29799/#29463 and macOS #29532); I just hit it on macOS where the OS flags excessive disk writes and, on a busy volume, the continuous WAL I/O stalled the host. It is disk I/O, not memory (process footprint ~130 MB).

Root cause confirmed: log_db::default_filter() hardcodes TRACE and the SQLite sink ignores RUST_LOG. Fix makes the level configurable and defaults it to INFO: https://github.com/denispol/codex/pull/1

taogezhizun · 25 days ago

Follow-up after upgrading Codex Desktop today: the Desktop/app-server path still reproduces high-frequency persistent TRACE writes on my machine.

Environment:

  • Date observed: 2026-06-26 10:56 CST
  • Codex Desktop: 26.623.31443
  • Bundle: 4441
  • Bundled CLI: codex-cli 0.142.2
  • Surface: Codex Desktop app-server
  • Writer process: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
  • Local config still has [analytics] enabled = false
  • RUST_LOG=warn

Recent 1-minute levels from ~/.codex/logs_2.sqlite:

TRACE 1516  (~1.054 MiB estimated_bytes)
DEBUG  144
INFO    61
WARN     8

Top TRACE targets in that 1-minute window:

log                                        1236 rows  ~0.138 MiB
codex_api::sse::responses                    81 rows  ~0.080 MiB
hyper_util::client::legacy::pool             63 rows  ~0.015 MiB
hyper_util::client::legacy::client           51 rows  ~0.013 MiB
codex_mcp::connection_manager                32 rows  ~0.019 MiB
rmcp::service                                19 rows  ~0.014 MiB
hyper_util::client::legacy::connect::http    17 rows  ~0.005 MiB
codex_app_server::message_processor          14 rows  ~0.003 MiB
codex_api::endpoint::responses_websocket      3 rows  ~0.756 MiB
codex_core::client                            2 rows  ~0.002 MiB

Short live sample over about 12 seconds:

max(id): 28422369 -> 28436123
WAL mtime kept updating every sample
last_10s_trace stayed around 998-1383

So with Desktop 26.623.31443 / bundled CLI 0.142.2, I still see the app-server path persisting high-frequency TRACE rows. Some byte volume may be lower than the worst earlier websocket-heavy samples, but the row frequency remains clearly abnormal.

No raw feedback_log_body, session IDs, thread IDs, or user-specific home paths included.