我的“金子”消失了，花了几个小时我又把他找回来了

入口不见了，先别急着认定是网络

2026 年 10 月 21 日，我的 Mac ChatGPT（Powered by Codex & OWL，版本 26.1016.51333）出现了几个一起冒出来的问题：金子助手入口消失，远程电脑显示离线，界面还有红色提醒。iOS 端却还能用。

换不同网络出口时，网页入口的表现也有差异。看到这里，很容易直接想到地区限制、IP 风控，或者账号出了问题。但这几次观察只能说明不同条件下表现不同，不能证明具体原因。手机可用，也不能单凭这一点就认定 Mac 的问题一定出在网络。

我把注意力转回了自己改过什么。之前为了缓解 Codex 反复「重新连接」，我配置过一个名为 openai_http 的模型提供商，并把 supports_websockets 设为 false。这里的「提供商」可以先理解为：Codex 用哪一套设置去连接模型。

这件事以前写过一篇切回 HTTP 的教程。现在再看，不能因为它曾经用来处理重连，就把它当成长期开着也无需复查的通用修复。旧方案在当前版本中的适用性还需要重新核对，不建议直接照着旧文操作。

先查有没有任务在持续改配置

这次最值得先查的，不是 config.toml 里某一行该怎么删，而是谁还在后台维护这份配置。

本机 Codex 的只读检查报告显示，之前的强制配置任务仍然加载着。它是一个 macOS LaunchAgent，可以理解成登录后按规则运行的小任务：登录时执行，每 300 秒执行一次，还监听 config.toml 和 app.asar 的变化。

如果只手动撤掉配置，却让这个任务继续运行，后续触发时就存在被写回的风险。因此我先让 Codex 看清任务和脚本的实际内容，再决定撤回范围，而不是不断重复编辑同一份文件。

这里有两个细节必须说清。检查报告说，这个任务没有修改系统代理，也没有修改 app.asar；监听文件变化和修改应用文件是两回事。另一个细节是，这次本机任务的触发方式，不等同于旧教程目前公开页面中的候选方案。公开页面写的是每 30 分钟检查、没有文件监听，不能拿那一版描述代替本机实查结果。

所以，如果以前装过「自动修复」「配置守护」之类的小脚本，排查时值得多问一句：它现在还在运行吗，什么时候触发，究竟写哪些字段？先弄清这个，才能知道眼前的配置是不是稳定状态。

禁用模型 WebSocket，不等于关掉整个 App 的通信

supports_websockets = false 的名字很容易让人误会，以为这是整个应用的 WebSocket 总开关。

官方配置文档把它放在 model_providers.<id> 下面，描述的是这个模型提供商是否支持 Responses API 的 WebSocket 传输。它的作用范围是模型提供商的这一种传输方式，不能据此推导出金子入口、远程电脑连接或整个 App 都被统一切换了通信方式。查看官方配置说明

还有一个常见误会：「切回 HTTP」是不是把加密关掉了？这次配置仍然通过 HTTPS 加密通信，并不是改成明文 HTTP。openai_http 是当时使用的提供商名称，名称里有 HTTP，不能据此判断连接是否加密。

我能确认的是，撤回这一组强制配置后，应用表现恢复了。至于入口消失和电脑离线究竟涉及哪一段通信，这次没有逐段测出来，不能把所有现象都解释成「WebSocket 被关了」。

这次怎么撤回，又看到了什么

我让本机 Codex 做的是一次可以回滚的小范围撤回：先备份配置与脚本，卸载并禁用这一个守护任务，再参考历史备份，只移除强制提供商相关字段，保留其他配置。

执行报告记录，随后观察了 310 秒，没有发现配置被写回。这个时间超过了原来的一个 300 秒定时间隔，能说明观察期间没有再次写回；它不能替代下一次登录、应用更新后的长期检查。

这轮操作没有修改代理、TUN、DNS、防火墙、账号、认证信息或 app.asar。也没有为了让界面恢复，把整份配置重置掉。

随后，我完全退出并重新打开应用，金子助手入口恢复。北京时间 2026 年 10 月 21 日 23:56:02，远程环境查询确认这台 Mac 已连接、已附加到任务，并且已有授权。之后我也确认，红色提醒消失，使用恢复正常。

这个过程给了我一个很有用的排查方向，但还不是严格的对照实验。停用任务、撤回配置和重启应用是连着做的，没有逐项单独复现，也没有排除服务端状态、时间变化等其他因素。因此，准确的说法是：这组撤回操作后恢复了；不能说已经证明所有故障都是 HTTP 引起的，更不能承诺别人照做也一定恢复。

新对话能用，为什么旧对话还找不到提供商

应用恢复后，旧 Codex 对话又留下了一个问题：

Model provider 'openai_http' not found

但新建聊天不报这个错。这时如果只盯着当前配置，很容易以为没删干净，然后继续删设置。

我提供给助手复核的 config.toml 能正常通过 TOML 解析。递归检查结果中，已经没有 model_provider、model_providers 或 openai_http；负责复核的助手也没有修改这份上传文件。这至少说明，「当前这份文件还有旧字段」不能直接拿来解释报错。

