macOS: Persistent SQLite TRACE target=log churn remains after rust-v0.142.0
已打开 02:41AM - 23 Jun 26 UTC
bug
app
app-server
performance
## Summary
After upgrading to `rust-v0.142.0`, I can still reproduce persistent… SQLite log churn on macOS in `~/.codex/logs_2.sqlite`.
This looks like a partial fix:
- `#29432` appears to have helped: `codex_api::endpoint::responses_websocket` is much lower than before.
- However, `#29457` does not appear to fully solve the persistent SQLite churn in this app build/runtime. The release note says noisy persistent log targets were filtered, and the PR says bridged `target=log` events should be excluded from the SQLite sink, but `TRACE target=log` is still the dominant persisted target here.
I also posted an earlier data point in the closed umbrella issue `#28224` here:
https://github.com/openai/codex/issues/28224#issuecomment-4775086154
Opening a new issue because `#28224` is closed and this is post-`rust-v0.142.0` macOS data.
## Environment
- Platform: macOS 26.5.1, arm64
- Codex app: `26.616.71553`, build `4265`
- Embedded CLI: `codex-cli 0.142.0`
- PATH CLI: `codex-cli 0.142.0`
- App-server process: `/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled`
- App-server PID/start at sample time: `7763`, started `Tue Jun 23 10:17:10 2026`
- `RUST_LOG`: empty
- `~/.codex/config.toml`: `[analytics] enabled = false`
- SQLite trigger count during the sample: `0`
- `logs_2.sqlite` journal mode: `wal`
No local `block_log_inserts` trigger was present during this sample.
## Files observed
At the start of the sample:
```text
~/.codex/logs_2.sqlite 745,517,056 bytes
~/.codex/logs_2.sqlite-wal 4,437,272 bytes
~/.codex/logs_2.sqlite-shm 32,768 bytes
```
The active app-server process was holding the DB/WAL/SHM files open.
## Read-only 60 second sample
Sample window:
```text
2026-06-23 10:43:00 +0800 to 2026-06-23 10:44:00 +0800
```
SQLite metadata before/after:
```text
trigger_count: 0 -> 0
row_count: 200589 -> 200589
max_id: 725810463 -> 725811933
sqlite_seq: 725810463 -> 725811933
max_ts: 1782182580 -> 1782182638
```
So the retained row count stayed flat, but `sqlite_sequence` / `max_id` advanced by `1,470` in about 60 seconds. This looks like continued insert-and-prune churn.
File mtimes also moved during the sample:
```text
logs_2.sqlite mtime: 1782182580 -> 1782182613
logs_2.sqlite-wal mtime: 1782182580 -> 1782182638
```
The WAL size stayed stable at about 4.4 MB, so file size alone hides the ongoing write activity.
## Recent persisted targets
Rows in the last 60 seconds:
```text
TRACE log 989 rows, 526.8 KiB
TRACE codex_api::sse::responses 14 rows, 14.0 KiB
TRACE codex_app_server::outgoing_message 12 rows, 2.0 KiB
TRACE codex_mcp::connection_manager 6 rows, 4.9 KiB
DEBUG codex_core::stream_events_utils 3 rows, 3.3 KiB
INFO feedback_tags 3 rows, 3.0 KiB
INFO codex_core::stream_events_utils 2 rows, 5.5 KiB
TRACE codex_api::endpoint::responses_websocket 1 row, 40.8 KiB
TRACE codex_core::session::turn 1 row, 0.9 KiB
```
TRACE targets in the last 5 minutes:
```text
log 989 rows, 526.8 KiB
codex_api::sse::responses 238 rows, 239.5 KiB
codex_mcp::connection_manager 18 rows, 13.8 KiB
codex_app_server::outgoing_message 12 rows, 2.0 KiB
codex_core::session::turn 2 rows, 1.8 KiB
codex_api::endpoint::responses_websocket 2 rows, 80.0 KiB
```
## Expected behavior
After `rust-v0.142.0`, Codex should not continuously persist high-frequency `TRACE target=log` rows into `logs_2.sqlite` by default, especially after `#29457`.
## Actual behavior
Codex app-server continued to insert high-frequency `TRACE target=log` rows into the persistent SQLite log sink. The retained row count stayed flat, but `max(id)` / `sqlite_sequence` kept advancing and the DB/WAL mtimes kept moving, indicating ongoing insert-and-prune churn.
## Privacy note
I am intentionally not pasting raw `feedback_log_body` contents because they may contain private conversation, local path, tool, or response data.
enochyoung 06-23 13:411楼
orange-2026 06-23 14:332楼