Codex重连，卡顿，CPU占用过高问题新用户解决攻略

作者本人是Claude的用户，最近被Codex折磨的够呛，原因在于这个B软件，从一下载打开后就开始CPU超高占用嗡嗡嗡个不停，外加上动不动就reconnection。

我一度把所有的锅，都当成了是codex的锅。中途卸载不打算用Codex了，然而今天又心血来潮准备攻克一下这个BUG，结果意外让我发现了两个问题的快速解决方法，重连问题来自youtuber或者说很多小红书和网上帖子也有重连的解决办法。

但，一直没想到居然连接和高CPU占用居然是俩问题！

今天，一顿探索几个小时，找了N个大模型帮我一起找问题。最后所有模式都不行，依旧嗡嗡嗡的占用15-20%的CPU。

无意之间，我打开了任务管理器，突然发现，这个CHATGPT桌面版本中chatgpt占用比例居然是大头，codex从cpu占用和内存上其实是正常的。但是我每打一个字符都卡的一笔。最后通过2个小时的不屑努力，终于解决了！！！

问题根源，居然是chatgpt自己！！！新人下载codex的时候推荐的一些AI自动程序，给自己程序死循环了。

Codex Desktop 踩坑记录：反复 Reconnecting、高 CPU、输入卡顿，最后发现是两个独立问题

问题一：模型连接反复 Reconnecting

症状

使用 Codex 时经常出现：

Reconnecting

具体表现包括：

1. 回复生成到一半断开；
2. 长时间停留在重连状态；
3. 相同请求反复尝试；
4. 网络看起来正常，但 Codex 连接不稳定；
5. 其他使用普通 HTTPS 的软件没有明显异常。

原因判断

在我的环境中，Codex 默认模型 Provider 使用的 WebSocket 传输不稳定。

这不一定意味着 OpenAI 服务本身异常，也可能和本地网络、代&理、防火墙、运营商链路或客户端兼容性有关。仅凭 Reconnecting 很难判断具体是哪一层，但可以通过切换传输方式验证。

我的处理方法是新建一个自定义 Provider，继续使用 OpenAI 登录认证和 Responses API，但明确关闭 WebSocket 支持，让 Codex 改用 HTTP/SSE 流式连接。

解决方法

打开用户级配置文件：

%USERPROFILE%.codexconfig.toml

将默认 Provider：

model_provider = "openai"

改为：

model_provider = "openai_http"[model_providers.openai_http]name = "OpenAI HTTP"wire_api = "responses"requires_openai_auth = truesupports_websockets = false

修改后完全退出并重新打开 Codex。

其中：

1. wire_api = “responses”：继续使用 Responses API；
2. requires_openai_auth = true：继续使用 OpenAI 账号认证；
3. supports_websockets = false：不再使用 Responses API 的 WebSocket 传输。

OpenAI 官方配置文档确认，model_provider 可以指向自定义 Provider；wire_api 当前支持 responses，而 supports_websockets 用来声明该 Provider 是否支持 Responses API WebSocket 传输。OpenAI Codex Configuration Reference

需要注意：这是我当前网络环境中的有效规避方案，不代表所有出现 Reconnecting 的用户都必须关闭 WebSocket。如果 WebSocket 在你的网络中正常，默认配置通常更合适。

或者你直接把这张图丢给CODEX让它帮你配置【这个攻略来自youtuber】，因为我今天解决的其实不是reconnection，应该是重连问题之前就解决好了，一直的bug都是高CPU占用卡顿问题。

问题二：Codex 一打开就高 CPU、严重卡顿

只要打开 Codex，电脑就会明显卡顿；关闭 Codex 后，系统马上恢复正常。

任务管理器中的表现

当时可以看到：

1. ChatGPT/Codex 进程组占用约 2 GB 内存；
2. ChatGPT.exe 主进程持续占用约 13% 总 CPU；
3. codex.exe 本身占用并不高；
4. 关闭 Codex 后，CPU 和系统响应立即恢复；
5. 每次重新打开，问题都会重新出现。

进一步采样发现，异常主进程在 5 秒内消耗了 3.69 秒 CPU，相当于持续占用一个逻辑核心，并不是普通的内存缓存。

真正原因

最终在自动化任务目录中找到了问题：

%USERPROFILE%.codexautomationsautomationautomation.toml

这是 Codex 新手引导推荐创建的“工作日晨间简报”任务，其关键配置是：

name = "工作日晨间简报"status = "ACTIVE"target_thread_id = "current"

问题出在：

target_thread_id = "current"

current 是占位值，不是有效的线程 UUID，但任务却被直接设置成了启用状态。

因此，Codex 每次启动后都会进入下面的循环：

读取目标线程→ thread ID 无效→ 尝试恢复会话→ session ID 无效→ 再次重试

日志证据

日志中持续出现：

invalid thread idinvalid session idheartbeat_automation_resume_failedmain_thread_jank_snapshot

排查时已经累计记录：

1. invalid thread id：430 次
2. invalid session id：430 次
3. heartbeat_automation_resume_failed：215 次
4. 主线程卡顿记录：22 次

它大约每隔两三秒就重试一次，形成了本地后台忙循环。

这和前面的模型连接 Reconnecting 不是同一个问题：

1. 模型 Reconnecting：网络传输层反复重连；
2. 晨间简报 Bug：本地定时任务反复恢复一个无效线程。

两者都表现为“不断重试”，但需要分别解决。

高 CPU 的解决方法

最安全的处理方式是暂停这个损坏的任务，不必删除账号、登录状态或其他配置。

将：

status = "ACTIVE"

改为：

status = "PAUSED"

也可以直接在 Codex 的定时任务管理界面中停用“工作日晨间简报”。