到了 10 月 22 日，接续前对原来置顶的 12 个旧对话做了回复检查，均出现了同一个 openai_http 找不到的错误。这个结果把问题缩小到了这批旧对话的继续回复环节。官方 App Server 文档中的线程信息也有 modelProvider 字段，但字段的存在并不能代替对具体会话状态的检查。这次没有逐个查明旧会话内部如何保存、如何加载提供商，也没有验证原位修复的方法。查看官方线程示例

因此，这里没有一个经过本次验证的「原位修复旧对话」按钮，也不能保证 fork 一下就能解决。我选择先保留旧会话，不把直接修改数据库、历史文件或重新加回强制配置，当成这次接续工作的办法。

12 个新对话接上了，旧记录仍然保留

10 月 22 日，我先处理了原来置顶的 12 个受影响对话。助手通过应用支持的历史读取接口，提取能获取的任务背景、已完成事项和下一步，整理后放进 12 个同名新对话，保留原来的项目归属。接续时没有重新加回 openai_http，也没有修改底层会话数据库或原始历史文件。

新对话建好后，逐个打开并检查回复，让它们说明自己接手的任务和当前边界。12 个都通过了这一步。随后，我让助手按原顺序置顶新对话，把对应旧对话取消置顶，名字保持不变。这样，日常直接点置顶里的新入口，就能继续聊原来的事。

这里完成的是摘要接续。带过去的是可获取记录中的任务背景和限制，没有把每一轮消息、图片附件和工具输出完整搬过去；检查新对话能回复，也不代表里面尚未完成的业务已经做完。

旧对话不能继续回复，历史却仍有可读取的部分。这次接续就实际读到了旧记录。每个新对话都带了对应旧对话的引用，后面遇到摘要没写全的事，可以先通过应用支持的接口查旧记录，再决定怎么继续。能补回多少取决于记录是否可访问，读不到的部分要明确留下缺口，不能让助手假装记得。

我还碰到一个例外：以前专门写 AI 小白博客的长期对话，暂时没有定位到。找不到入口，不能据此断言历史已经丢失。我先依据现有网站规范和资料建了一个新的博客专用入口，确认它能正常回复。这个入口另行建立，没有恢复原博客对话的历史，也不计入前面那 12 个同名接续对话。

摘要里，要留下能继续做事的信息

这次接续也让我更在意交接摘要写了什么。只说「继续上次的任务」不够，新对话需要知道上次停在哪里、哪些决定已经确认，以及文件到底保存在哪。

原对话的引用：
这项任务要完成什么：
已经做完了什么，证据或文件在哪里：
哪些操作只是提出过，还没有执行：
当前未提交改动、正在运行的任务或发布状态：
已确认的限制，以及下一步只需要做的一件事：
哪些记录尚未读到，需要回查：

尤其是涉及代码和发布的工作，「已经改了」「已经提交」「已经上线」要分开写。文件路径、提交号和可访问的结果，比一句「前面差不多做完了」更有用。摘要里不需要放密码、密钥、完整邮箱或认证文件。

聊天接上以后，真正动手前还要核对代码目录与现有改动。新入口可能使用项目默认目录，旧任务却在另一个隔离目录里，不能把聊天背景接续当成代码也搬好了。这次也没有迁移或恢复自动化调度，更没有让新对话照着旧记录重新执行发布、付款或客户操作。

小白遇到类似情况，可以先查这六件事

1. 记下具体表现和版本。 哪个入口消失，哪台电脑离线，手机和新聊天是否可用。网络切换前后的差别也可以记，但先不要替它命名为风控或地区限制。
2. 盘点以前加过的自动任务。 先只读确认任务、脚本、触发频率和写入范围。尤其留意那些以前为了「省得反复手改」而安装的工具。
3. 把备份和撤回范围讲清楚。 配置、脚本、任务定义都要能找回。只处理确认相关的任务与字段，别把删除整个配置目录当成常规排查。
4. 撤回后确认不会马上写回。 按实际触发间隔留出观察时间；随后完全退出重开应用，重新检查原本出问题的入口和连接状态。
5. 分别验证新聊天与旧聊天。 配置能解析、应用入口恢复、新聊天能用、旧任务能续接，是四个不同的结果，不能只测一个就说全好了。
6. 先把工作接续起来。 保留旧记录，把摘要和原对话引用带入新入口，检查它能否回复、是否理解当前任务。再核对实际文件与未完成事项；需要进一步修旧会话时，单独核实当前版本支持的方式。

我会保留这次备份和排查记录，后面再遇到异常时，先核对自动任务与配置有没有变化。以前为解决一个具体问题加上的设置，应用更新后也值得重新检查；继续保留它，应该有当前版本下的验证结果支持。

参考与时间说明

• 先前的 HTTP 方案：用于交代历史背景，当前适用性待复核，不建议直接照做。
• OpenAI 配置参考：核对 model_providers.<id>.supports_websockets 的作用范围。
• OpenAI App Server 文档：核对线程信息中的 modelProvider 字段。

文中故障与恢复过程来自这次实际使用记录、本机执行报告及远程环境查询；10 月 22 日的接续进展来自新旧对话对应记录和逐个回复、置顶检查的结果。技术字段说明来自上述官方文档。时间统一使用北京时间，远程环境确认时间对应 UTC 2026-10-21 15:56:02。这里只公开必要的泛化字段，不展示私人配置内容和未脱敏截图。