macOS上syspolicyd高占用时如何判断是否与Codex有关

Posted on Edited on Views:

在macOS上使用Codex桌面端时，如果机器突然变卡，活动监视器里又恰好是syspolicyd或trustd占满CPU，很容易把两件事直接联系起来。不过，syspolicyd本来就是系统安全策略的一部分，应用启动、签名验证以及应用写入的可执行文件都可能触发它。进程同时出现，只能说明值得继续查，还不能证明Codex就是根因。

更稳妥的顺序是先做一轮只读检查，确认高占用是否随桌面应用启动和退出而变化，再决定是更新应用、暂时改用CLI，还是继续检查其他刚刚安装或生成的程序。

先确认是谁在消耗资源

活动监视器已经足够看出CPU趋势。需要把进程信息留存下来时，可以执行：

1
2
ps -axo pid,ppid,%cpu,%mem,etime,command \
  | grep -E '[s]yspolicyd|[t]rustd|[C]hatGPT|[C]odex'

当前的Codex桌面体验位于ChatGPT桌面应用中，旧版本或旧安装中也可能仍然看到Codex.app，因此排查时不要只盯着一个应用名。

如果syspolicyd持续高占用，再看它打开了多少文件，以及最近打开的对象里有没有反复出现同一路径：

1
2
3
4
5
6
policy_pid="$(pgrep -x syspolicyd | head -n 1)"

if [ -n "$policy_pid" ]; then
  sudo lsof -nP -p "$policy_pid" | wc -l
  sudo lsof -nP -p "$policy_pid" | tail -n 50
fi

这里的文件数只能用来判断进程是否异常忙碌，不能拿一个固定阈值直接下结论。真正有价值的是路径是否反复指向ChatGPT、Codex或它刚刚下载、解压、编译出来的可执行文件。

系统统一日志也能补上时间线：

1
2
3
/usr/bin/log show --last 10m --style compact \
  --predicate 'process == "syspolicyd" OR process == "trustd"' \
  | tail -n 100

日志可能隐去部分路径，也可能夹杂其他应用的安全检查。重点看高占用开始前后是否重复出现同一签名、同一目录或同一类校验失败，不要因为看到syspolicyd字样就认定已经找到了原因。

用退出前后的变化判断关联

如果卡顿仍在发生，先保存正在进行的工作，再从菜单正常退出ChatGPT桌面应用。旧版独立Codex应用同样应当正常退出，而不是用模糊的pkill -f一次结束所有名称相近的进程。

退出后重新执行前面的ps和lsof检查，观察一两分钟：

  • 应用退出后，syspolicyd占用很快下降，且多次发生时都能重复看到相同变化，说明两者关联较强。
  • 应用已经退出，高占用却没有变化，日志和打开文件也指向别的路径，应当继续检查最近安装、更新或生成的程序。
  • 只有一次时间上的重合，没有路径或重复现象支撑，最多只能记为怀疑对象。

这一步仍然不能回答是桌面应用自身、应用调用的工具，还是项目里刚生成的二进制文件触发了检查，但至少可以避免一开始就修改系统安全配置。

恢复时先动应用，不动系统安全服务

如果退出桌面应用后系统恢复正常，先不要急着重新打开。可以从官方渠道更新或重新安装ChatGPT桌面应用，重启macOS后再观察。系统服务已经长时间无响应时，重启也比强制结束syspolicyd、trustd更稳妥。

桌面端暂时不能使用时，可以改用Codex CLI继续工作：

1
2
codex --version
codex

CLI是独立入口，但并不意味着它一定绕过所有系统检查。如果任务会下载工具、运行浏览器或生成新的可执行文件，仍然可能触发Gatekeeper。它在这里只是缩小变量的临时替代方案，不是对问题原因的证明。

不建议为了消除高占用去关闭Gatekeeper或SIP，也不要删除/var/db/SystemPolicy下的数据库。它们会扩大安全风险，还会破坏现场信息；即使负载暂时下降，也无法说明原来的触发对象是什么。清理Codex会话或本地缓存同样不是直接修复，除非日志和打开文件已经明确指向其中的具体损坏文件。

更新后检查应用本身

系统恢复后，可以先记录macOS、CPU架构和应用版本：

1
2
3
4
5
6
7
8
9
sw_vers
uname -m

for app in /Applications/ChatGPT.app /Applications/Codex.app; do
  [ -d "$app" ] || continue
  echo "$app"
  defaults read "$app/Contents/Info" CFBundleShortVersionString
  defaults read "$app/Contents/Info" CFBundleVersion
done

再让系统评估一次应用是否能正常执行：

1
spctl --assess --type execute --verbose=4 /Applications/ChatGPT.app

这条命令本身会发起安全评估，应当在系统已经稳定时运行。如果实际安装的是旧版Codex.app，把路径换成对应应用即可。评估失败时，优先从官方渠道重新下载；不要用移除隔离属性、临时签名或全局关闭安全检查来掩盖失败。

如果问题仍能重复出现，提交反馈时附上macOS版本、芯片架构、应用版本、出现与恢复时间，以及脱敏后的进程快照和日志片段。项目路径、用户名、对话内容和凭据不需要跟着日志一起公开。

参考资料