There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . xxxxxwater Sep 30, 2026 我在 Intel Mac（ x86_64 ，macOS 26.6）上使用 DeepSeek Harness Desktop。查看 dsh-v0.2.0-rc.2 Release 时，页面的 Assets 列表为空，找不到 Intel macOS 安装包，因此容易误以为新版不再支持 Intel Mac。相关疑问也见 #8328 。 但在 2026-09-30 核对官方发布源后，发现 rc.2 的 Intel 包实际上已经存在 ： 官方 Intel DMG： https://download.deepseek.com/dsh-desk/bin/mac-x64/deepseek-harness-0.2.0-rc.2-mac-x64.dmg （HTTP 200， 386,418,433 字节）。 官方 mac-x64 更新清单： https://download.deepseek.com/dsh-desk/feeds/mac-x64/nightly-mac.yml （显示 version: 0.2.0-rc.2 ）。 rc.2 发布说明也明确提到了 Intel Mac 内置 Node 的签名权限修复。 所以这里更准确的问题是： 官方 Intel 构建已发布，但 GitHub Release 页面缺少可见下载入口和校验信息 。希望维护者把 mac-x64 的官方安装包入口、最低系统版本、签名/公证状态及校验值放到 Release 说明或下载页，让 Intel 用户能直接找到并确认来源。我目前安装运行的是官方签名、公证的 0.2.0-rc.1 ；尚未把 rc.2 安装到本机，因此以下不宣称 rc.2 的运行结果。 我在 Intel Mac 上做过的本地打包方案 在官方桌面安装包不易找到时，我曾从仓库的 dsh-v0.1.6-alpha.2 源码在 Intel Mac 上自行构建 mac-x64 DMG。这个方案是旧版的本地复现经验， 没有在 rc.2 源码上重新验证，也不是官方发布包 ；愿意把思路供维护者和社区参考： 固定 DSH_DESKTOP_TARGET_PLATFORM=darwin 、 DSH_DESKTOP_TARGET_ARCH=x64 ，运行仓库的 build:official ，并打包 dsh、desktop-host、vendor 与 native/system 依赖。 依次执行 prepare:runtime 、 prepare:packages 、 prepare:dsh ，保证 Electron、Node、Python、原生模块和插件运行时进入同一个目标目录。网络受限时，我把下载源改为可达镜像，但 仍以仓库 lock 文件中的 SHA-256 校验每份运行时资产 ；仅校验一致才写入缓存。npm 镜像通过本地 DSH_DESKTOP_RUNTIME_REGISTRY 配置传给内部 pnpm 安装步骤。 使用 electron-builder 针对 darwin/x64 生成应用目录，再做本机 ad-hoc 签名、 codesign --verify --deep --strict 、 hdiutil create 和 hdiutil verify 。当时生成的本地 DMG 约 470 MB， hdiutil verify 通过。 我本地脚本中的关键构建顺序如下（省略个人绝对路径；需先安装仓库要求的构建依赖，并使用同版本源码）： 随后我的 本地专用 electron-builder 配置指定 mac-x64 的 Electron/运行时目录、 identity: null 、 notarize: false 和 --mac --x64 --dir --publish never ；对产出的 .app 执行 ad-hoc codesign 并封装 DMG。镜像下载只有在 SHA-256 与锁文件一致后才进入缓存。这个配置和跳过正式签名的改动只为本地验证，不能替代官方发布配置。 本地 ad-hoc 包 未经过 Developer ID 签名与 Apple 公证 ，Gatekeeper 体验与官方包不同，不能当作面向普通用户的下载包。正式发布仍应沿用仓库的签名、公证和 mac-x64 上传流程。若需要，我可以在回复中提供已去除本机路径的构建脚本和最小本地改动；核心改动只是允许镜像 registry，以及在没有 Developer ID 凭据的本地构建中跳过正式运行时签名。 另外几项兼容经验 / 希望确认 从早期自打包版本升级到官方 Desktop 时，Bundle ID 从 com.deepseek.harness 变成 com.deepseek.dsh ，macOS 将其视作另一个应用，磁盘/麦克风/屏幕录制等系统权限可能要重新授权。希望升级说明显式提示用户，并建议先备份 ~/.dsh 。 我在 rc.1 环境遇到过旧版第三方插件的 peer dependency 不覆盖 0.2.0-rc.1 ，插件管理器会判为不兼容。这是插件版本声明问题，建议文档明确“插件不兼容”与“桌面端不支持 Intel”是不同情况。 rc.2 发布说明提到 Intel 内置 Node 的签名权限和图形入口的 login-shell 环境修复。希望有 Intel 真机验收结果，尤其是 Office 技能命令、PATH/代理读取及从 rc.1 升级后的会话/权限表现。 欢迎维护者和 Intel Mac 用户补充 rc.2 的实际安装、签名、公证及升级结果。 English summary: The official rc.2 macOS x64 DMG and update feed are live, but the GitHub Release has no downloadable assets or visible Intel link. I also shared a verified local mac-x64 packaging approach from an older source tag, clearly separated from the official signed/notarized distribution, plus upgrade and plugin compatibility observations. I have not yet runtime-tested rc.2 on this Mac. Replies: 2 comments There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . xxxxxwater Sep 30, 2026 Author Update: I continued validating the official dsh-v0.2.0-rc.2 Intel macOS build on my Intel Mac. Verified so far Downloaded the official rc.2 mac-x64 DMG . The disk image passed macOS DMG verification. The application inside the DMG reports dsh-v0.2.0-rc.2 and is built for x86_64 . Developer signature verification passed. macOS notarization / Gatekeeper assessment passed. Before upgrading, I backed up both the previous rc.1 application and the existing DeepSeek Harness user data, sessions and configuration. rc.2 has now been installed into the original application location while keeping the previous application and user-data backups. Correction / clarification to my original report The official Intel build itself does exist . The main issue appears to be distribution/discoverability: the GitHub Release page for dsh-v0.2.0-rc.2 does not clearly expose the Intel macOS download asset, while the official x64 DMG is available from DeepSeek's download infrastructure. Therefore this is different from “rc.2 does not support Intel Macs”. At the packaging level, I can now confirm that the official rc.2 build is: Intel x86_64 → validly signed → notarized → installable on macOS. Runtime compatibility validation I am continuing the runtime-level validation rather than treating successful DMG installation as sufficient. The next checks include: desktop main-process stability renderer-process stability bundled runtime/helper-process architecture existing session/config migration from rc.1 to rc.2 whether previous conversations remain accessible startup/relaunch loops native dependency compatibility on Intel unexpected crashes after prolonged runtime compatibility differences between the official rc.2 binary and my locally packaged build My local packaging approach is still useful for Intel users when an official binary is difficult to discover, or when source-level compatibility fixes are required, but the official rc.2 x64 binary should now be considered the baseline for further testing. I will keep packaging/distribution problems separate from actual Intel runtime compatibility problems in the follow-up results. There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . xxxxxwater Sep 30, 2026 Author Another important update from my Intel macOS / dsh-v0.2.0-rc.2 testing. The Intel x86_64 package itself installs correctly, passes signature/notarization checks, and can launch. However, I have now found a more serious runtime compatibility problem: rc.2 can enter a persistent crash/restart loop when third-party plugins or third-party registry state are restored In my local environment I tested rc.2 together with third-party DSH ecosystem sources such as: awesome-dsh-plugin.com After third-party plugin/registry state is introduced, rc.2 may no longer remain stable. The observed behavior is approximately: In other words, the problem is not simply: “one plugin does not work” The more serious problem is: one incompatible third-party plugin or registry state can make the entire rc.2 Desktop application repeatedly crash on every startup. Current recovery workaround At the moment, the reliable way I found to recover the application is effectively: So for affected users the current practical choice appears to be: either remove the third-party ecosystem integration, or remain stuck in the restart loop. This is particularly problematic because the application automatically restores the same state that caused the previous crash. This looks like a startup isolation problem, not only a plugin compatibility problem I think rc.2 should assume that a third-party plugin can be broken, outdated, built for another Harness version, contain an incompatible native dependency, or fail during initialization.

