照常打开Codex，输入第一条命令——擦，又断网了。
text
curl -I [目标网站]
# Could not resolve host
ping baidu.com
# Unknown host但同样的命令在Mac终端里跑得好好的，DNS解析正常，TLS握手成功，HTTP 200正常返回。
这不是我第一次遇到Codex沙盒断网了，之前有一次我花了3个小时，最后发现是global-state.json被污染，当时还不懂手工清理，切到了完全控制授权后才恢复。
我心想：“又来？那按老办法处理就行。”
但我错了，今天遇到的情况比上次复杂得多——是两个独立问题在同一时间段叠加在了一起。
先确认了系统网络没问题，问题锁定在Codex内部。
检查环境变量也干净，不是系统级注入。
打开~/.codex/.codex-global-state.json一看，sandboxPolicy.networkAccess又被错误地持久化为false。
这是Codex的一个已知问题：线程启动器在创建新会话时，没有读取当前全局配置，而是使用了过时的、被污染的默认策略。
我用了此前验证有效的方法——完全退出Codex，重命名global-state.json，然后重新打开。
这一步清除了被污染的状态后，沙盒网络恢复了，curl能正常返回了！
但在重启客户端后，新的问题出现了：Codex客户端本身连不上OpenAI服务器了。
界面空白，所有会话提示“无法加载”，客户端整体处于“离线”状态。
我在Codex里尝试发了一条普通会话，发现返回的不是JSON数据，而是一个完整的HTML页面。页面的核心内容是一个Cloudflare托管质询页面——Enable JavaScript and cookies to continue，以及一串Cloudflare的挑战参数。
Soga！那懂了，Codex客户端在访问api.openai.com时，被Cloudflare的安全屏障拦截了，这就不算是Codex的bug了，而是OpenAI侧的Cloudflare风控机制认为当前请求“可疑”，要求完成人机验证。
为什么会触发？结合今天的操作记录，诱因很可能是：频繁切换节点导致IP地址短时间内多次变化、频繁重启Codex客户端产生大量新会话和认证请求、清理状态文件后Codex用新的会话身份重新连接被Cloudflare视为“陌生设备”，再加上Codex客户端的TLS指纹和User-Agent与常规浏览器不同，风控等级更高。
Cloudflare把这些行为综合判定为“高风险”，于是返回了人机验证页面，而不是正常API响应。
解法：完全退出Codex，清理认证缓存，切换一个干净的VPN节点，重新打开。
全部恢复！
沙盒网络✅、客户端到OpenAI服务器✅、历史会话加载✅、新建会话网络策略✅。
这次踩坑让我对Codex的网络架构有了更深的理解，实际上我今天遇到了两个不同层面的问题：
- 内层：沙盒策略——Codex Shell沙盒网络被禁用，表现是curl DNS失败、localhost拒绝连接，解法是清理global-state.json或开启Full Access。
- 外层：网络路径——Codex到OpenAI服务器的连接被Cloudflare拦截，表现是API请求返回HTML人机验证页面，解法是切换节点+重启客户端。
这两个问题可能同时出现，也可能分别出现，今天我是先解决了内层，才发现外层还有个Cloudflare在等着我。
我一开始下意识地认为这是一个“老问题复现”，但实际上今天的状况比上次要复杂。
我修复了第一层，问题并没有完全消失，因为第二层在等着我。这两层问题的诱因或许是同一个：频繁切换节点（且节点本身网络也不是很稳定）+频繁重启客户端，但它们的机制则完全不同。
虽然花了2小时，但这个代价换来了三个清晰的认知：
第一，Codex的沙盒网络和客户端网络是两层独立的问题。沙盒通不代表客户端通，客户端通也不代表沙盒通——它们各自有各自的故障模式。
第二，Cloudflare风控是Codex用户的“隐藏成本”。它不是Bug，但会反复出现。当你频繁切换节点或重启客户端时，它就有可能冒出来。
第三，一次断网不一定只有一种原因。今天的经历证明，同一个表象可能由两个完全不同的原因叠加造成。如果只修一个，问题不会彻底消失。
如果你也遇到Codex突然断网，先别急着怪自己配置错了，也别急着怪OpenAI。按上面的顺序一步步排查，大概率能找到原因。
另外，建议尽量保持你的节点稳定，切换节点后完全退出Codex再重新打开。如果遇到Cloudflare问题，切换到稳定节点并重启Codex。