codex日志大量写入硬盘会影响硬盘寿命

cabudon 2026-06-20 10:25 1

下面是原来链接，有没有懂的，文本居然能做到5m/s，想不出来

https://x.com/bdsqlsz/status/2067964486615810369?s=20

github.com/openai/codex

Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance

已打开 09:34PM - 14 Jun 26 UTC

1996fanrui

bug

CLI

performance

# Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endu…rance

## Issue

Codex is continuously writing a large amount of data to the local SQLite feedback log database:

- `~/.codex/logs_2.sqlite`
- `~/.codex/logs_2.sqlite-wal`
- `~/.codex/logs_2.sqlite-shm`

On my machine, after about **21 days of uptime**, the main SSD has written about **37 TB**. Process/file-level checks show Codex SQLite logs are the main continuous writer.

That extrapolates to roughly **640 TB/year**. On a **1 TB SSD**, that is about **640 full-drive writes per year**. Some consumer SSDs are rated around **600 TBW**, so this could consume roughly a full drive's warranted write endurance in less than a year.

## Evidence

Current retained rows in `logs_2.sqlite`:

| metric | value |
| --- | ---: |
| retained rows | 681,774 |
| estimated retained log content | 1,035.6 MiB |

Level distribution:

| level | estimated MiB | byte % |
| --- | ---: | ---: |
| TRACE | 732.5 | 70.7% |
| INFO | 266.5 | 25.7% |
| DEBUG | 30.6 | 3.0% |
| WARN | 5.9 | 0.6% |

Largest target+level pairs:

| target | level | estimated MiB |
| --- | --- | ---: |
| `codex_api::endpoint::responses_websocket` | TRACE | 527.4 |
| `codex_otel.log_only` | INFO | 141.2 |
| `codex_otel.trace_safe` | INFO | 121.2 |
| `log` | TRACE | 97.4 |
| `codex_client::transport` | TRACE | 60.1 |
| `codex_core::stream_events_utils` | DEBUG | 27.5 |
| `codex_api::sse::responses` | TRACE | 19.1 |

The top sources are mostly global TRACE logs, mirrored telemetry logs, and raw websocket/SSE payload logging. `TRACE` alone is about **70.7%** of retained bytes. `codex_otel.log_only` + `codex_otel.trace_safe` add another **25.3%**. Filtering these categories should remove roughly **96%** of retained log bytes in this sample without fully disabling feedback logs.

<details>
<summary>Sanitized examples from the most frequent TRACE source: <code>target=log</code></summary>

These are high-frequency retained samples. Raw websocket/SSE payload bodies are intentionally not included because they may contain private conversation content.

```text
128,764x TRACE log: inotify event: ... mask: OPEN, name: Some("ld.so.cache")
37,982x TRACE log: inotify event: ... mask: OPEN, name: Some("locale.alias")
23,843x TRACE log: inotify event: ... mask: OPEN, name: Some("passwd")
3,639x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:131 AllowStd.with_context
3,505x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:245 WebSocketStream.with_context
3,362x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:154 Read.read
3,356x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:157 Read.with_context read -> poll_read
3,230x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:294 Stream.poll_next
3,227x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:304 Stream.with_context poll_next -> read()
3,213x TRACE log: inotify event: ... mask: OPEN, name: Some("nsswitch.conf")
2,001x TRACE log: WouldBlock
1,217x TRACE log: Masked: false
1,169x TRACE log: Opcode: Data(Text)
1,169x TRACE log: First: 11000001
```

</details>

<details>
<summary>Sanitized examples from frequent INFO sources</summary>

The dominant INFO sources are mostly repeated OpenTelemetry mirror events. IDs are redacted.

```text
843x INFO codex_client::custom_ca:
using system root certificates because no CA override environment variable was selected ...

334x INFO codex_otel.trace_safe:
session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<redacted> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...}

333x INFO codex_otel.log_only:
session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<redacted> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...}

332x INFO codex_otel.log_only:
session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<redacted> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...}

332x INFO codex_otel.trace_safe:
session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<redacted> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...}
```

</details>

## Write amplification

The retained DB size hides the real write volume. In a 15-second sample:

| metric | before | after |
| --- | ---: | ---: |
| retained rows | 681,774 | 681,774 |
| max row id | 5,003,347,015 | 5,003,383,226 |

About **36,211 rows were inserted in 15 seconds**, while retained row count stayed flat. This suggests continuous insert-and-prune write amplification: rows are inserted, indexed, written to WAL, then pruned.

## Likely cause

The SQLite feedback log sink is installed with a global TRACE default:

```rust
Targets::new().with_default(Level::TRACE)
```

This persists all targets at TRACE level by default, including dependency/internal logs and large raw protocol payloads.

## Proposed fix

