[Bug] macOS: 硬运行时缺少麦克风 entitlement，语音输入被永久拒绝且不弹授权窗（无用户侧绕过方案）

[Theeffortman]

EN · 中文见下

Summary

On macOS, the shipped 0.1.7-rc.2 build is signed with Hardened Runtime but does not declare the com.apple.security.device.audio-input entitlement. As a result, macOS tccd treats microphone access as a hardened-runtime policy violation: it refuses to even show the permission prompt, and every capture request is denied outright. The user can never grant the permission — the toggle in System Settings → Privacy & Security → Microphone never appears.

I verified that this is not a stale/missing TCC row: manually inserting an allow row into the user TCC database for the app's bundle id (auth_value=2) does not help, because the hardened-runtime entitlement check happens before the database is consulted. So this cannot be worked around from the user side.

Environment

Item	Value
App	DeepSeek Harness.app 0.1.7-rc.2 (official notarized build)
Bundle id	com.deepseek.dsh
Team ID	NAN929V4UM
macOS	26.6.2 (build 25G83), Apple Silicon (arm64)
Feature in use	voice input UI (dsh-experimental-voice-input-bundle)

Evidence

1. Hardened runtime is enabled

$ codesign -dv --verbose=2 "/Applications/DeepSeek Harness.app"
Identifier=com.deepseek.dsh
TeamIdentifier=NAN929V4UM
CodeDirectory v=20500 size=444 flags=0x10000(runtime) hashes=3+7 location=embedded
                                             ^^^^^^^^^^^^^^^^ Hardened Runtime ON

2. The entitlements do not include audio input

$ codesign -d --entitlements - "/Applications/DeepSeek Harness.app"
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.disable-library-validation
# no com.apple.security.device.audio-input

Note that Info.plist does contain NSMicrophoneUsageDescription and NSAudioCaptureUsageDescription — so the intent to use the microphone is clearly there; only the entitlement is missing.

3. tccd denies without prompting (decisive)

tccd[6402] Prompting policy for hardened runtime; service: kTCCServiceMicrophone
  requires entitlement com.apple.security.device.audio-input but it is missing
  for responsible={identifier=com.deepseek.dsh, pid=35214,
     responsible_path=…/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness},
  accessing={identifier=com.deepseek.dsh.helper, pid=51318,
     binary_path=…/Frameworks/DeepSeek Harness Helper.app/Contents/MacOS/DeepSeek Harness Helper}

tccd[6402] Policy disallows prompt for Sub:{com.deepseek.dsh}
  → access to kTCCServiceMicrophone denied

Reproduced 15 times within a few minutes of normal UI usage (just invoking voice input). Both the main process and the audio.mojom.AudioService helper trigger it.

4. A TCC database entry is not sufficient (tested)

I added an allow row for kTCCServiceMicrophone / com.deepseek.dsh (client_type=0, auth_value=2, auth_reason=4) with a csreq blob compiled from the app's actual designated requirement:

$ codesign -d -r- "…/DeepSeek Harness.app"
designated => identifier "com.deepseek.dsh" and anchor apple generic
              and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
              and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
              and certificate leaf[subject.OU] = NAN929V4UM

The row is structurally identical to working rows for other apps (e.g. Chrome's), and it survived a tccd reload — yet the app is still denied. That confirms the gate is the entitlement, not the database. (I removed the row afterwards to leave the machine in stock state.)

Suggested fix

Add the entitlement when packaging the macOS build, for both the main process and the helper that performs capture:

<key>com.apple.security.device.audio-input</key>
<true/>

then re-sign and re-notarize. After that, the normal macOS prompt will appear once, and the app will be listed under System Settings → Privacy & Security → Microphone.

For Electron specifically, the actual capture happens in a helper process (…/Frameworks/<App> Helper.app), so the entitlement must be present there as well — the log above shows tccd blaming the responsible process (com.deepseek.dsh) while the accessing process is com.deepseek.dsh.helper, so both need it.

---

中文

摘要

macOS 官方构建 0.1.7-rc.2 启用了硬运行时（Hardened Runtime），但没有声明麦克风所需的 com.apple.security.device.audio-input entitlement。macOS 的 tccd 会把这种情况判定为「硬运行时策略违规」：连授权弹窗都不允许弹出，每次采集请求都被直接拒绝。用户永远无法授权——系统设置 → 隐私与安全性 → 麦克风 里根本不会出现这个 App。

已排除「TCC 数据库缺行」这一可能：手动为 App 的 bundle id 写入一条 允许 行（auth_value=2）同样无效，因为硬运行时的 entitlement 检查发生在查数据库之前。也就是说，这个 bug 用户侧无法绕过。

环境

• App：DeepSeek Harness.app 0.1.7-rc.2（官方公证包），bundle id com.deepseek.dsh，Team NAN929V4UM
• 系统：macOS 26.6.2 (25G83)，Apple Silicon
• 使用场景：语音输入（dsh-experimental-voice-input-bundle）

证据

1. codesign -dv --verbose=2 → flags=0x10000(runtime)，硬运行时已开
2. codesign -d --entitlements - → 只有 allow-jit / allow-unsigned-executable-memory / disable-library-validation 三条，没有 com.apple.security.device.audio-input（但 Info.plist 里 NSMicrophoneUsageDescription 是有的，说明只是漏了 entitlement）
3. tccd 日志：requires entitlement com.apple.security.device.audio-input but it is missing → Policy disallows prompt → denied，几分钟内复现 15 次
4. 手动补 TCC 允许行（csreq 由该 App 的真实 designated requirement 编译而来，结构与其他可用 App 完全一致）仍然被拒 → 瓶颈是 entitlement，不是数据库

修复建议

打包时为主进程与执行采集的 helper 进程都加上：

<key>com.apple.security.device.audio-input</key>
<true/>

然后重新签名并公证。之后正常的系统授权弹窗会出现一次，App 也会出现在「隐私与安全性 → 麦克风」列表中。

Electron 场景要注意：实际采集发生在 helper 进程（…/Frameworks/<App> Helper.app），而日志显示 tccd 追责的是 responsible 进程（com.deepseek.dsh）、实际访问者是 com.deepseek.dsh.helper，所以两边都需要这条 entitlement。