macOS app 0.34: UI hangs because ChatGPT/Codex detection runs osascript on the main thread

快速结论：这个报错通常出现在 macOS Ollama 桌面应用 0.34.x 启动时：应用为了检测 ChatGPT/Codex 是否在运行，在主线程上调用 osascript 查询 System Events，如果系统里运行的应用很多、Accessibility 响应慢，主线程会被 fork + wait4 长时间阻塞，导致窗口无响应、鼠标事件被跳过，看起来像整个 Mac 卡死。优先排查是否只有 0.34.x 出现、降级到 0.33.3 是否恢复正常。

适用环境：已确认环境为 MacBook Pro (Mac16,5)，Apple M4 Max，macOS 27.2 (Build 26B5091g)，Ollama 桌面应用 0.34.1（故障）/ 0.33.3（正常），从 ollama.com 下载的 /Applications/Ollama.app 并通过应用内置更新器自动升级；0.34.2 与 0.34.3-rc1 也确认存在同一段检测代码。Issue 中未提供 Python、CUDA、PyTorch 等环境信息。

最快修复方案：暂无确认的一步修复方案（Issue 中尚未合入已验证的修复）。可优先尝试降级回 0.33.3 并关闭自动更新：在 ~/Library/Application Support/Ollama/db.sqlite 中执行 UPDATE settings SET auto_update_enabled = 0;。这是 Issue 作者本人验证有效的规避方法，不是上游官方修复。

注意事项：问题根因是代码把阻塞式 osascript 检测放在了 AppKit 主线程，只有在运行进程较多（此例 141 个进程，其中 53 个菜单栏应用）的机器上才会明显卡顿，应用少的测试机难以复现，因此官方一度无法重现。降级只是规避手段，会停留在旧版本、拿不到后续更新；直接结束 ollama serve 或重装 0.34.1 均无效；冻结时系统过于卡死，不会在 ~/Library/Logs/DiagnosticReports/ 留下崩溃日志。

问题场景

在 macOS 上使用从 ollama.com 下载的 Ollama 桌面应用，应用自动更新到 0.34.x（本例 0.34.1）后，打开应用窗口几秒内整个系统失去响应：指针还能移动，但点击、键盘都不生效，只能强制重启。手动降级回 0.33.3 后恢复正常。Issue 作者曾在启动 GUI 前杀掉 ollama serve 以排除内置服务端，问题依旧；后端服务本身在冻结期间仍正常工作，说明卡的是桌面应用的主线程，而不是推理服务。

报错原文

macOS app 0.34: UI hangs because ChatGPT/Codex detection runs osascript on the main thread

main thread in __wait4_nocancel after fork for 2714 of 2716 samples
child processes: osascript ... exists process "ChatGPT" / "Codex"
WebKit: pending main thread dispatch stuck for 0.5s
osascript -e 'tell application "System Events" to exists process "Zzz"': 1.66 s (process not running)
vs 0.08 s for a process that is running

原因分析

根因已被 Issue 中的维护者/作者定位，不是 MLX，也不是 Metal 或 llama.cpp 的内存问题。0.34.x 的 Mac 应用启动时会通过 refreshCodexAppState → IsCodexDesktopConnected 调用 cmd/launch/codex_app.go 里的 defaultCodexAppIsRunning()，用于检查 ChatGPT 或 Codex 是否在运行。问题在于这段检查跑在 AppKit 主线程上，它执行 osascript -e 'tell application "System Events" to exists process "ChatGPT"'（Codex 同理），主线程会在 fork + wait4 上阻塞直到返回。

当目标进程没有运行时，System Events 会对每个正在运行的应用发送 Accessibility 请求（AXUIElementCopyAttributeNames）来判断进程是否存在。在这台 Mac 上（141 个进程、53 个菜单栏应用），每次检查约 1.7 秒，个别应用响应慢时会超过 3 秒；两次检查连续执行，主线程几乎一直处于阻塞状态，WebKit 记录 pending main thread dispatch stuck for 0.5s，鼠标事件被跳过，窗口不断重新抢焦点，于是整个 Mac 表现为冻结。应用少的机器上每次检查约 0.1 秒，几乎无感，这就是问题难以复现的原因。官方建议的修复方向是改用 NSRunningApplication runningApplicationsWithBundleIdentifier: 或 pgrep 检测，或至少把检查移出主线程，但 Issue 中尚未确认修复已合入。

环境排查

确认 Ollama 桌面应用版本：出现问题的为 0.34.1，同一段检测代码仍在 0.34.2 和 0.34.3-rc1 中；0.33.3 正常。
确认安装方式：/Applications/Ollama.app，从 ollama.com / GitHub Releases 手动下载，非 brew。
确认更新路径：由应用内置更新器自动从 0.33.3 升级到 0.34.1。
确认系统环境：macOS 27.2 (Build 26B5091g)，Apple M4 Max (MacBook Pro Mac16,5)。
统计当前运行进程数量与菜单栏应用数量：本例为 141 个进程、其中 53 个菜单栏应用，是触发卡死的关键条件。
检查系统日志与诊断报告：~/.ollama/logs/app*.log、~/.ollama/logs/server*.log，以及 ~/Library/Logs/DiagnosticReports/（冻结时通常不会写入崩溃报告）。
Issue 中未涉及 Python、CUDA、PyTorch、显卡驱动等依赖，无需排查这些项。

解决步骤

先确认症状与版本相关：记录当前 Ollama 桌面应用版本，观察卡死只在 0.34.x 出现、0.33.3 不出现。
可优先尝试降级回 0.33.3：从 github.com/ollama/ollama/releases 下载对应的 Ollama-darwin.zip 并重新安装，替换 0.34.1。
关闭自动更新，避免再次被升级到 0.34.x：编辑 ~/Library/Application Support/Ollama/db.sqlite，执行 UPDATE settings SET auto_update_enabled = 0;（Issue 作者使用的规避手段）。
如果必须留在 0.34.x，可减少卡死概率：退出不必要的重型应用，尤其是大量菜单栏应用，降低 Accessibility 检查的耗时；但 Issue 中未验证这能彻底避免卡死。
抓取证据便于向官方反馈：用 grep -HF "0.34.1" ~/.ollama/logs/app*.log 和 grep -HF "0.34.1" ~/.ollama/logs/server*.log 找出同一编号的 app/server 日志对并完整附上；卡死时另开终端用 sample 抓取进程调用栈，确认主线程是否停在 __wait4_nocancel。
等待或跟进官方修复：Issue 中建议改用 NSRunningApplication runningApplicationsWithBundleIdentifier: / pgrep，或把检查移出主线程，但截至 Issue 关闭时尚未确认已发布修复版本。

验证方法

降级到 0.33.3 后，反复启动 Ollama 桌面应用，若窗口出现后系统保持响应、点击和键盘正常，则说明确实由 0.34.x 的 ChatGPT/Codex 检测引起。进一步验证可在卡死时用 sample 查看主线程是否阻塞在 __wait4_nocancel，并观察是否有反复出现的 osascript ... exists process "ChatGPT" / "Codex" 子进程；同时确认 ~/.ollama/logs/app*.log 与 server*.log 中没有报错、server 侧仍正常响应请求，即可判定问题出在应用主线程而非推理后端。