Keep feedback logs enabled, but narrow what is persisted by default:

1. Do not use global TRACE for the SQLite feedback log sink.
2. Drop or raise thresholds for low-value dependency noise, especially `target=log`, `hyper_util`, tokio-tungstenite internals, inotify spam, and low-level OpenTelemetry SDK logs.
3. Avoid persisting full raw websocket/SSE payloads by default. Store summaries instead: event kind, duration, success/error, token usage, and payload byte length.
4. Avoid persisting mirrored `codex_otel.log_only` / `codex_otel.trace_safe` events unless they are explicitly useful for feedback debugging.
5. Add a global logs DB size/write cap. Per-thread caps are not enough when many threads/processes exist.

An optional escape hatch such as `sqlite_logs_enabled = false` would still be useful, but the main fix should be better default filtering.

## Related issues and discussions

- https://github.com/openai/codex/issues/17320
- https://github.com/openai/codex/issues/24275
- https://github.com/openai/codex/issues/26374
- https://github.com/openai/codex/issues/22444
- https://github.com/openai/codex/issues/20563
- https://github.com/openai/codex/issues/27020
- https://github.com/openai/codex/issues/27911
- https://github.com/openai/codex/issues/21134
- https://github.com/openai/codex/pull/12969

github.com/openai/codex

Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG

已打开 09:19AM - 10 Apr 26 UTC

piotrkacala

bug

agent

### What version of the IDE extension are you using?

`openai.chatgpt-26.406.310…14-linux-x64` (VSCodium on Linux Mint)

### What subscription do you have?

ChatGPT Plus

### Which IDE are you using?

VSCodium (Code - OSS fork)

### What platform is your computer?

Linux x64 (Linux Mint)

### What issue are you seeing?

During model streaming responses, the Codex `app-server` binary writes **~5 MiB/s** (observed up to ~16 MiB/s in `iotop`) to `~/.codex/logs_2.sqlite-wal`. This results in sustained disk write rates that can significantly impact SSD longevity and system performance.

This issue is independent of the `thread-stream-state-changed` warning spam and the `open-in-targets` retry loop, which were investigated separately.

### Root cause

The extension correctly sets `RUST_LOG=warn` when spawning the `app-server` process — confirmed via `/proc/<pid>/environ`:

```
RUST_LOG=warn
```

However, the SQLite logging sink appears to bypass or not respect the `RUST_LOG` filter, since TRACE-level entries are still persisted to `logs_2.sqlite` despite `RUST_LOG=warn`. The SQLite logging path appears to operate outside of the standard `RUST_LOG` filtering mechanism, or uses a separate filter configuration.

This was confirmed via `strace` during streaming:

```
pwrite64(20</home/k/.codex/logs_2.sqlite-wal>, ..., 4096, ...) = 4096
pwrite64(20</home/k/.codex/logs_2.sqlite-wal>, ..., 4096, ...) = 4096
...
```

And via SQLite query — MAX(id) jumped by **~5000 rows** for a single short (~50 token) response, while total row count remained stable, indicating that rows are being rapidly inserted and pruned/rotated during streaming:

```
-- Before response:
SELECT MAX(id), COUNT(*) FROM logs; --> 3088667 | 30141

-- After response:
SELECT MAX(id), COUNT(*) FROM logs; --> 3093673 | 30141
```

Log level breakdown in `logs_2.sqlite`:

```
TRACE 20485 (68%)
INFO 8286
DEBUG 1326
WARN 44
```

Sample TRACE entries written during streaming:

```
target=hyper_util::client::legacy::pool feedback_log_body="idle interval checking for expired"
target=log feedback_log_body="WouldBlock"
target=log feedback_log_body="/home/runner/work/codex/codex/.cargo-home/git/checkouts/tokio-tungstenite-..."
```

These are low-level internal network events from `tokio-tungstenite` and `hyper_util` with no diagnostic value for end users. They should not be persisted to disk in a production binary — and critically, they are not suppressed by `RUST_LOG=warn` as one would expect.

### What steps can reproduce the bug?

1. Open a workspace in VSCodium/VS Code with the Codex extension.
2. Confirm `RUST_LOG=warn` is set:
```bash
cat /proc/$(pgrep -f 'codex.*app-server')/environ | tr '\0' '\n' | grep RUST_LOG
```
3. Run `strace -f -e trace=pwrite64 -p $(pgrep -f 'codex.*app-server')` in a separate terminal.
4. Ask any question in the Codex chat panel and observe streaming.
5. Observe continuous `pwrite64` calls to `logs_2.sqlite-wal` at ~5 MiB/s despite `RUST_LOG=warn`.

Alternatively, check log level distribution after a session:
```bash
sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"
```

### What is the expected behavior?