That failure should not be allowed to take down the whole Desktop host. The desired failure model should look more like: Possible trigger areas I have not yet isolated the exact code path, but several areas look worth investigating. 1. Plugin restore happens too early during application startup If persisted plugins are restored before the Desktop reaches a stable state, one plugin initialization exception may become fatal to the complete startup sequence. A safer sequence would be: Third-party plugin activation should probably happen only after the core application is already recoverable. 2. No crash-loop breaker rc.2 appears to restore the same plugin state after a failed launch. There should be a persistent startup health marker. If the next launch finds: then Harness knows that the previous launch died during startup. It could automatically enter: and skip third-party plugin activation. 3. Third-party plugin initialization is insufficiently isolated A plugin initialization error should ideally be caught at the plugin boundary. Something conceptually similar to: A malformed plugin, incompatible dependency or initialization failure should not terminate the Desktop process. 4. Registry discovery and plugin execution should remain separate as discovery sources should not itself cause arbitrary plugin code to execute during application startup. I would strongly separate: into different phases. A failure in registry synchronization should produce something like: 5. rc.1 → rc.2 migration may restore incompatible state Because this test also involves an upgrade from rc.1 to rc.2, another possibility is that rc.2 reads persisted plugin state created under the previous runtime. Something like: If so, plugin state probably needs an explicit schema/runtime compatibility check during migration. I think Desktop should have a built-in recovery mechanism before rc.2 becomes a stable release. Safe Mode should: disable all non-official plugins temporarily; disable third-party registry synchronization; preserve the plugin files rather than deleting them; allow the user to inspect the failure; allow plugins to be re-enabled one by one. 2. Automatic plugin quarantine If plugin activation terminates unexpectedly: rc.2 could automatically mark it: and continue launching. The UI could then show: This plugin was automatically disabled because it caused an error during the previous startup. 3. Crash-loop detection should trigger: The application should stop automatically relaunching the same broken configuration indefinitely. 4. Last-known-good plugin configuration Desktop could maintain: After a successful startup: After a startup crash, the user could restore the previous known-good configuration. This would make experimentation with community plugins much safer. 5. Per-plugin compatibility metadata Before activating a plugin, Desktop should check at least: For my environment specifically: A plugin built only for arm64 should never reach the activation stage on this machine. It should instead be reported as: 6. Better startup diagnostics When a crash occurs, it would be extremely helpful if rc.2 preserved something like: Ideally the log should identify the last plugin being activated immediately before the crash . That would make it much easier for community users to provide actionable reports. At this point my Intel rc.2 testing shows two separate results. Packaging / Intel support This part works: Third-party ecosystem compatibility This is where the current problem appears: So I would no longer describe the Intel problem as simply “there is no Intel build”. There is an Intel build. The more important remaining rc.2 issue is that third-party plugin compatibility failures can currently become application-level failures instead of isolated plugin-level failures . Minimal reproduction pattern from my environment The general reproduction pattern is: I am continuing to narrow this down to determine whether the fatal path originates in: one specific plugin; plugin manifest parsing; registry synchronization; rc.1 → rc.2 state migration; an x64 native dependency; plugin-host process handling; renderer initialization; or Desktop's automatic restart behavior. But regardless of the specific plugin responsible, I think a third-party plugin should never be able to permanently trap Desktop in a crash/restart loop . That recovery boundary is the main issue I would like to raise for rc.2 before stable release.