花了4小时、烧了7%的周Token，我终于搞懂了Codex的网络沙盒

补档说明

这篇记录的是我开通Plus之后遇到的一次真实故障排查经历。写作时间在事件发生后不久。

开通Plus之后，我用Codex跑了一段时间，一直挺顺的。直到有一天晚上，我更新了客户端。

然后，会话里API的网络就断了。

具体来说，是Codex Desktop的exec沙盒——那个用来执行代码的环境——完全连不上网。DNS解析失败，curl报Could not resolve host，ping报Unknown host。

但奇怪的是，浏览器里的Codex插件网络正常。

同一个工具，两条网络路径，一条通，一条断。

我一开始以为是自己改了什么配置，于是开始排查。

第一阶段：改配置。

我打开~/.codex/config.toml，加了一行network_access = true。没用。

改sandbox_mode = "bypass"。还是没用。

第二阶段：改环境变量。

我设了代理变量，心想是不是网络环境的问题。依然没用。

第三阶段：直接改全局状态文件。

我开始动~/.codex/.codex-global-state.json，把所有networkAccess都改成true。

然后我发现一个奇怪的现象——当前正在跑的线程还是断网，但新建的线程网络通了。

有戏。

但高兴了没一小会儿，当我再新建了一个线程的时候，全部又断了。全局污染，一个都通不了。

后来我发现，.codex-global-state.json 是运行结果，而不一定能有效配置。

第四阶段：切Full Access。

我被逼到这一步——切换到完全访问权限，绕过沙盒限制。

网络终于恢复了。

但随之而来的问题是，多个会话开始报 403 错误，于是，又查，发现切换Full Access需要（推荐）重新登录，遂重登、恢复。

到这个时候，我已经花了4个小时，烧掉了周额度的7%左右，丢了多个历史会话（历史会话的网络无法恢复）。

我开始复盘，怀疑自己是不是操作有问题。

然后我去了OpenAI社区论坛。

发现这不是我的问题——这是一个官方已知的Bug。

从2026年5月被报告，到8月还没有修复（截至发稿，我刚去试了一下）。

核心问题是：Codex的“线程启动器”在创建新线程时，没有读取当前全局配置，而是使用了过时的、被污染的默认策略。简单说，sandboxPolicy.networkAccess被错误地持久化为false，导致新建线程强制断网。

看到这个帖子的时候，我心情有点复杂——既松了口气（不是我菜），又觉得离谱（一个20美元/月的产品，这个Bug 至少 3个月了还没修）。

代价：

• 3小时排查时间
• 7%的周Token消耗
• 多个历史会话消失

收获：

• 简要掌握了Codex的网络沙盒机制、会话隔离设计、全局状态继承逻辑
• 确认了官方Bug的存在，不再怀疑自己的操作
• 获得了一个可靠的临时工作区方案：Full Access + 定期重置

给同样用Codex的朋友几个提醒：

1. 如果新线程突然断网，先检查环境变量CODEX_SANDBOX_NETWORK_DISABLED是不是被设为1。如果是，试试手动清理global-state.json中的sandboxPolicy.networkAccess。
2. 切换Full Access后如果出现403错误，检查~/.codex/auth.json，清理旧的登录凭证，或者干脆重新登录。
3. 不同认证模式下，会话存储空间存在隔离。切换模式后，部分历史会话可能不可见，但数据文件还在本地。
4. 如果频繁遇到网络污染问题，可以定期备份并重置~/.codex目录（不推荐，代价很高）。参考命令：

cp -r ~/.codex ~/.codex.backup.$(date +%Y%m%d)
rm -rf ~/.codex

5. 关注OpenAI社区论坛的Bug修复动态——有些问题，官方自己还没修。

回到那个老问题：到底值不值？

值。

虽然踩了坑、烧了Token、丢了会话，但Plus带来的能力提升是质的飞跃。免费版做不了的长流程自动化任务，Plus可以做；免费版额度撑不住的Agent模式，Plus可以跑；免费版无法操作的本地文件和浏览器，Plus可以接管。

但我还是想补一句：一个20美元/月的产品，不应该让用户花4个小时去排查一个官方已知状态的Bug，这个问题从5月被报告至今未修复，对用户来说，确实是一种信任损耗。

希望这篇记录，能帮到同样在纠结、或同样踩坑的你。

如果你也有类似的经历——欢迎留言。