问题Codex正在不断地将大量数据写入本地SQLite反馈日志数据库：~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm 在我的机器上，21天的正常运行后，主SSD已经写入了约37 TB。进程/文件级别检查显示Codex SQLite日志是主要的持续写入者。这推测出约640 TB/年。在1 TB的SSD上，大约是每年640次完全写入。一些消费级SSD的评级在600 TBW左右，因此这可能在不到一年的时间内消耗掉一个完整驱动器的保修写入耐用性。证据 当前在logs_2.sqlite中保留的行：指标 值 保留行 681,774 估计保留日志内容 1,035.6 MiB 级别分布：级别 估计 MiB 字节 % TRACE 732.5 70.7% INFO 266.5 25.7% DEBUG 30.6 3.0% WARN 5.9 0.6% 最大目标+级别对：目标 级别 估计 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 主要来源大多数是全局TRACE日志、镜像遥测日志和原始WebSocket/SSE有效载荷日志。TRACE单独占保留字节的约70.7%。codex_otel.log_only + codex_otel.trace_safe又增加了约25.3%。过滤这些类别应在不完全禁用反馈日志的情况下删除大约96%的保留日志字节。来自最频繁TRACE来源的净化示例：目标=log 这些是高频率保留样本。 原始WebSocket/SSE有效载荷主体故意未包括，因为它们可能包含私人对话内容。 128,764x TRACE日志：inotify事件：...屏蔽：OPEN，名称：Some("ld.so.cache") 37,982x TRACE日志：inotify事件：...屏蔽：OPEN，名称：Some("locale.alias") 23,843x TRACE日志：inotify事件：...屏蔽：OPEN，名称：Some("passwd") 3,639x TRACE日志：<tokio-tungstenite checkout>/src/compat.rs:131 AllowStd.with_context 3,505x TRACE日志：<tokio-tungstenite checkout>/src/lib.rs:245 WebSocketStream.with_context 3,362x TRACE日志：<tokio-tungstenite checkout>/src/compat.rs:154 Read.read 3,356x TRACE日志：<tokio-tungstenite checkout>/src/compat.rs:157 Read.with_context read -> poll_read 3,230x TRACE日志：<tokio-tungstenite checkout>/src/lib.rs:294 Stream.poll_next 3,227x TRACE日志：<tokio-tungstenite checkout>/src/lib.rs:304 Stream.with_context poll_next -> read() 3,213x TRACE日志：inotify事件：...屏蔽：OPEN，名称：Some("nsswitch.conf") 2,001x TRACE日志：WouldBlock 1,217x TRACE日志：已屏蔽：假 1,169x TRACE日志：操作码：数据（文本） 1,169x TRACE日志：首个：11000001 频繁INFO来源的净化示例 主要INFO来源大多数是重复的OpenTelemetry镜像事件。ID被删减。 843x INFO codex_client::custom_ca：使用系统根证书，因为没有选择CA覆盖环境变量... 334x INFO codex_otel.trace_safe：session_loop{thread_id=<删减>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<删减> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<删减> ...} 333x INFO codex_otel.log_only：session_loop{thread_id=<删减>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<删减> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<删减> ...} 332x INFO codex_otel.log_only：session_loop{thread_id=<删减>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<删减> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<删减> ...} 332x INFO codex_otel.trace_safe：session_loop{thread_id=<删减>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<删减> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<删减> ...} 写入放大 保留的数据库大小掩盖了实际写入量。在一次15秒的样本中：指标 之前 之后 保留行 681,774 681,774 最大行ID 5,003,347,015 5,003,383,226 在15秒内插入了大约36,211行，而保留行数保持不变。这表明持续的插入和修剪写入放大：行被插入、索引、写入WAL，然后被修剪。 可能原因 SQLite反馈日志接收器安装了全局TRACE默认设置：Targets :: new ( ). with_default ( Level :: TRACE ) 这默认情况下保留所有目标在TRACE级别，包括依赖/内部日志和大型原始协议有效载荷。 提议的修复 保持反馈日志启用，但缩小默认保留的内容： 不要为SQLite反馈日志接收器使用全局TRACE。 降低或提高低价值依赖噪音的阈值，特别是target=log、hyper_util、tokio-tungstenite内部、inotify垃圾邮件和低级OpenTelemetry SDK日志。 避免默认情况下保留完整的原始WebSocket/SSE有效载荷。 取而代之，存储摘要：事件种类,