`RUST_LOG=warn` should suppress TRACE and DEBUG output everywhere, including the SQLite logging sink. The current behavior — where `RUST_LOG=warn` suppresses stderr output but does not affect SQLite persistence — is inconsistent and undocumented.

TRACE-level events from internal networking libraries (`tokio-tungstenite`, `hyper_util`) should never be written to the persistent SQLite log database during normal operation.

### Additional information

### Suggested fix

The SQLite logging sink in `app-server` should apply the same log-level filter as `RUST_LOG` (or the internal `tracing` subscriber filter), rather than maintaining a separate or hardcoded verbosity level. The fix should ensure that setting `RUST_LOG=warn` — as the extension already does — is sufficient to suppress TRACE/DEBUG writes to `logs_2.sqlite`.

### Workaround

Users can redirect `logs_2.sqlite` to tmpfs to protect their SSD while waiting for a fix:

```bash
# stop VSCodium first
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite
```

Note: `logs_2.sqlite` contains only internal diagnostic logs — no conversation history — so data loss on reboot is acceptable.

After symlinking logs_2.sqlite to tmpfs, disk I/O from the Codex extension dropped to zero during streaming, confirming that the SQLite WAL is the sole source of the observed write load.

### Workaround 2: block inserts into the SQLite log table

Another workaround was suggested by @synap5e in this comment:
https://github.com/openai/codex/issues/17320#issuecomment-4514992998

Instead of redirecting `logs_2.sqlite` to tmpfs, users can prevent new rows from being inserted into the `logs` table by adding a SQLite trigger:

```bash
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
```

This causes attempted inserts into the logs table to be ignored without returning an error to the application, which should prevent logs_2.sqlite-wal from growing due to persistent TRACE/DEBUG log writes.

To remove the workaround:

```bash
sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;"
```

As with the tmpfs workaround, this is not a proper fix. It disables local persistent logging rather than fixing the underlying issue: the SQLite logging sink appears to ignore RUST_LOG=warn and continues persisting TRACE/DEBUG entries during normal streaming.

解决办法，把下面这个问ai，然后让ai执行

临时处理办法：

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

使用 SQLite3 禁用生成新日志

站内也有人提到，可惜没有深究，起初人们只觉得这是普通的占用过大

自从用了codex 后，发现磁盘越来越小了，看了一些任务的目录，没有规律的创建，到处都有。
是我用的不对吗？还是有什么技巧呢？

最新回复 (9)

xx_yy1 06-20 10:27

1楼

很正常的情况,因为他这个不是什么垃圾日志
Huagnqf 06-20 10:47

2楼

我用cursor诊断了一下我的情况，问题还挺严重的，主要不是占用空间，而是反复读写。

以下是cursor给出的部分结论。
kerryeva 06-20 13:23

3楼

奥特曼是不是有三星或者海力士的股？？
szzz 06-20 15:00

4楼

害怕

奥特曼想要毁了我的硬盘吗？
killer 06-20 15:52

5楼

我 Codex和 Open Code 用的比较多嘛，发现他们俩都有这种问题。

尤其是 Codex，我大概每三四天就需要去删除一下它的数据库。

因为我一天平均下来要用 1B 的 token，然后大概三四天， Codex 的数据库就到六七 G。

而且 Codex 本身也感觉会变得更卡，就很奇怪。

然后 Open Code 也是这样的，就是有一个非常大的数据库，就非常的离谱。

Open Code 也是数据库能到六七 G，然后我也是要几天清一次。尤其是 Open Code 特别喜欢用 subagent 嘛，然后这些 subagent 也都会保留下来，然后就导致这个数据库特别特别的大，膨胀的特别特别快。

dskdkj 06-20 15:53

6楼

由于我长期多开20个左右的codex会话，观测到CPU占用异常高(表现是PSI值>10%)，昨天独立遇到这个问题

我的缓解：

把本仓已经隔离出来的 session-local CODEX_HOME 运行态放到 /run/user/$UID 这类 tmpfs

只把 auth/config/memories/sessions 等持久条目继续软链回原位置

SQL trigger 也可做临时止血，但会直接禁用本地持久日志，工程上不如 tmpfs 隔离干净。

省流就是这么喜欢写让它写内存去，不要祸害SSD

九十 06-20 16:01

7楼

这种体量的软件居然还会有这种流氓的行为逻辑，量大本来这个问题倒影响不大，codex倒是实现一个批量写入呀，大大减少落地的频率
sonotokan 06-23 10:56

8楼

最新release把log禁用了
Jonathan 06-28 00:34

9楼

怎么判断现在用的 codex 是不是还有这个问题？

* 帖子来源Linux.do

附近帖子

飞读

cabudon

主题数
1

帖子数
1

注册排名
3

随机推荐