macos 屏幕录制权限由 tcc 框架严格管控，因其涉及密码、银行页面等高敏信息，与摄像头同属高风险权限；授权非一次性，受签名验证、路径绑定及终端代理等多重限制，手动勾选和首次触发弹窗为强制安全设计。

macos 对屏幕录制权限的控制非常严格，这不是设置问题，而是系统级安全机制在起作用。它背后是苹果的 tcc（transparency, consent, and control）框架，目的就是防止任意程序偷偷录屏、窃取画面内容。

为什么屏幕录制权限特别敏感？

屏幕内容可能包含密码、聊天记录、银行页面等高度敏感信息。macOS 将“屏幕录制”归类为高风险权限，和摄像头、麦克风、辅助功能同级。一旦授权，应用就能捕获整个桌面或指定窗口——这比普通文件读写危险得多。

• 授权不是一次性的：每次应用更新、重装或 Bundle ID 变更，旧权限自动失效
• 签名验证强制介入：未通过 Apple 公证（Notarized）的应用，即使勾选了权限，也会被系统拦截，显示灰色禁用图标
• 浏览器场景更复杂：网页调用录屏 API（如 MediaDevices.getDisplayMedia）时，实际授权对象是浏览器本身（Chrome、Edge），不是网页

授权过程中的关键安全细节

系统不会让你盲目授权，每一步都有设计意图：

macOS Local Voice

利用 macOS 原生能力实现本地语音识别与合成。通过 yap (Apple Speech.framework) 进行语音转文字，通过 say + ffmpeg 进行文字转语音。完全离线，无需 API 密钥。具备音质检测与智能选声功能。

下载

• 首次触发才弹窗：权限请求只在应用真正调用录屏 API 时出现，避免预授权滥用
• 必须手动勾选：不能通过代码静默开启，用户操作不可绕过
• 路径绑定严格：TCC 数据库记录的是应用的完整安装路径，移动或复制.app 文件会导致权限丢失
• 终端类工具需额外注意：Node.js 脚本、CLI 工具依赖终端应用（Terminal/iTerm2）代为执行，所以要给终端授予权限，而非脚本本身

如何判断授权是否真正生效？

勾选开关 ≠ 功能可用。常见“已授权但黑屏”问题，往往源于缓存或状态错乱：

• 先关闭再重新开启开关：在“屏幕录制”列表中取消勾选 → 等待 3 秒 → 再勾选，强制刷新 TCC 状态
• 检查应用是否从原始路径运行：右键应用 → “显示简介”，确认“位置”与授权时一致
• 终端命令验证：运行 tccutil list ScreenCapture 查看当前所有已授权条目，确认目标应用在列且状态为 authorized
• 重启应用或浏览器：权限变更后不重启，旧进程仍使用旧上下文

不推荐的“捷径”及其风险

有些教程建议直接修改 TCC.db 或关闭 SIP 来强制授权，这些操作存在明显隐患：

• 手动改数据库需先禁用 SIP，这会削弱整个系统防护能力
• TCC.db 格式复杂，字段误写可能导致其他权限异常，甚至影响系统设置面板打开
• 重置命令 sudo tccutil reset ScreenCapture 会清空所有记录，不是修复，而是重来
• 绕过 Gatekeeper（右键“仍要打开”）仅解决签名问题，不解决权限逻辑本身