AI我遇到的问题
Codex 有一类很烦的小问题：更新完软件以后，连接又回到 WebSocket 优先。表现出来就是对话先重连几次 WebSocket，最后才回到 HTTP。这个配置我以前手动改过，但软件一更新，问题就会回来。
这种问题不能靠记性解决。你今天改了，下一次更新还是会忘。
不要继续手改一次。要把“我希望它保持什么状态”写成脚本，再让系统在更新后自动跑。
先判断谁会被覆盖
我先查了两件事。
- Codex 装在
/Applications/Codex.app，软件更新会替换应用包。 - 我要保住用户配置里的 provider，应用包里的打包代码只用来判断问题来源。
旧日志里出现过 transport="responses_websocket"。我想要的结果很简单：让 active provider 回到 HTTP，并明确告诉它不要走 WebSocket。
model_provider = "openai_http"
[model_providers.openai_http]
supports_websockets = false这个配置放在 ~/.codex/config.toml。只要它保持住，Codex 其它设置还可以照常改，不需要锁死整个文件。
我的做法
我做了两层。
一层是幂等修复脚本
脚本只负责一件事：检查 ~/.codex/config.toml，发现 provider 偏了就修回去。没偏就退出，不乱改其它字段。
我把脚本放在类似这个位置：
~/.codex/patches/codex-force-http-provider.sh这个脚本要做到三点。
- 重复执行不会把配置越改越乱。
- 真的写文件前先留备份。
- 只碰
model_provider和supports_websockets这类目标字段。
另一层是系统自动触发
脚本自己不会跑，所以我用 macOS 的 LaunchAgent 挂起来。启动项放在类似这个位置：
~/Library/LaunchAgents/com.yourname.codex-force-http-provider.plist触发条件我会设得保守一点：
- 登录时跑一次。
- 每 5 分钟检查一次。
- 监听
/Applications/Codex.app和~/.codex/config.toml，这两个地方变了就跑。
为什么用 LaunchAgent
普通定时任务只能隔一段时间扫一次。LaunchAgent 可以监听路径变化，Codex 更新包一变，系统就能触发脚本。
我不想让这个脚本常驻吃资源。它跑完就退出，下一次触发再跑。这个思路适合处理“软件更新后配置回退”这类问题。
- 先确认配置在用户目录，还是在应用包里。
- 能改用户配置，就别硬改应用包。
- 把目标状态写成幂等脚本。
- 用 LaunchAgent 或系统任务自动触发。
- 手动制造一次错误配置，确认脚本能修回来。
怎么验证
我不把“脚本写好了”当成完成。至少要验证四件事。
plutil -lint能通过，说明 plist 格式没坏。- 手动执行脚本，退出码是
0。 - 用
launchctl确认 LaunchAgent 已加载。 - 临时把配置改坏一次，看它能不能自动修回 HTTP provider。
最后这一项最关键。真实配置没偏的时候，脚本不改文件只能证明它没乱动；只有把配置临时改坏，才能证明它真的能修。
给 Codex 的提示词
如果你也遇到类似问题，可以直接让 Codex 按这个方向查。先让它拿证据，再让它写脚本。
我这台 macOS 上 Codex 更新后会把连接配置改回 WebSocket 优先。
请你先只读检查：
1. Codex 应用位置
2. ~/.codex/config.toml 里当前 model_provider
3. 是否已有 model_providers.openai_http
4. supports_websockets 当前值
5. 是否已有相关 LaunchAgent
确认证据后，帮我做一个幂等修复方案：
- 脚本只修 model_provider 和 supports_websockets
- 不要锁死整个 config.toml
- 写入前做备份
- 用 macOS LaunchAgent 在登录、定时、Codex.app 或 config.toml 变化时触发
- 安装后要手动跑一次
- 最后用临时坏配置验证能自动修回这套办法也能用在别的软件上。只要问题是“更新后本地配置被重置”，我就会先找目标状态，再写幂等修复，再让系统在正确时间触发。