关于 Codex 日志高频写盘问题的解决方案

发布于 2026-07-06 11:42:31

## 事件起因

2026年6月，有用户报告 Codex Desktop / app-server 存在日志落盘缺陷。官方文档指出，可以通过 `RUST_LOG` 控制 Rust 日志级别（如 `error/warn/info/debug/trace`）。然而，在多个 openai/codex issue 中大家发现：即使设置了 `RUST_LOG=warn`，`~/.codex/logs_2.sqlite` 依然会写入大量 `TRACE` 记录。([OpenAI开发者](https://www.nodeseek.com/jump?to=https%3A%2F%2Fdevelopers.openai.com%2Fcodex%2Fenvironment-variables))

此外，有用户测试过设置 `[analytics] enabled = false`，但也无法阻止本地 SQLite 持续写入 TRACE 日志。([GitHub](https://www.nodeseek.com/jump?to=https%3A%2F%2Fgithub.com%2Fopenai%2Fcodex%2Fissues%2F30988))

实测发现，截至 2026/7/4，Codex Windows Desktop 版本仍有此问题：
![5sLcL32IP9I3rsoSG07suGYFoKHF2rsW.webp](http://pic.zhso.org/2026/07/06/831e09872868.webp)

目前的处理思路是：**先止损，等待官方更新修复**。

## 推荐方案：为 `logs` 表添加 SQLite 触发器 (Trigger) 忽略写入

这种方法比直接将文件设为只读更稳妥，因为它不会引发应用层面的插入报错，只是让 SQLite 层面直接忽略这些日志的插入。

在 Windows PowerShell 中依次执行以下命令：

```powershell
# 1. 彻底退出 Codex
Get-Process | Where-Object {
$_.ProcessName -like "*codex*" -or $_.Path -like "*OpenAI.Codex*"
} | Stop-Process -Force -ErrorAction SilentlyContinue

# 2. 备份 logs_2.sqlite
$dir = Join-Path $env:USERPROFILE ".codex"
$db = Join-Path $dir "logs_2.sqlite"
$bak = Join-Path $dir ("logs_2.sqlite.bak-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
Copy-Item $db $bak -ErrorAction SilentlyContinue

# 3. 清空旧日志、压缩数据库、阻止后续日志插入
@'
import sqlite3, pathlib

p = pathlib.Path.home() / ".codex" / "logs_2.sqlite"
con = sqlite3.connect(str(p))

# 清旧日志
con.execute("DROP TRIGGER IF EXISTS block_log_inserts")
con.execute("DELETE FROM logs")
con.commit()

# 压缩主库
con.execute("VACUUM")
con.commit()

# 截断 WAL
con.execute("PRAGMA wal_checkpoint(TRUNCATE)")
con.commit()

# 阻止后续日志插入
con.execute("""
CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
SELECT RAISE(IGNORE);
END;
""")
con.commit()

con.execute("PRAGMA wal_checkpoint(TRUNCATE)")
con.close()

print("done: logs cleared, trigger installed")
'@ | python -
```

随后重新打开 Codex，并检查文件大小：

```powershell
Get-Item "$env:USERPROFILE\.codex\logs_2.sqlite*" | Select-Object Name, Length, LastWriteTime
```

如果修复成功，`logs_2.sqlite-wal` 不应该再持续高频增长。

## 验证：检查近 60 秒是否仍在写 TRACE

```powershell
@'
import sqlite3, pathlib

p = pathlib.Path.home() / ".codex" / "logs_2.sqlite"
con = sqlite3.connect(f"file:{p}?mode=ro", uri=True)

for row in con.execute("""
SELECT level, COUNT(*) AS rows
FROM logs
WHERE ts >= CAST(strftime('%s','now') AS INTEGER) - 60
GROUP BY level
ORDER BY rows DESC;
"""):
print(row)

con.close()
'@ | python -
```

如果输出为空，或者没有大量的 `TRACE`，就说明 trigger 已经生效。

## 如何撤销此临时解决方案

等 Codex 官方修复后，可以删除触发器：

```powershell
@'
import sqlite3, pathlib

p = pathlib.Path.home() / ".codex" / "logs_2.sqlite"
con = sqlite3.connect(str(p))
con.execute("DROP TRIGGER IF EXISTS block_log_inserts")
con.commit()
con.close()

print("trigger removed")
'@ | python -
```

## 不建议的操作

不要仅仅修改配置文件：

```toml
[analytics]
enabled = false
```

也不要仅仅设置环境变量：

```powershell
$env:RUST_LOG="warn"
```

这些操作大概率无济于事。现有报告确认，即使关闭 analytics 并设置 `RUST_LOG=warn`，`logs_2.sqlite` 仍可能继续写入 `TRACE`。([GitHub](https://www.nodeseek.com/jump?to=https%3A%2F%2Fgithub.com%2Fopenai%2Fcodex%2Fissues%2F30780))

此外，**切勿将完整的 `logs_2.sqlite` 直接上传到 GitHub Issue 或论坛中**。官方 issue 中的用户特别提醒，该文件可能包含你的会话内容、本地文件路径等敏感隐私信息。([GitHub](https://www.nodeseek.com/jump?to=https%3A%2F%2Fgithub.com%2Fopenai%2Fcodex%2Fissues%2F30236))

**总结：目前最实用的方法是添加触发器（trigger）阻断 `logs` 表的数据插入；虽然不能从根本上解决 bug，但能立竿见影地停止高频写盘。**

关于 Codex 日志高频写盘问题的解决方案

评论（1）