WorkBuddy 启动提示“无法访问 ~/Documents”是因未获macOS 12+的“完整磁盘访问”授权，需在系统设置→隐私与安全性中手动添加/Applications/WorkBuddy.app并勾选；写入受保护路径报“Operation not permitted”应改用~/.applicationSupportDirectory等安全路径；拖拽无响应需检查Info.plist UTI声明及NSDraggingDestination实现；iCloud文件读取失败须用NSFileCoordinator协调且避免直连路径。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 启动后提示 “无法访问 ~/Documents”
这是 macOS 12+ 系统下最常见的权限问题，根本原因不是 WorkBuddy 没有权限，而是它没被明确授予「完整磁盘访问」或「特定文件夹访问」——macOS 默认禁止沙盒应用读写用户文档目录，哪怕路径看起来合法。
解决方法不是点「允许」弹窗就完事，必须手动进系统设置补全：
- 打开 系统设置 → 隐私与安全性 → 完整磁盘访问，点击右下角锁图标输入密码解锁
- 点击「+」号，用快捷键
Cmd+Shift+G调出前往文件夹窗口，输入/Applications/WorkBuddy.app并回车选中 - 确保勾选了
WorkBuddy.app左侧复选框；如果列表里已有但未勾选，勾选后需重启 WorkBuddy 才生效 - 若只希望限制访问范围（比如仅允许读写
~/Projects），则改去「文件和文件夹」→「文档文件夹」或「其他文件夹」里添加对应路径
WorkBuddy 保存文件时抛出 Operation not permitted
这个错误几乎都发生在尝试写入受保护路径时，比如 /usr/local/bin、/Library/Application Support 或任何非用户主目录下的位置。WorkBuddy 默认以普通用户身份运行，没有 root 权限，也无法绕过 SIP（系统完整性保护）。
正确做法是调整目标路径，而非强行提权：
- 避免硬编码系统级路径；改用
NSFileManager.default.urls(for: .applicationSupportDirectory, in: .userDomainMask)获取安全的 App 支持目录（如~/Library/Application Support/WorkBuddy） - 如果必须导出到桌面或文档夹，请先检查是否已获得对应文件夹授权（见上一节），再调用
URL.startAccessingSecurityScopedResource()（适用于通过 Open Panel 选取的路径） - 不要在代码里调用
sudo或尝试AuthorizationExecuteWithPrivileges—— macOS 不允许沙盒应用执行此类操作，会直接崩溃
拖拽文件到 WorkBuddy 窗口后无响应
这通常不是权限问题，而是拖放目标未正确声明支持的 UTI 类型，或未启用沙盒下的「辅助功能」权限（用于监听全局拖拽事件）。
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
开发者侧需确认两件事：
- 在
Info.plist中声明所需类型，例如添加CFBundleDocumentTypes并包含LSTypeIsPackage、LSItemContentTypes等键，否则 macOS 会静默过滤掉不匹配的拖入项 - 若依赖
NSDraggingDestination协议实现自定义拖放逻辑，确保draggingEntered(_:)返回有效值，并在performDragOperation(_:)中及时调用URL.stopAccessingSecurityScopedResource()释放资源引用 - 终端命令
tccutil reset All com.workbuddy.app可重置所有隐私授权，适合调试时快速清空状态（需重启 app）
WorkBuddy 读取 iCloud 同步文件夹失败
iCloud Drive 下的文件（如 ~/Library/Mobile Documents/com~apple~CloudDocs/）受额外一层协调机制约束。即使已开启「完整磁盘访问」，WorkBuddy 仍可能因文件处于「待同步」或「仅在线」状态而读取为空或报错 NSFileReadNoSuchFileError。
稳妥方案是避开直接访问 iCloud 路径，改用系统 API：
- 使用
NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)获取默认文档路径（指向 iCloud 启用时的同步位置） - 对文件操作前，务必用
FileManager.default.isUbiquitousItem(at: url)判断是否为 iCloud 文件；若是，优先走NSFileCoordinator协调读写，而不是直连FileManager - 不要假设
url.lastPathComponent在 iCloud 中一定可读——某些文件可能仅缓存元数据，真实内容需显式下载，调用NSFileManager.default.startDownloadingUbiquitousItem(at: url)并等待完成回调
iCloud 的延迟同步和本地缓存策略会让路径行为变得不可预测，最省事的方式其实是让用户自己从 Finder 拖入文件，由系统自动处理安全作用域和下载调度。