我最后通过 Codex 的任务管理接口将其暂停，保留任务内容，没有直接删除。

停用后的结果

处理后再次验证：

1. 6 秒内新增恢复错误：0
2. 主进程 CPU 消耗：0
3. 内存从约 1 GB 降至约 338 MB
4. 输入和界面操作立即恢复流畅

最直观的感受就是：电脑终于安静了。

如何区分这两个问题

如果是模型连接问题

通常表现为：

Reconnecting

同时伴随：

1. 回复生成中断；
2. 网络请求重新连接；
3. 模型长时间没有输出；
4. CPU 不一定持续跑高。

可以尝试检查网络、代&理和防火墙，或者测试关闭模型 Provider 的 WebSocket 支持。

如果是本地自动化死循环

通常表现为：

1. 打开 Codex 后 CPU 持续不降；
2. 即使没有发送消息也会卡；
3. 关闭 Codex 后马上恢复；
4. 日志反复出现无效线程、会话恢复失败或 heartbeat 错误。

此时应该优先检查：

%USERPROFILE%.codexautomations

尤其留意：

status = "ACTIVE"target_thread_id = "current"

正常的线程 ID 应该是类似下面这样的 UUID，而不是 current：

019fxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

这次排查得到的经验

1. Reconnecting 不一定等于服务器故障，也可能是 WebSocket 在当前网络环境中不稳定。
2. 持续稳定的高 CPU，通常意味着程序内部存在轮询、恢复或重试循环。
3. ChatGPT.exe 高占用不等于 codex.exe 后端有问题，需要区分具体进程。
4. 不要一上来就清空全部缓存、删除登录状态或重装系统。
5. 先检查日志中的重复事件，重复数百次的同类错误往往就是根因。
6. 官方推荐创建的任务也可能因为占位值没有正确替换而生成损坏配置。
7. 修改配置前建议备份 config.toml 和对应的自动化任务文件。

最终使用的两个解决方案

解决模型 Reconnecting

model_provider = "openai_http"[model_providers.openai_http]name = "OpenAI HTTP"wire_api = "responses"requires_openai_auth = truesupports_websockets = false

解决高 CPU 和输入卡顿

暂停损坏的晨间简报任务：

status = "PAUSED"

并检查是否存在：

target_thread_id = "current"

总结

这次遇到的不是单一故障，而是两个重试循环叠在了一起：

1. 模型连接层通过 WebSocket 反复 Reconnecting；
2. 本地自动化任务因为无效的 target_thread_id 反复恢复失败。

前者通过切换到不使用 WebSocket 的 HTTP Responses Provider 得到改善；后者通过暂停损坏的“工作日晨间简报”任务彻底解决。

如果你也遇到 Codex Desktop 反复重连、高 CPU、内存上涨、输入卡顿，建议不要只盯着网络或项目索引。分别检查模型传输方式和自动化任务状态，可能会更快找到真正原因。

【最后一顿排查后，居然指向了一个叫工作日晨间简报的，死循环程序】直接给我看懵了，后来打开细节一看，又想起来了，这应该是codex刚下载的时候chagtgpt推荐的什么东西点了一下配置，然后就不知道了。之后就一直偷偷死循环bug。。。

【最后我给一个小白可以直接给CODEX输入的指令自动化解决这个问题：D】

请帮我修复 Codex Desktop 的两个问题：

1. 对话经常显示 Reconnecting，疑似默认 WebSocket 模型连接不稳定。

2. 打开 Codex 后持续高 CPU、内存上涨和输入卡顿，疑似损坏的定时任务在反复恢复无效线程。

请按以下要求执行，不要只告诉我 操作步骤：

一、操作前备份

1. 备份 %USERPROFILE%.codexconfig.toml。

2. 检查 %USERPROFILE%.codexautomations 下的定时任务。

3. 修改任何自动化文件前先创建备份。

4. 不要删除 auth.json、登录信息、会话记录或其他正常任务。

5. 不要修改注册表、Windows 系统设置、代&理设置或其他软件。

二、处理 Reconnecting

检查用户级配置：

%USERPROFILE%.codexconfig.toml

保留原有其他配置，将模型 Provider 设置为：

model_provider = “openai_http”

确保配置中存在且只存在一份以下内容：

[model_providers.openai_http]

name = “OpenAI HTTP”

wire_api = “responses”

requires_openai_auth = true

supports_websockets = false

不要覆盖其他无关配置，不要把 Provider 配置写到项目级 .codex/config.toml。

三、处理高 CPU 定时任务

检查 %USERPROFILE%.codexautomations 下所有启用的任务。

如果发现同时满足以下条件的任务：

- status = “ACTIVE”

- target_thread_id = “current”

说明它引用了无效的线程占位值。

优先使用 Codex 的定时任务管理功能将该任务暂停；不要删除任务。暂停后应为：

status = “PAUSED”

如果无法使用任务管理功能，再在已备份的前提下修改对应的 automation.toml。

特别检查名为“工作日晨间简报”的任务。

四、验证

完成后请验证：

1. config.toml 仍是有效的 TOML 文件。

2. model_provider 已经是 openai_http。

3. supports_websockets 已经是 false。

4. 损坏的定时任务已经是 PAUSED。

5. 不再新增 invalid thread id、invalid session id 或 heartbeat_automation_resume_failed 错误。

6. 对比处理前后的 ChatGPT.exe 和 codex.exe CPU、内存占用。

最后用中文告诉我：

- 修改了哪些文件；

- 备份文件在哪里；

- 暂停了哪个任务；

- 验证结果；

- 是否需要完全退出并重新打开 Codex。

执行范围严格限制在当前用户的 .codex 配置和 Codex 自己的任务管理功能中。

希望你的问题顺利解决哦！