Computer Use: mac-x64 desktop build ships no native helper (ENOENT dsh-cua-native), and enabling it on unsupported macOS breaks unrelated status reads

[DEVbyQIN]

Summary

On the mac-x64 DSH Desktop build, enabling Computer Use (@deepseek-ai/dsh-cua-bundle)
fails because the native helper is missing from the shipped app.asar, and the failure
surfaces as a burst of unrelated-looking errors (all cuaAccess queries unavailable,
plus "cannot read PTC execution mode"). This host also runs macOS 13.7.1, which the
helper's README says is below its minimum (macOS 14+), so two separate issues overlap:
a packaging gap and a missing platform gate.

Environment

• DSH Desktop 0.2.1-rc.4 (nightly mac-x64 feed), /Applications/DeepSeek Harness.app
• macOS 13.7.1 (22H221), arch x86_64 (Intel i5-7267U) — cannot be upgraded to macOS 14
• Bundled CLI reports 0.2.1-rc.4
• Enabled via: Plugins → Add plugin → @deepseek-ai/dsh-cua-bundle → Install → Enable now

Expected

Either Computer Use works, or enabling is refused up front with a clear
"unsupported on this host" reason (the bundle README states:
"其他 Host 默认不在插件列表和模型推荐中展示此组合包，并在保存设置前拒绝启用").

Actual

1. Plugin card shows 异常:

   ENOENT, dsh/node_modules/@deepseek-ai/dsh-experimental-cua-macos/native/bin/darwin-x64/dsh-cua-native
   not found in /Applications/DeepSeek Harness.app/Contents/Resources/app.asar

2. Detail page shows a chain of failures, all from the missing native service:

   无法读取 PTC 执行方式，请在设置中检查
   无法检测权限：typert gateway: cuaAccess/systemStatus: active Service "cuaAccess" is unavailable
   无法读取应用授权：typert gateway: cuaAccess/applications: active Service "cuaAccess" is unavailable
   无法读取应用图标：typert gateway: cuaAccess/applicationIcons: active Service "cuaAccess" is unavailable

   Accessibility / Screen Recording rows stay at "未确认" because status cannot be queried.

Evidence that the helper is not in the package

Inspecting the installed Resources/app.asar (file index only):

• @deepseek-ai/dsh-experimental-cua-macos/native/bin/ → 0 files
• No entry anywhere in the archive matches dsh-cua-native
• The package ships native/Package.swift, native/Sources/CuaNative/*.swift,
  native/LICENSE.cua-driver, and lib/index.js — sources and JS, but no prebuilt binary

@deepseek-ai/dsh-experimental-cua-macos/README.zh.md says:

本包是仅限 macOS 的可选依赖。打包前需在 native/bin 下准备对应架构的可执行文件，
该目录会包含在发布包中。安装版需要准备好的 helper，不会编译 Swift。

So the packaging step that should place native/bin/darwin-x64/dsh-cua-native did not
run for this build (or only an arm64 artifact was produced). We cannot verify the arm64
package from here, but the x64 artifact is definitely missing it.

The native helper README also states it supports macOS 14+ (Swift 6, ScreenCaptureKit).
This host is 13.7.1 and cannot be upgraded; the local toolchain is only Command Line
Tools Swift 5.8.1, so building the helper locally is not an option either.

Requested fixes

1. Ship the x64 helper in the mac-x64 desktop build (native/bin/darwin-x64/dsh-cua-native),
   or if x64 is intentionally unsupported for CUA, don't present the bundle on that arch.
2. Gate enablement properly: check helper presence and macOS version before enabling,
   refuse with a concrete reason, and keep the bundle out of the catalog on unsupported hosts.
3. Isolate the failure: a broken CUA provider should not make unrelated reads fail.
   "无法读取 PTC 执行方式" is collateral — PTC executor state should still be readable.
4. Optional: when the helper is missing, say "Computer Use is not available on this
   build/OS" instead of surfacing a raw ENOENT path.

Workaround

Disable the Computer Use plugin from the Plugins page; the cuaAccess errors stop, and
we expect the PTC execution-mode read to recover as well (to be confirmed after disabling).

[BigUncle]

Confirmed on a supported macOS version — the packaging gap is independent of the 13.x version gate

Same failure, but on macOS 15.8.1 (above the helper's macOS 14+ floor), Intel i9-9980HK, arch x86_64 bare metal — so this is not the OS-version overlap.

• DSH Desktop 0.2.1-rc.4 (nightly mac-x64), bundled Node 24.21.0, Swift 6.1.2 / SDK 15.5
• Identical error: ENOENT … /native/bin/darwin-x64/dsh-cua-native not found in …/app.asar, plus the same cuaAccess/* collateral.

More granular packaging evidence

• The package's asar index has 657 files (lib/index.js, native/Package.swift, 23 × Sources/CuaNative/*.swift, 19 × tests/swift/*.swift, protocol.schema.json, node_modules/zod) and zero entries under native/bin/ — neither darwin-x64 nor darwin-arm64.
• app.asar.unpacked/ carries node-pty, koffi, sherpa-onnx-darwin-x64, so the packager does ship non-asar native payloads; this package just had nothing to carry.
• Loader confirms installs can never self-build: prepareNativeExecutable() compiles only when isSourcePackage() matches a repo checkout, otherwise it does access(path, X_OK) → ENOENT.

The shipped sources build and run on x64 — only the artifact is missing

From the exact sources inside app.asar, on this host:

xcrun swift build --package-path native -c release --product dsh-cua-native --arch x86_64 --disable-sandbox
# complete in 155.69s

Output: 1,093,712 bytes, Mach-O 64-bit executable x86_64, ad-hoc signed, starts and parses args. No external SwiftPM deps. (Note for the build pipeline: --disable-sandbox is needed when the build runs inside DSH's own process sandbox, and the SwiftPM/clang caches must be redirected away from ~/Library.)

Why a user workaround isn't viable

Contents/Info.plist sets ElectronAsarIntegrity (SHA256 of the asar header), so dropping a locally built helper into app.asar / app.asar.unpacked fails the integrity check unless the hash is rewritten and the whole bundle re-signed ad-hoc. This has to be fixed at build time.

Guard worth adding: for non-source packages, assert native/bin/darwin-<arch>/dsh-cua-native exists and is executable for every supported arch, and fail the release otherwise; sign the helper stably, since a changed signature invalidates previously granted Accessibility / Screen Recording TCC entries on each update.