2026 年 8 月 31 日Ollama 发布 v0.33.2 最新版本。本次更新虽然聚焦在应用体验与 Claude Desktop 代理稳定性但涉及 macOS 应用启动接力、进程同步、系统外观适配、云模型目录刷新、退出时配置恢复等多个关键环节。从变更信息来看本次版本共包含 6 次提交涉及 21 个文件共有 3 位贡献者参与代码改动规模为 898 行新增、481 行删除。更新重点可以概括为三项Ollama 应用重新跟随系统外观深色模式支持恢复。macOS 应用启动时能够正确交接给已经运行的实例不再错误启动第二个实例。Claude Desktop 代理在模型目录更新时不再中断正在进行中的请求。此外v0.33.2 还补充了 Claude 的账户云端模型列表能力并完成了部分无效代码清理与代码规范修复。一、更新概览v0.33.2 解决了哪些问题此次更新的发布说明明确列出了三个用户可直接感知的变化。第一Ollama 应用重新遵循系统外观设置。此前应用的深色模式支持出现缺失或未能正确跟随系统设置的情况。本次更新恢复了应用对系统外观的响应能力。当系统切换到深色模式时Ollama 应用能够再次呈现对应的深色界面系统处于浅色模式时应用也会与系统整体视觉保持一致。第二修复 macOS 应用实例交接问题。此前 macOS 上如果 Ollama 已经在运行再次启动应用时可能会启动第二个实例或者原有实例与新实例之间无法正确完成交接。本次更新改进了已有实例的处理逻辑新启动的应用会识别现有运行实例并根据进程状态完成接力、关闭和退出控制避免重复启动带来的冲突。第三Claude Desktop 代理刷新模型目录时不再打断请求。Claude Desktop 代理会使用模型目录来处理可用模型、模型映射和云端模型信息。此前当模型目录发生更新时可能会导致正在进行中的请求被中断。v0.33.2 调整了模型目录刷新与代理请求之间的处理方式使目录更新不会再干扰已经在执行的请求。二、提交记录6 项变更覆盖应用、代理与代码维护本次更新包含 6 次提交时间集中在 2026 年 8 月 27 日与 8 月 28 日。8 月 27 日完成的提交包括应用恢复系统深色模式支持变更编号 18049。代理在模型目录变化时继续处理请求变更编号 18058。同步 macOS 应用交接流程变更编号 18056。8 月 28 日完成的提交包括为 Claude 列出账户云端模型变更编号 18077。清理无效代码变更编号 17381。修复代码检查问题变更编号 18081。从提交主题可以看到v0.33.2 并非单纯进行视觉调整而是围绕“应用是否只运行一个正确实例”“Claude Desktop 是否能稳定使用模型目录”“退出和接力时是否会影响已有代理配置”等问题进行了系统性修复。三、应用启动逻辑变化启动前先判断已有实例是否可处理在应用主入口中已有实例的处理逻辑发生了关键变化。原有流程中应用会直接调用已有实例处理函数。更新后处理函数会返回一个布尔结果主流程会根据结果决定是否继续启动if!handleExistingInstance(startHidden){return}这一调整意味着已有实例的检测不再只是一次无返回值的处理动作而是正式参与应用启动决策。如果已有实例处理后判断当前进程不应该继续启动应用会立即返回不再继续执行后续初始化流程。这样可以避免多个实例同时继续启动降低重复运行、资源竞争和应用状态冲突的可能性。该逻辑尤其与 macOS 平台的实例接力机制相关。更新后当当前启动实例发现有一个更新的实例已经拥有交接控制权时当前实例会停止继续启动。四、macOS 多实例问题修复从“直接杀掉其他实例”升级为进程同步屏障本次版本中macOS 应用实例处理部分的改动规模较大。原有逻辑相对直接处理已有实例时会调用原生层的逻辑关闭其他实例。更新后这一部分引入了更完整的应用同步屏障机制。新的机制不再仅仅是“发现其他实例后关闭它们”而是将整个过程拆分为识别当前进程身份。发现其他 Ollama 应用进程。判断哪个实例更新。决定当前实例是否有权接管。向旧实例发送交接信号。等待旧实例退出。在必要时发送正常终止信号。在仍未退出时进行强制终止。确认没有其他实例残留后再完成启动。这套机制的核心目标是在 macOS 上存在已有 Ollama 应用实例时确保应用能够完成稳定交接而不是简单地再启动一个新实例。五、进程身份识别不只看进程号还要看启动时间更新中新增了应用进程身份结构用于识别一个具体的 Ollama 应用进程。进程身份包含两个字段字段含义pid进程号startedAt进程启动时间仅凭进程号无法完全可靠地判断是否为同一个进程因为进程退出后其进程号未来可能被其他进程重新使用。因此新的逻辑会同时比较进程号和启动时间。新增的同一进程判断逻辑要求两个条件同时成立进程号相同。启动时间相同。同时代码也新增了“是否启动得更晚”的判断规则如果启动时间不同则启动时间更晚的进程被视为更新实例。如果启动时间相同则进程号更大的实例被视为更新实例。这一规则用于解决多个 Ollama 应用实例重叠启动时的归属问题。只有被判定为较新的实例才可以继续承担接力与终止旧实例的工作。六、新实例选举较新的启动者拥有接力控制权新的同步屏障逻辑中有一个明确原则多个重叠启动的实例需要按进程启动时间排序只有最新启动的候选实例可以终止已有实例。当当前实例发现其他进程比自己更新时会返回“更新的应用实例拥有交接权”的错误状态。这意味着当前实例会被判定为较旧实例不能继续关闭其他进程也不应继续自己的启动流程。代码将这一情形定义为专门的错误varerrNewerAppInstanceerrors.New(newer app instance owns the handoff)当出现该错误时日志会记录“更新的 Ollama 应用实例拥有交接权”随后当前实例停止启动。这种设计避免了两个同时启动的实例都认为自己应当关闭对方的问题。通过对进程启动时间和进程号进行排序应用可以确定单一的交接控制者。七、同步屏障的完整退出策略交接、正常终止、强制终止为了让旧实例可靠退出v0.33.2 将关闭过程分成三种模式。关闭模式使用信号作用交接关闭SIGUSR1告知旧应用进行接力退出正常终止SIGTERM在交接超时后请求正常结束强制终止SIGKILL在正常终止仍超时后强制结束整个流程的时间配置如下阶段时长交接等待时间5 秒正常终止等待时间30 秒强制终止等待时间5 秒进程状态轮询间隔50 毫秒空进程快照确认间隔100 毫秒也就是说新的实例接力流程首先给旧实例 5 秒时间处理交接若旧实例没有退出再给予最长 30 秒的正常终止阶段如果依然无法退出则再进行最长 5 秒的强制终止等待。这种顺序体现出应用优先尝试交接与正常退出而不是一开始就直接终止进程。八、为什么需要两次确认“没有其他进程”更新中的同步屏障并不会在第一次发现“没有其他应用进程”时立刻认为交接完成。代码要求连续两次获得空的进程快照才认为其他实例已全部退出。这一机制是为了应对 macOS 工作区进程快照并非原子操作的情况。某个进程在系统进程列表中出现的时机可能存在延迟如果只依赖一次空快照就有可能让尚未完全被发现的实例绕过同步屏障。因此逻辑会先记录已经看到一次空快照然后等待一个稳定时间再进行一次检查。只有第二次仍然为空才返回成功。这样做可以提高多实例交接过程中的稳定性降低旧实例刚好在系统中延迟出现的风险。九、代码明确保留的边界两个并发启动实例可能同时通过虽然同步屏障机制已经明显增强但代码中也明确说明了一个仍未处理的边界情况。由于 macOS 的工作区快照不是原子操作如果两个应用实例几乎同时启动且两者在检测时都还没有出现在对方的可见进程列表中那么两个实例都有可能通过屏障。也就是说这个极端并发启动窗口被明确标注为暂未处理。这一说明反映出本次更新对已知限制保持了明确边界它处理了已发现实例的交接、退出与接管问题但没有宣称完全消除所有极端并发启动时序问题。十、进程存活检查更严格防止误操作被复用的进程号在停止 macOS 应用进程前新的代码不会直接根据进程号发送信号而是先确认目标身份仍然匹配。处理流程包括根据目标进程号读取系统进程信息。如果进程不存在则视为已经退出。如果进程存在则比较当前读取到的进程身份与此前记录的身份。只有进程号与启动时间都一致时才认为该目标仍是原来的 Ollama 应用进程。只有确认目标仍在运行时才发送对应的关闭信号。这种做法避免了一个重要问题旧进程退出后系统可能重新分配同一个进程号。如果仅依赖进程号就有可能将信号发送给并非原来的目标进程。更新后通过进程号加启动时间的双重校验确保强制终止等操作只作用于预期的存活身份。十一、交接信号到达后先停止 Claude 代理再进行退出应用运行期间会监听交接信号。当收到交接信号时逻辑会依次执行记录收到应用交接信号并准备关闭。停止 Claude 应用代理。执行用于交接的退出流程。原有流程中接收到交接信号后会停止 Claude 应用代理、调用原生退出逻辑并执行交接退出。更新后不再在该处直接调用原生退出而是进入统一的交接退出路径。新增的交接退出函数会先将一个全局原子状态设置为真标识“应用交接正在进行”再调用通用退出流程。这一变化的重要点在于应用退出不再只依赖实时检测是否有另一个 Ollama 实例运行而是通过明确的交接状态保存当前退出的原因。十二、Claude Desktop 配置恢复逻辑调整接力退出时不再被后续信号干扰本次 macOS 交接修复中还涉及 Claude Desktop 配置恢复逻辑。更新前应用退出时会调用原生层逻辑检查是否存在其他 Ollama 实例运行并将结果作为是否处于交接状态的依据。更新后退出逻辑不再通过该方式动态判断而是读取全局原子状态appHandoffInProgress.Load()该状态会在执行交接退出时提前设置。代码注释指出一旦替换交接已经开始之后到来的关闭信号不应使 Claude 配置在新应用运行期间被重新恢复。换句话说当旧实例已经确认要交接给新实例时退出过程必须维持这一状态避免后续关闭流程错误地将 Claude Desktop 从 Ollama 网关配置恢复回原状态从而影响新实例的工作。这也是此次 macOS 多实例修复的重要配套调整不仅要确保旧应用退出还要确保退出过程中的 Claude 代理配置不会破坏新应用接管后的状态。十三、Claude Desktop 退出恢复逻辑简化本次更新还简化了 Claude Desktop 退出前恢复配置的函数参数。原先的恢复判断函数会接收两个状态是否正在交接。是否已经配置。更新后该函数只保留“是否已经配置”这一项。新的逻辑变为如果未配置 Claude Desktop 网关则不执行恢复。如果已经配置则执行恢复操作。交接状态不再由该函数自行判断而是通过前面提到的应用交接全局状态统一控制退出流程。这使配置恢复的职责更加集中恢复函数只负责根据是否配置决定是否恢复是否属于交接退出则由应用的退出状态来管理。十四、Claude Desktop 云模型账户模型会被纳入可用模型列表v0.33.2 增加了 Claude 的账户云端模型列表能力。在 Claude Desktop 启动目录解析流程中应用会尝试加载账户云端模型。如果加载失败会记录调试日志如果加载成功则将云端模型库存并入当前可用模型集合。更新前合并云端模型时存在不同的参数控制方式例如是否追加缺失模型。更新后这一参数被移除合并逻辑统一为mergeClaudeDesktopCloudInventory(available,cloudModels)新的合并逻辑会根据云端模型库存验证已有模型。记录已出现的模型名称。遍历账户云端模型。对于当前列表中还不存在的云端模型将其加入结果。返回包含可用模型与账户云端模型的统一列表。这意味着账户中可使用的云端模型会被补充到 Claude Desktop 的可用模型目录中。十五、模型目录刷新时可用模型与可选模型统一处理在 Claude Desktop 启动时原先逻辑会根据是否存在显式云端模型名称决定可选模型集合是否需要采用不同的合并方式。更新后逻辑被统一加载到账户云端模型后先合并至可用模型列表。可选模型列表直接使用合并后的可用模型列表。也就是说不再区分“仅验证已有模型”与“追加缺失模型”的两条分支而是统一使用完整合并后的模型目录。在模型目录刷新流程中也进行了相同调整。当云端库存已知时应用会将云端模型统一合并到可用模型中。当当前模型与账户模型在名称或 Ollama 模型字段上匹配时也会将对应账户模型以统一方式合并到可用模型中。这使 Claude Desktop 对账户云端模型的识别与展示逻辑更加一致。十六、模型合并函数变化不再保留“是否追加缺失项”开关原有的云端模型合并函数带有一个布尔参数用于控制是否追加当前列表中缺失的云端模型。更新后这个参数被移除。新的函数始终执行以下两步使用云端模型库存校验已有模型。将未出现在已有结果中的云端模型补充进去。因此账户云端模型不再只在某些特定分支中被追加而是统一进入模型合并结果。这一修改影响了以下场景Claude Desktop 启动时的模型目录解析。Claude Desktop 运行过程中的模型目录刷新。当前模型与账户模型匹配时的更新。Claude Desktop 模型选择时的可选模型生成。十七、Claude Desktop 模型选择统一使用账户云模型后的可选集合在 Claude Desktop 模型映射应用流程中如果成功获取到账户云端模型新的逻辑会将现有可用模型与云端模型进行统一合并并将合并结果作为可选模型集合。之后系统会根据当前模型、已知本地模型和映射配置执行已知 Claude Desktop 模型映射。完成映射后验证流程也发生了变化。原先验证函数会同时考虑访问状态、本地模型名称以及本地模型加载是否成功等条件。更新后映射后的模型会进入一个新的可用性保障流程ensureClaudeDesktopModelsAvailable(context.Background(),selected)这一变更将模型可用性确认放入专门的保障函数中处理。从变更关系看模型选择流程不再直接使用原有的综合验证调用而是通过新的可用性确认步骤处理已选择模型。十八、代理目录更新不中断请求本次版本的重要稳定性修复发布说明中明确指出Claude Desktop 代理在模型目录更新时不再中断正在进行中的请求。模型目录更新通常涉及以下内容可用模型列表变化。账户云端模型信息加载。本地模型与云端模型的合并。Claude Desktop 模型映射刷新。当前模型目录的验证与更新。本次更新将云端库存合并、当前模型匹配和模型可用性保障等逻辑进行调整使模型目录更新能够与已经在进行中的代理请求更好地共存。对于 Claude Desktop 代理而言这意味着模型目录刷新不再需要以打断当前请求为代价。正在执行的请求可以继续完成而模型目录变化则在后续流程中生效。十九、深色模式恢复应用重新跟随系统外观v0.33.2 的另一项直接可见更新是应用恢复系统外观跟随能力。发布说明中指出Ollama 应用现在再次遵循系统外观从而恢复深色模式支持。这项更新的核心内容并不是增加新的主题配置入口而是恢复应用根据系统外观自动适配的行为。当系统使用深色外观时应用能够使用对应的深色模式当系统采用其他外观时应用也恢复与系统保持一致。这一调整使应用界面行为重新符合系统级外观设置。二十、代码维护清理无效代码与修复代码检查问题除了功能修复外本次版本还包含两项维护类提交清理无效代码。修复代码检查问题。这两项改动在发布记录中被单独列出说明 v0.33.2 也同步进行了代码层面的整理。无效代码清理有助于减少不再使用的实现残留代码检查修复则用于使代码符合现有检查规则。它们与应用启动、代理稳定性和模型目录能力一起构成了本次版本的完整更新内容。二十一、v0.33.2 变更总结代码地址github.com/ollama/ollamaOllama v0.33.2 的更新重点集中在三个方向应用界面适配、macOS 实例管理、Claude Desktop 代理稳定性。更新方向本次变化系统外观应用再次跟随系统外观恢复深色模式支持macOS 启动修复已运行实例的交接问题避免错误启动第二个实例进程同步引入进程身份、启动时间排序、交接与终止阶段控制退出处理通过交接状态避免退出时错误恢复 Claude 配置Claude 云模型支持列出账户云端模型并统一合并到可用模型目录模型选择模型映射后改为执行可用性保障流程代理稳定性模型目录更新不再中断正在进行中的 Claude Desktop 请求代码维护清理无效代码修复代码检查问题整体来看v0.33.2 对 macOS 应用交接进行了较完整的流程重构从简单处理其他实例升级为带有进程身份校验、最新实例选举、多阶段退出、双重空快照确认和交接状态控制的同步屏障。
ollama v0.33.2更新：深色模式回归、macOS 多开接力修复、Claude Desktop 请求不中断
2026 年 8 月 31 日Ollama 发布 v0.33.2 最新版本。本次更新虽然聚焦在应用体验与 Claude Desktop 代理稳定性但涉及 macOS 应用启动接力、进程同步、系统外观适配、云模型目录刷新、退出时配置恢复等多个关键环节。从变更信息来看本次版本共包含 6 次提交涉及 21 个文件共有 3 位贡献者参与代码改动规模为 898 行新增、481 行删除。更新重点可以概括为三项Ollama 应用重新跟随系统外观深色模式支持恢复。macOS 应用启动时能够正确交接给已经运行的实例不再错误启动第二个实例。Claude Desktop 代理在模型目录更新时不再中断正在进行中的请求。此外v0.33.2 还补充了 Claude 的账户云端模型列表能力并完成了部分无效代码清理与代码规范修复。一、更新概览v0.33.2 解决了哪些问题此次更新的发布说明明确列出了三个用户可直接感知的变化。第一Ollama 应用重新遵循系统外观设置。此前应用的深色模式支持出现缺失或未能正确跟随系统设置的情况。本次更新恢复了应用对系统外观的响应能力。当系统切换到深色模式时Ollama 应用能够再次呈现对应的深色界面系统处于浅色模式时应用也会与系统整体视觉保持一致。第二修复 macOS 应用实例交接问题。此前 macOS 上如果 Ollama 已经在运行再次启动应用时可能会启动第二个实例或者原有实例与新实例之间无法正确完成交接。本次更新改进了已有实例的处理逻辑新启动的应用会识别现有运行实例并根据进程状态完成接力、关闭和退出控制避免重复启动带来的冲突。第三Claude Desktop 代理刷新模型目录时不再打断请求。Claude Desktop 代理会使用模型目录来处理可用模型、模型映射和云端模型信息。此前当模型目录发生更新时可能会导致正在进行中的请求被中断。v0.33.2 调整了模型目录刷新与代理请求之间的处理方式使目录更新不会再干扰已经在执行的请求。二、提交记录6 项变更覆盖应用、代理与代码维护本次更新包含 6 次提交时间集中在 2026 年 8 月 27 日与 8 月 28 日。8 月 27 日完成的提交包括应用恢复系统深色模式支持变更编号 18049。代理在模型目录变化时继续处理请求变更编号 18058。同步 macOS 应用交接流程变更编号 18056。8 月 28 日完成的提交包括为 Claude 列出账户云端模型变更编号 18077。清理无效代码变更编号 17381。修复代码检查问题变更编号 18081。从提交主题可以看到v0.33.2 并非单纯进行视觉调整而是围绕“应用是否只运行一个正确实例”“Claude Desktop 是否能稳定使用模型目录”“退出和接力时是否会影响已有代理配置”等问题进行了系统性修复。三、应用启动逻辑变化启动前先判断已有实例是否可处理在应用主入口中已有实例的处理逻辑发生了关键变化。原有流程中应用会直接调用已有实例处理函数。更新后处理函数会返回一个布尔结果主流程会根据结果决定是否继续启动if!handleExistingInstance(startHidden){return}这一调整意味着已有实例的检测不再只是一次无返回值的处理动作而是正式参与应用启动决策。如果已有实例处理后判断当前进程不应该继续启动应用会立即返回不再继续执行后续初始化流程。这样可以避免多个实例同时继续启动降低重复运行、资源竞争和应用状态冲突的可能性。该逻辑尤其与 macOS 平台的实例接力机制相关。更新后当当前启动实例发现有一个更新的实例已经拥有交接控制权时当前实例会停止继续启动。四、macOS 多实例问题修复从“直接杀掉其他实例”升级为进程同步屏障本次版本中macOS 应用实例处理部分的改动规模较大。原有逻辑相对直接处理已有实例时会调用原生层的逻辑关闭其他实例。更新后这一部分引入了更完整的应用同步屏障机制。新的机制不再仅仅是“发现其他实例后关闭它们”而是将整个过程拆分为识别当前进程身份。发现其他 Ollama 应用进程。判断哪个实例更新。决定当前实例是否有权接管。向旧实例发送交接信号。等待旧实例退出。在必要时发送正常终止信号。在仍未退出时进行强制终止。确认没有其他实例残留后再完成启动。这套机制的核心目标是在 macOS 上存在已有 Ollama 应用实例时确保应用能够完成稳定交接而不是简单地再启动一个新实例。五、进程身份识别不只看进程号还要看启动时间更新中新增了应用进程身份结构用于识别一个具体的 Ollama 应用进程。进程身份包含两个字段字段含义pid进程号startedAt进程启动时间仅凭进程号无法完全可靠地判断是否为同一个进程因为进程退出后其进程号未来可能被其他进程重新使用。因此新的逻辑会同时比较进程号和启动时间。新增的同一进程判断逻辑要求两个条件同时成立进程号相同。启动时间相同。同时代码也新增了“是否启动得更晚”的判断规则如果启动时间不同则启动时间更晚的进程被视为更新实例。如果启动时间相同则进程号更大的实例被视为更新实例。这一规则用于解决多个 Ollama 应用实例重叠启动时的归属问题。只有被判定为较新的实例才可以继续承担接力与终止旧实例的工作。六、新实例选举较新的启动者拥有接力控制权新的同步屏障逻辑中有一个明确原则多个重叠启动的实例需要按进程启动时间排序只有最新启动的候选实例可以终止已有实例。当当前实例发现其他进程比自己更新时会返回“更新的应用实例拥有交接权”的错误状态。这意味着当前实例会被判定为较旧实例不能继续关闭其他进程也不应继续自己的启动流程。代码将这一情形定义为专门的错误varerrNewerAppInstanceerrors.New(newer app instance owns the handoff)当出现该错误时日志会记录“更新的 Ollama 应用实例拥有交接权”随后当前实例停止启动。这种设计避免了两个同时启动的实例都认为自己应当关闭对方的问题。通过对进程启动时间和进程号进行排序应用可以确定单一的交接控制者。七、同步屏障的完整退出策略交接、正常终止、强制终止为了让旧实例可靠退出v0.33.2 将关闭过程分成三种模式。关闭模式使用信号作用交接关闭SIGUSR1告知旧应用进行接力退出正常终止SIGTERM在交接超时后请求正常结束强制终止SIGKILL在正常终止仍超时后强制结束整个流程的时间配置如下阶段时长交接等待时间5 秒正常终止等待时间30 秒强制终止等待时间5 秒进程状态轮询间隔50 毫秒空进程快照确认间隔100 毫秒也就是说新的实例接力流程首先给旧实例 5 秒时间处理交接若旧实例没有退出再给予最长 30 秒的正常终止阶段如果依然无法退出则再进行最长 5 秒的强制终止等待。这种顺序体现出应用优先尝试交接与正常退出而不是一开始就直接终止进程。八、为什么需要两次确认“没有其他进程”更新中的同步屏障并不会在第一次发现“没有其他应用进程”时立刻认为交接完成。代码要求连续两次获得空的进程快照才认为其他实例已全部退出。这一机制是为了应对 macOS 工作区进程快照并非原子操作的情况。某个进程在系统进程列表中出现的时机可能存在延迟如果只依赖一次空快照就有可能让尚未完全被发现的实例绕过同步屏障。因此逻辑会先记录已经看到一次空快照然后等待一个稳定时间再进行一次检查。只有第二次仍然为空才返回成功。这样做可以提高多实例交接过程中的稳定性降低旧实例刚好在系统中延迟出现的风险。九、代码明确保留的边界两个并发启动实例可能同时通过虽然同步屏障机制已经明显增强但代码中也明确说明了一个仍未处理的边界情况。由于 macOS 的工作区快照不是原子操作如果两个应用实例几乎同时启动且两者在检测时都还没有出现在对方的可见进程列表中那么两个实例都有可能通过屏障。也就是说这个极端并发启动窗口被明确标注为暂未处理。这一说明反映出本次更新对已知限制保持了明确边界它处理了已发现实例的交接、退出与接管问题但没有宣称完全消除所有极端并发启动时序问题。十、进程存活检查更严格防止误操作被复用的进程号在停止 macOS 应用进程前新的代码不会直接根据进程号发送信号而是先确认目标身份仍然匹配。处理流程包括根据目标进程号读取系统进程信息。如果进程不存在则视为已经退出。如果进程存在则比较当前读取到的进程身份与此前记录的身份。只有进程号与启动时间都一致时才认为该目标仍是原来的 Ollama 应用进程。只有确认目标仍在运行时才发送对应的关闭信号。这种做法避免了一个重要问题旧进程退出后系统可能重新分配同一个进程号。如果仅依赖进程号就有可能将信号发送给并非原来的目标进程。更新后通过进程号加启动时间的双重校验确保强制终止等操作只作用于预期的存活身份。十一、交接信号到达后先停止 Claude 代理再进行退出应用运行期间会监听交接信号。当收到交接信号时逻辑会依次执行记录收到应用交接信号并准备关闭。停止 Claude 应用代理。执行用于交接的退出流程。原有流程中接收到交接信号后会停止 Claude 应用代理、调用原生退出逻辑并执行交接退出。更新后不再在该处直接调用原生退出而是进入统一的交接退出路径。新增的交接退出函数会先将一个全局原子状态设置为真标识“应用交接正在进行”再调用通用退出流程。这一变化的重要点在于应用退出不再只依赖实时检测是否有另一个 Ollama 实例运行而是通过明确的交接状态保存当前退出的原因。十二、Claude Desktop 配置恢复逻辑调整接力退出时不再被后续信号干扰本次 macOS 交接修复中还涉及 Claude Desktop 配置恢复逻辑。更新前应用退出时会调用原生层逻辑检查是否存在其他 Ollama 实例运行并将结果作为是否处于交接状态的依据。更新后退出逻辑不再通过该方式动态判断而是读取全局原子状态appHandoffInProgress.Load()该状态会在执行交接退出时提前设置。代码注释指出一旦替换交接已经开始之后到来的关闭信号不应使 Claude 配置在新应用运行期间被重新恢复。换句话说当旧实例已经确认要交接给新实例时退出过程必须维持这一状态避免后续关闭流程错误地将 Claude Desktop 从 Ollama 网关配置恢复回原状态从而影响新实例的工作。这也是此次 macOS 多实例修复的重要配套调整不仅要确保旧应用退出还要确保退出过程中的 Claude 代理配置不会破坏新应用接管后的状态。十三、Claude Desktop 退出恢复逻辑简化本次更新还简化了 Claude Desktop 退出前恢复配置的函数参数。原先的恢复判断函数会接收两个状态是否正在交接。是否已经配置。更新后该函数只保留“是否已经配置”这一项。新的逻辑变为如果未配置 Claude Desktop 网关则不执行恢复。如果已经配置则执行恢复操作。交接状态不再由该函数自行判断而是通过前面提到的应用交接全局状态统一控制退出流程。这使配置恢复的职责更加集中恢复函数只负责根据是否配置决定是否恢复是否属于交接退出则由应用的退出状态来管理。十四、Claude Desktop 云模型账户模型会被纳入可用模型列表v0.33.2 增加了 Claude 的账户云端模型列表能力。在 Claude Desktop 启动目录解析流程中应用会尝试加载账户云端模型。如果加载失败会记录调试日志如果加载成功则将云端模型库存并入当前可用模型集合。更新前合并云端模型时存在不同的参数控制方式例如是否追加缺失模型。更新后这一参数被移除合并逻辑统一为mergeClaudeDesktopCloudInventory(available,cloudModels)新的合并逻辑会根据云端模型库存验证已有模型。记录已出现的模型名称。遍历账户云端模型。对于当前列表中还不存在的云端模型将其加入结果。返回包含可用模型与账户云端模型的统一列表。这意味着账户中可使用的云端模型会被补充到 Claude Desktop 的可用模型目录中。十五、模型目录刷新时可用模型与可选模型统一处理在 Claude Desktop 启动时原先逻辑会根据是否存在显式云端模型名称决定可选模型集合是否需要采用不同的合并方式。更新后逻辑被统一加载到账户云端模型后先合并至可用模型列表。可选模型列表直接使用合并后的可用模型列表。也就是说不再区分“仅验证已有模型”与“追加缺失模型”的两条分支而是统一使用完整合并后的模型目录。在模型目录刷新流程中也进行了相同调整。当云端库存已知时应用会将云端模型统一合并到可用模型中。当当前模型与账户模型在名称或 Ollama 模型字段上匹配时也会将对应账户模型以统一方式合并到可用模型中。这使 Claude Desktop 对账户云端模型的识别与展示逻辑更加一致。十六、模型合并函数变化不再保留“是否追加缺失项”开关原有的云端模型合并函数带有一个布尔参数用于控制是否追加当前列表中缺失的云端模型。更新后这个参数被移除。新的函数始终执行以下两步使用云端模型库存校验已有模型。将未出现在已有结果中的云端模型补充进去。因此账户云端模型不再只在某些特定分支中被追加而是统一进入模型合并结果。这一修改影响了以下场景Claude Desktop 启动时的模型目录解析。Claude Desktop 运行过程中的模型目录刷新。当前模型与账户模型匹配时的更新。Claude Desktop 模型选择时的可选模型生成。十七、Claude Desktop 模型选择统一使用账户云模型后的可选集合在 Claude Desktop 模型映射应用流程中如果成功获取到账户云端模型新的逻辑会将现有可用模型与云端模型进行统一合并并将合并结果作为可选模型集合。之后系统会根据当前模型、已知本地模型和映射配置执行已知 Claude Desktop 模型映射。完成映射后验证流程也发生了变化。原先验证函数会同时考虑访问状态、本地模型名称以及本地模型加载是否成功等条件。更新后映射后的模型会进入一个新的可用性保障流程ensureClaudeDesktopModelsAvailable(context.Background(),selected)这一变更将模型可用性确认放入专门的保障函数中处理。从变更关系看模型选择流程不再直接使用原有的综合验证调用而是通过新的可用性确认步骤处理已选择模型。十八、代理目录更新不中断请求本次版本的重要稳定性修复发布说明中明确指出Claude Desktop 代理在模型目录更新时不再中断正在进行中的请求。模型目录更新通常涉及以下内容可用模型列表变化。账户云端模型信息加载。本地模型与云端模型的合并。Claude Desktop 模型映射刷新。当前模型目录的验证与更新。本次更新将云端库存合并、当前模型匹配和模型可用性保障等逻辑进行调整使模型目录更新能够与已经在进行中的代理请求更好地共存。对于 Claude Desktop 代理而言这意味着模型目录刷新不再需要以打断当前请求为代价。正在执行的请求可以继续完成而模型目录变化则在后续流程中生效。十九、深色模式恢复应用重新跟随系统外观v0.33.2 的另一项直接可见更新是应用恢复系统外观跟随能力。发布说明中指出Ollama 应用现在再次遵循系统外观从而恢复深色模式支持。这项更新的核心内容并不是增加新的主题配置入口而是恢复应用根据系统外观自动适配的行为。当系统使用深色外观时应用能够使用对应的深色模式当系统采用其他外观时应用也恢复与系统保持一致。这一调整使应用界面行为重新符合系统级外观设置。二十、代码维护清理无效代码与修复代码检查问题除了功能修复外本次版本还包含两项维护类提交清理无效代码。修复代码检查问题。这两项改动在发布记录中被单独列出说明 v0.33.2 也同步进行了代码层面的整理。无效代码清理有助于减少不再使用的实现残留代码检查修复则用于使代码符合现有检查规则。它们与应用启动、代理稳定性和模型目录能力一起构成了本次版本的完整更新内容。二十一、v0.33.2 变更总结代码地址github.com/ollama/ollamaOllama v0.33.2 的更新重点集中在三个方向应用界面适配、macOS 实例管理、Claude Desktop 代理稳定性。更新方向本次变化系统外观应用再次跟随系统外观恢复深色模式支持macOS 启动修复已运行实例的交接问题避免错误启动第二个实例进程同步引入进程身份、启动时间排序、交接与终止阶段控制退出处理通过交接状态避免退出时错误恢复 Claude 配置Claude 云模型支持列出账户云端模型并统一合并到可用模型目录模型选择模型映射后改为执行可用性保障流程代理稳定性模型目录更新不再中断正在进行中的 Claude Desktop 请求代码维护清理无效代码修复代码检查问题整体来看v0.33.2 对 macOS 应用交接进行了较完整的流程重构从简单处理其他实例升级为带有进程身份校验、最新实例选举、多阶段退出、双重空快照确认和交接状态控制的同步屏障。