31KB/秒的写入不算很大量的写入的。

之前让cc把日志写入的功能禁掉了（虽然还没有查有用没） ^-^

那是因为我没东西在跑，问题是 trace 日志占比依然巨大，和 github 上 issue 建议不一致

升级到142了吗 说是修复了 我看我的好像是正常了

你是用 cli 还是 app? 我是用 app 测的，而且 app 的内置 cli 版本就是0.142.0

我没升级，直接用的sqlite拦截器，直接拦截写入

大惊小怪的,你随便访问下网站的读写都不止这个速率了有更新殿下更新就好了

现在好像就只有 trigger 这个方案了，要不链到内存或者机械硬盘，我是秉持着别乱用野路子动官方的设定没搞

咦 好像和你差不多 但是比之前应该是好多了？

修复了，但是只修复了 一部分，说是143版本才能修复

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

有更新CLI吗？要把CLI也更新到142，我这里升级前升级后对比明显好了不少，但我看您的这个写入速度其实不高，就正常水平

全部都更新一下试试，目前看着还好。

我刚查了好像也是存在高频写入的问题

反正 github 上的 issue 还是 open。实际接收不到只能加 trigger

这个好像拦截掉了所有log

看看我的

OpenAI的codex log数据库写入trace日志的问题仍然未解决。
临时方案：
执行sql：
CREATE TRIGGER codex_drop_trace_logs
BEFORE INSERT ON logs
WHEN NEW.level = 'TRACE'
BEGIN
SELECT RAISE(IGNORE);
END;