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

快速结论：该问题通常出现在 macOS 上运行 Ollama 桌面应用 0.34.x（含 0.34.1、0.34.2，以及 0.34.3-rc1）时，应用启动后会卡死甚至让整个系统失去响应。优先排查方向不是 MLX 或模型加载，而是应用启动时对 ChatGPT/Codex 的检测逻辑在主线程上执行 osascript 导致的阻塞。

适用环境：已验证环境为 macOS 27.2（Build 26B5091g）、Apple M4 Max（MacBook Pro，Mac16,5）、Ollama 桌面应用 0.34.1（0.34.2 同样复现，0.34.3-rc1 仍然存在相同代码）。0.33.3 正常。安装方式为从 ollama.com 下载的 /Applications/Ollama.app，非 brew，更新路径为应用内置自动更新。

最快修复方案：暂无确认的一步修复方案。Issue 中确认有效的做法是降级回 v0.33.3（手动从 GitHub Release zip 重装），并关闭自动更新以避免被再次升级到 0.34.x。

注意事项：降级只是绕过问题，并非修复；关闭自动更新意味着不会收到后续版本更新。Issue 中提出的代码层修复建议（改用 NSRunningApplication runningApplicationsWithBundleIdentifier: 或 pgrep，或至少把检测移出主线程）尚未被合入正式版本，0.34.3-rc1 中仍存在该逻辑。

问题场景

在 macOS 上使用 Ollama 桌面应用（/Applications/Ollama.app）从 0.33.3 自动更新到 0.34.1 后，打开应用几秒内整个系统失去响应：鼠标指针还能移动，但点击无响应、键盘无输入，窗口反复抢占焦点，只能强制关机重启。该现象在 0.34.1 上 100% 复现，在 0.33.3 上 0% 复现。

用户已排除若干因素：多次重启并重新打开 0.34.1 无效；在启动 GUI 前杀掉 ollama serve 无效；重新下载 0.34.1 与 0.33.3 的 Ollama-darwin.zip 全新安装后，结论一致。冻结后 ~/Library/Logs/DiagnosticReports/ 中没有崩溃报告，用户推测是系统锁死到无法写入日志。

Issue 作者最初怀疑与 0.34 的 MLX / llama.cpp 更新有关（当时同时存在 #18038、#18269、#18505、#18231、#18213 等 MLX 相关回归），但维护者后续定位后确认：根因不是 MLX。

报错原文

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

main thread blocked in fork + wait4 (__wait4_nocancel) for 2714 of 2716 samples
child processes: osascript -e 'tell application "System Events" to exists process "ChatGPT"' / "Codex"

WebKit: pending main thread dispatch stuck for 0.5s

原因分析

根因已由维护者确认：0.34.x Mac 应用启动时会检查 ChatGPT 或 Codex 是否在运行。该检查由 defaultCodexAppIsRunning()（位于 cmd/launch/codex_app.go）实现，经由 refreshCodexAppState → IsCodexDesktopConnected 调用，并且运行在 AppKit 主线程上。

具体流程是执行 osascript -e 'tell application "System Events" to exists process "ChatGPT"'，随后对 “Codex” 再做一次同样的检查；主线程会在 fork 之后阻塞在 wait4，直到每个检查完成。

当目标进程不存在时，System Events 会通过向每个正在运行的应用发送辅助功能请求（AXUIElementCopyAttributeNames）来判断 exists process "X"。在问题机器上（141 个进程，其中 53 个是菜单栏应用），每次检查约耗时 1.7 秒；只要有任何应用响应辅助功能较慢，就会超过 3 秒。两次检查连续执行，导致主线程几乎一直处于阻塞状态。WebKit 记录到 pending main thread dispatch stuck for 0.5s，鼠标事件被跳过，窗口不断重新抢占焦点，因此表现为整个系统卡死。同时后端服务本身仍正常工作。

这也解释了为什么多数人无法复现：在运行应用较少的 Mac 上，每次检查仅约 0.1 秒，用户几乎察觉不到。因此该问题只在同时运行大量应用的机器上明显暴露。

环境排查

确认 Ollama 桌面应用版本：出现问题的为 0.34.1、0.34.2，0.34.3-rc1 仍含相同代码；正常版本为 0.33.3。
确认安装方式：从 ollama.com 下载的 /Applications/Ollama.app，非 brew 安装。
确认更新路径：由应用内置自动更新从 0.33.3 升级到 0.34.1。
确认系统与硬件：macOS 27.2（Build 26B5091g）、Apple M4 Max、MacBook Pro（Mac16,5）。
确认当前运行的进程数量，尤其是菜单栏应用数量（问题机器为 141 个进程、53 个菜单栏应用）。
若仍有可用日志，可对比应用日志与 server 日志：命令为 grep -HF "0.34.1" ~/.ollama/logs/app*.log 和 grep -HF "0.34.1" ~/.ollama/logs/server*.log；本 Issue 中两份日志均无报错，卡顿发生在应用主线程。

解决步骤

确认当前版本是否为 0.34.x（0.34.1 / 0.34.2 / 0.34.3-rc1），以及是否从 0.33.3 自动更新而来。
确认系统卡死的表现符合本 Issue 描述：指针可动、点击无响应、窗口反复抢占焦点，且后端服务仍正常。
使用 Issue 中已验证有效的方法：手动从 github.com/ollama/ollama/releases 下载 v0.33.3 的 release zip 并重新安装，替代 0.34.1。
为避免被自动更新再次升级到 0.34.x，可关闭自动更新：在 ~/Library/Application Support/Ollama/db.sqlite 中执行 UPDATE settings SET auto_update_enabled = 0;（此为 Issue 作者采用的临时规避方式）。
在启动应用前，可优先尝试关闭大量不必要的应用（尤其是菜单栏应用），以减少 System Events 辅助功能请求的耗时；此做法未在 Issue 中作为确认方案验证，仅作为缓解思路。
如需向维护者提供诊断信息，可采集 sample 输出与卡顿期间出现的 osascript 子进程记录，以及 log show --predicate 'process == "Ollama" OR process == "ollama" OR process == "llama-server"' --last 1h 的输出。
等待官方针对该检测逻辑发布修复版本；截至 Issue 讨论，0.34.3-rc1 中该代码仍然存在。

验证方法

按上述步骤降级到 v0.33.3 后重新启动应用，观察打开应用几秒内系统是否仍会卡死。Issue 中作者的验证结果是：v0.34.1 上 100% 复现，v0.33.3 上 0% 复现，因此降级后不再卡死即可确认已绕过该问题。

如果希望确认是同一根因，可在问题版本卡死时采集 sample，检查主线程是否长时间停留在 __wait4_nocancel（fork 之后等待 osascript）；并确认卡顿期间是否持续出现对 "ChatGPT" / "Codex" 的 osascript System Events 检查子进程。