Codex Desktop 在 macOS 空闲时主进程飙到 280% CPU 的排查记录

AIDO
, , , , ,
1

TL;DR

Codex Desktop 在 macOS 上有个挺离谱的现象：人没在用、对话也没在跑，主进程却能稳定吃到 250%+ CPU，而真正干活的 app-server 子进程只占 0.1%~1.3%。也就是说 CPU 不是花在模型推理或后端通信上，而是耗在桌面端自己那一层。下面是本机实测和 sample 栈分析，顺便挂一下我刚提的 issue 和相关历史 issue。

环境

  • Codex Desktop：26.506.31421
  • macOS：26.4.1
  • 机器：Mac mini M4 / 16GB
  • 状态：窗口在后台，无活跃会话，仅历史会话存在

现象

top / Activity Monitor 持续观察：

  • Codex 主进程：264% – 285% CPU，长期不降
  • codex app-server 子进程：0.1% – 1.3%
  • app-server 低占用，没有看到模型/后端计算成为瓶颈

直觉上很容易误判成「模型/后端在偷偷干活」，但子进程数据直接否掉了这个假设。

sample 栈在干嘛

用 sample 抓主进程，hot path 大概长这样（节选，存到 /tmp/codex-main-665.sample.txt）：

uv__io_poll
  └─ node::LibuvStreamWrap::OnUvRead
       └─ node::StreamBase::CallJSOnreadMethod
            └─ <JS / V8 frames>
                 └─ Buffer / ArrayBuffer ops
                 └─ memmove / bzero

特征非常清楚：

  • 全是 libuv → Node stream → JS 回调的链路
  • 大量时间耗在 Buffer / ArrayBuffer 的拷贝（memmove、bzero）
  • 没有任何 ML/推理相关符号，也没有 HTTP 客户端栈

所以这是 Electron 渲染/主进程里的 Node IPC / 本地流处理在空转或反复搬数据，跟模型本身没关系。

两个明显的放大因素

排查过程中发现两件事，单独看都不致命，但叠加起来很容易把这条 hot path 喂爆：

1. ~/.codex/sessions 体积异常

du -sh ~/.codex/sessions
# 596M
  • 单个最大的 JSONL 历史：178M
  • 另有多个 ~60M 量级的大历史文件

如果桌面端启动/空闲期会扫描、读取或预热这些会话历史，单个 178M JSONL 经过 Node stream → JS Buffer 这条链是相当昂贵的，正好对得上 sample 里看到的 memmove/Buffer 模式。

2. 空 git 仓库反复 git rev-parse 失败

日志里能看到对多个 workspace 反复执行 git rev-parse，并以 exit 128 失败，错误为：

fatal: ... does not have any commits yet
fatal: not a valid object name HEAD

也就是这些目录是 git init 之后还没有任何 commit、没有 HEAD 的「半成品仓库」。桌面端似乎在某个轮询里反复对它们探测 HEAD，每次失败再重试，又是一份持续的空转开销。

我提的 issue

刚提交的新 issue（带本机 sample 栈和数据）：

相关历史 issue（症状/方向接近，可参考）

这些 issue 里能看到类似的「空闲高 CPU / 主进程异常占用」描述，目前没有看到明确的官方修复结论，所以本帖也不声称已修。

临时绕法（亲测有缓解）

在官方修之前，可以试试：

  1. 重启 Codex Desktop：能立刻把主进程 CPU 打回正常水平，但过一段时间会复发，属于治标。
  2. 归档/清理超大会话历史：把 ~/.codex/sessions 里特别大的 JSONL（几十 M 起跳的那种）挪到别处备份，体积降下来后空闲 CPU 明显更稳。
  3. 处理空 git 仓库：对那些 No commits yet 的 workspace，要么补一个初始 commit 让 HEAD 存在，要么干脆把没用的 .git 目录删掉，避免桌面端反复 git rev-parse 失败。
  4. 排查时别先怀疑模型/后端：先看 app-server 子进程的 CPU。如果它是低的、主进程是高的，基本可以锁定在 Electron/Node 这一层，而不是网络或推理。

小结

这次的坑不在「模型慢」也不在「网络慢」，而在桌面端自己 IPC/流处理这层被大历史文件 + 异常 git 仓库联手放大。希望这份复盘对遇到同样症状的人有帮助，也欢迎在 issue 下补充各自的 sample 栈和 ~/.codex/sessions 体积数据，样本越多越容易定位。