主应用包内嵌辅助bundle执行AppleScript报-1743未授权向Finder发Apple事件

你已经排除了沙盒开关、基础权限配置、独立启动场景的问题，这类“单独跑全正常、嵌进主包就报无权限”的问题，基本都是macOS TCC隐私系统的进程身份识别逻辑导致的，常见的具体坑点有这几个：

• 权限申请的主体完全错位
  从macOS Catalina开始，TCC对应用自动化权限的校验，根本不会把主应用包内嵌的辅助组件单独算成申请主体。只要辅助组件的签名和主应用匹配、放在系统约定的辅助组件路径下，它发起的所有Apple Event请求，都会被系统算到主应用的签名身份头上。
  你之前单独测试时，系统把辅助bundle当独立可执行程序处理，加上Xcode调试启动会临时绕过TCC校验、命令行启动的程序本身校验逻辑更宽松，自然所有场景都正常；但当辅助bundle嵌在主包里被正常启动时，之前给辅助bundle单独授的权根本匹配不上——因为现在的权限申请主体已经变成了主应用，而主应用本身从来没拿到过向Finder发事件的权限，自然触发-1743错误。
• 辅助组件的身份根本没被系统识别
  如果你把可执行的辅助bundle随便塞在主应用的Resources目录下，没放到系统约定的辅助组件路径（比如Contents/Helpers、Contents/Library/LaunchServices），同时辅助bundle本身的包结构不完整（缺自己的Contents/Info.plist），系统根本没法正常判定它的“责任进程”：既不会把它当独立程序对待，也不会把它归到主应用的权限上下文里。
  这种场景下TCC会直接走默认拒绝逻辑，哪怕你给辅助bundle配了所有需要的entitlements、写全了使用说明，系统也不会认，因为它根本找不到这个请求对应的有效权限记录。
• 打包流程直接把辅助组件的权限配置覆盖了
  主应用打包时，Xcode默认会对主包内的所有组件用主应用的签名配置重新签名。如果你没有单独给辅助bundle指定专属的签名和entitlements配置，之前给辅助bundle配的Apple Events相关权限会被直接覆盖成主应用的配置。
  这也是为什么你单独从Xcode、命令行跑辅助bundle时一切正常——那时候用的是辅助bundle自己的原始签名和权限；一旦打进主包被重新签名，辅助bundle带着被覆盖后的空权限配置去发Apple Event，必然被拦截。
• TCC数据库的脏缓存冲突
  你之前单独测试辅助bundle时，系统已经在本地TCC数据库里存了它的路径、签名对应的权限记录。当它被移到主应用包路径下运行时，系统会因为部分签名信息重合出现身份映射冲突：既不匹配独立程序的旧记录，也不建立主应用的新记录，直接拒绝所有权限请求，甚至不会在系统设置的自动化列表里显示你的应用条目。

• 先确认系统对辅助进程的责任身份判定：找到辅助进程的PID后执行ps -o responsible_pid,executable,label -p <PID>
  • 如果输出的label是主应用的签名ID，说明权限归属已经完全转移到主应用，只需要在主应用的entitlements里加上对应的Apple Events权限配置，重新安装主应用触发系统授权弹窗即可。
  • 如果输出的label为空或者是无意义的字符串，说明辅助组件位置不对：把结构完整的辅助bundle移到Contents/Helpers目录下，别把可执行文件直接扔在Resources根目录。
• 校验打包后辅助bundle的实际权限配置：执行codesign -d --entitlements - <主app路径>/Contents/Helpers/<辅助bundle路径>，确认输出的权限没有被主应用打包流程覆盖掉。
• 清理冲突的权限缓存：执行tccutil reset AppleEvents <你的应用签名ID>清掉之前的无效权限记录，重新启动应用触发授权流程。
• 从根源绕开权限依赖：你现在的脚本核心逻辑是删除其他应用bundle，根本没必要通过AppleScript给Finder发事件，直接用NSFileManager的接口删除目标路径就行，连Apple Events的权限请求都不需要，自然不会触发这类权限问题。

额外提个很多人踩过的误区：不少开发者以为辅助bundle的权限是独立的，实际上macOS从Catalina版本开始，只要是主应用包内和主应用签名匹配的组件，权限都是统一挂在主应用名下的，根本不存在内嵌组件单独申请权限的逻辑。

内容的提问来源于stack exchange，提问作者mezo