Codex疯狂写入SSD的问题还在发酵
可能大家对于Codex烧坏SSD的事情已经有所耳闻，这几天推上又冒出两路新现场。一路偷硬盘容量，一路偷硬盘寿命。

博主 ​Glavo 发现自己的 .codex 文件夹占了 400 多 GB，调查了一圈。每次给 Codex 发图，它会把图片用 Base64 编码存进 .codex/sessions 的 jsonl；上下文压缩后，同一文件里把这些图片全部重新复制一遍；每次开子代理，又把父线程日志整份复制一遍。博主的一个会话发了 57 张图，触发 1052 次压缩，一个日志文件里塞了 42895 张图片副本，其中一张被复制了 1048 次。这个会话还拉起 142 个子代理，那几万张图又被乘了 142 轮，最后吃掉超过 400 GB。一张图，理论上能重复存储约 15 万次。​

简单说就是：常发图、常开子代理，.codex/sessions 可能悄悄涨到几十上百 GB，用户完全不知道。虽然 400GB 是个案，但机制摆在那了。

​另一路更隐蔽。博主 Alexey Fateev 的帖子说：Codex有个小毛病，会疯狂往电脑硬盘里写日志，可能把固态硬盘（SSD）写坏。​

具体讲：Codex 在后台不停记录极其详细的运行日志，写进电脑里的一个本地小数据库。写完一批又删掉，再写，再删……文件看起来不大（博主那边只有约 89 MB），但 SSD 最怕的就是这种不停擦写。

​严重到什么程度，博主发现日志编号已经跑到约 1.15 亿条——说明写了非常多次。​他给的解决办法：先彻底退出 Codex，在终端跑一条命令，让那个日志数据库“拒绝再写入”，等于临时把这个狂写日志的水龙头关掉。

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

再重新打开 Codex。​

我看完这两路帖子，把截图二丢给 Codex 让它按博主描述自检，真查出10多 GB 的重复压缩占用，清掉了。大家可以直接把图二博主的帖子截图发给 Codex，让它按同样描述检查。

#OpenAI[话题]# #AI[话题]# #Codex[话题]#
Codex疯狂写入SSD的问题还在发酵 可能大家对于Codex烧... http://xhslink.cn/o/AeVJvZBaBvc 复制这段文字，打开【小红书】一键直达笔记。
resolved_url: https://www.xiaohongshu.com/explore/6a6872210000000009037953
xhs_capture_status: success