各位好，我是果叔。
昨天看到一个挺吓人的消息，说 Codex 的本地日志可能存在一个写入 bug，会持续往 SSD 里写大量数据，严重一点甚至会影响硬盘寿命。
我第一反应其实不是慌。
我第一反应是：这会不会又是一个被放大的技术圈小惊吓？
因为正常来讲，Mac 的 SSD 没那么脆。你日常用电脑，系统本来就会有 Swap，会有缓存，会有各种日志写入。尤其现在内存压力一上来，macOS 拿 SSD 当交换空间也不是什么新闻。真要说“写入会损耗 SSD”，这句话当然对，但很多时候它也容易被讲得太吓人。
问题是，我这台电脑的用法不太正常。
它基本是 24 小时开着的。我会长期挂很多自动化任务，Codex 也经常不是开一下就关，而是作为一个常驻工作层跑在机器里。这个前提一变，事情就不能只靠感觉判断了。
所以我还是认真查了一遍。
真正吓人的不是文件大小，而是写入速度
我先去看了 Codex 本地的数据目录。
在我这台机器上，Codex Desktop 默认用的是：
/Users/zixuansmac/.codex里面有一个比较关键的文件：
~/.codex/logs_2.sqlite这个文件本身看起来不算离谱，大概 1.8GB 左右。它旁边的 WAL 文件在采样时也有几百 MB。单看文件大小，你很容易得出一个结论：也还好嘛，不就是一个本地 SQLite 日志库。
但这里有个坑。
SQLite 这种东西，不是文件最后有多大，就代表它只写了多少。一个文件可以不断被写入、更新、覆盖、刷 WAL，最后留在磁盘上的体积不大，但过程中的写入量很大。
这就像你每天擦黑板写字，最后黑板上只有几行字，但你一天其实写了几百页。
我真正去测的是运行中的 Codex app-server 进程写了多少。
结果有点离谱。
两分钟左右的采样里，进程写入量大概是 846MB，折算下来约 7.0MB/s。逻辑写入也有 4.9MB/s 左右。这个速度如果只是偶尔出现，那还好。但如果你像我一样 24 小时挂着跑，年化下来大概就是 222TB 写入。
222TB 是什么概念？
它不一定立刻把 SSD 干废。SSD 有冗余，有磨损均衡，也不是写到某个数字就马上死。但是对于一台日常工作机来说，这个量已经不是“可以忽略的小日志”了。
我顺手看了一下 SMART 数据。
我这台内置 500GB Apple SSD，Data Units Written 已经到了约 54.8TB，健康状态还没问题，Percentage Used 大概 2%。所以现在不是“硬盘马上要坏”，不是那种恐怖故事。
但它提醒我一件事：如果你长期把 Codex 当常驻自动化工作台来用，这个写入问题就值得处理。
普通用户先别慌，真正该关心的是长期常驻的人
我觉得这件事最容易被写歪。
一写 Codex 写 SSD，大家就容易进入两个极端。
一种是恐慌：完了完了，我是不是用了几天 Codex，SSD 就废了。
另一种是轻视：不就是日志嘛，SSD 哪有那么容易坏。
我自己的判断是，这两种都不太对。
如果你只是每天打开 Codex 用几个小时，写点代码、修点 bug、问点问题，用完就关，那我觉得大概率不用太焦虑。你应该更关心的是项目有没有备份、重要文件有没有版本管理，而不是盯着 SSD 写入数字吓自己。
但如果你的用法像我这样，电脑 24 小时开着，Codex 也经常挂着跑自动化、跑后台任务、跑长流程，那就不一样了。
因为这里的关键不是 Codex 会不会写日志。
所有软件都会写日志。
关键是它有没有在某个场景下持续、高频、没必要地写一类本地日志。这个差别很大。前者是正常软件行为，后者就是会把一个小问题变成长期磨损。
说人话就是：这事不太适合拿来制造大众恐慌，但很适合提醒重度用户检查一下自己的机器。
尤其是我们这种拿本地电脑当半个服务器用的人。
我先做的低风险处理，不是直接上黑魔法
这里要先讲一个边界。
如果你想低风险处理，第一优先级不应该是直接去改 SQLite 数据库。
更稳的方式，是先关掉 analytics。
在 Codex 的配置文件里加：
[analytics]
enabled = false配置路径通常是：
~/.codex/config.toml然后完整重启 Codex，再重新采样写入。
为什么我把这个放在前面？
因为 Codex app-server 本身是以 --analytics-default-enabled 方式启动的，但从命令帮助和本地验证看，配置里的 [analytics] enabled = false 是更像“官方低风险开关”的方案。它比你直接去 SQLite 里加 trigger 要温和得多。
如果你不是很确定自己在干什么，我建议先从这里开始。
不要一上来就复制网上某个命令往 SQLite 里怼。
这个世界上很多电脑问题，不是原问题搞坏的，是修问题的人太兴奋搞坏的。
我后来用了一个更硬的办法，但它有代价
因为我这台机器的写入确实比较夸张，而且我明确知道自己要阻断的是 logs_2.sqlite 里的 logs 表写入，所以我后来用了一个更硬的方式：给 SQLite 加一个 trigger，直接忽略对 logs 表的 insert。
实际命令大概是这个形态：
sqlite3 ~/.codex/logs_2.sqlite "PRAGMA busy_timeout=10000; CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"这个命令做的事很简单粗暴。
当 Codex 想往 logs 表插入新日志时，SQLite 触发器直接让这次插入被忽略。
我执行之后又重新测了一次。
结果很明显。
logs 表的 max(id) 不再增长，logs_2.sqlite、logs_2.sqlite-wal、logs_2.sqlite-shm 的体积变化也都是 0。进程写入从之前约 846MB / 120 秒，降到约 29MB / 120 秒，下降大概 96.5%。
换成年化估算，从 200 多 TB 级别，降到了大约 7.7TB 到 10TB 这个量级。
这个就正常多了。
不是说 7TB 一定精确，也不是说每台机器都一样。这个只是我这台机器、我这个使用方式、我这次采样窗口里的估算。但它至少说明：高写入确实主要和这张日志表有关，阻断之后效果也非常明显。
不过，这个办法有代价。
代价就是：你本地的 Codex 日志会缺失。
以后 Codex 如果崩溃、异常、某个本地问题需要追查，你可能就少了一部分诊断材料。尤其是以后 Codex 自己升级、迁移、改本地数据库结构时，这种 trigger 也可能带来一些不可预期的小麻烦。
所以这个方案适合什么人？
适合你明确知道自己在做什么，明确知道风险，也明确知道怎么回滚。
不适合一看见“保护 SSD”四个字就复制粘贴。
回滚命令一定要放在旁边
我做这类操作有一个习惯：只要是会改本地数据库行为的命令，回滚命令一定要贴在旁边。
不然等你真的遇到问题，早就忘了自己当时干了什么。
这个 trigger 的回滚命令是：
sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;"如果你还想检查当前有没有 trigger，可以查：
sqlite3 ~/.codex/logs_2.sqlite "SELECT name, sql FROM sqlite_master WHERE type='trigger';"还有一点很重要。
删除 Codex App 本体，不一定能清掉这个 trigger。因为用户数据在：
~/.codex你卸载 /Applications/Codex.app，通常不会自动删掉这个目录里的 SQLite 数据库。
所以如果你真的要恢复，优先用 DROP TRIGGER，不要以为“重装软件”就一定能解决。
当然，如果你要彻底重置 Codex 本地状态，也可以把整个 ~/.codex 备份走再重建。但那会影响 auth、config、skills、sessions、memory、plugins 和各种本地状态。这个动作就大很多了，不建议当成普通修复手段。
这件事真正提醒我的，不只是 SSD
说实话，这个问题最有意思的地方，不是“Codex 会不会写坏 SSD”。
真正有意思的是，AI 工具正在从一个你偶尔打开的应用，变成一个长期在线的本地工作系统。
以前我们用软件，很多软件是人驱动的。你打开，点几下，关掉。它的后台行为就算有，也有限。
但现在不一样了。
Codex、Claude Code、各种 agent、各种自动化脚本，越来越像一群常驻在你电脑里的小工人。它们会读文件、写文件、开数据库、记日志、跑任务、生成缓存、保存状态。
一旦你把它们变成 24 小时工作流，很多原本不明显的小成本都会被放大。
几 MB/s 的写入，放在一分钟里没感觉。
放在一天里，就变成几百 GB。
放在一年里，就变成上百 TB。
这就是自动化的反面。
自动化不是没有成本。自动化只是把人的动作换成机器的持续动作。机器不会喊累，但硬盘、电量、网络、API、Token、数据库，都会默默记账。
所以我越来越觉得，AI 时代真正重要的能力，不只是会不会 prompt，也不是会不会装一个新工具。
更重要的是，你要知道这些工具在你的机器里到底干了什么。
它写了什么。
它存了什么。
它有没有在你看不见的地方持续消耗资源。
它出了问题以后，你能不能回滚。
这才是长期用 AI 工具的人，慢慢要补上的基本功。
我的建议很简单
如果你只是普通使用 Codex，每天几个小时，不用太焦虑。先正常用，别被技术圈的惊吓带着跑。
如果你跟我一样，把 Codex 当成半个自动化工作台，机器 24 小时开着，那建议你至少做三件事。
第一，看一下 ~/.codex/logs_2.sqlite 和 WAL 文件是不是异常大。
第二，采样一下 Codex app-server 的实际写入速度，不要只看文件大小。
第三，先尝试低风险的 analytics 关闭方案。如果写入还是很夸张，再考虑 SQLite trigger 这种硬停方案，而且一定要把回滚命令记下来。
这事不神秘，也不用玄学。
就是一次很典型的 AI 工具本地化之后的副作用：工具越来越强，常驻越来越多，后台状态越来越复杂，然后一些原本不起眼的日志和数据库行为，开始真的影响你的硬件和工作环境。
我还是那句话。
AI 工具可以放大生产力，但它不会自动替你承担系统成本。
你让它 24 小时干活，就要偶尔掀开盖子看一眼：它到底在怎么干活。
别等 SSD 真开始报警了，才想起来自己电脑里还有这么一个长期加班的小家伙。
有所保留地说，今天这个坑，我先替大家踩了一脚。
如果你也是重度 Codex 用户，尤其是把 Mac 当服务器跑自动化的那种，建议你抽空看一下自己的写入情况。
不一定有问题。
但看一眼，心里有数。
这就够了。
