https://github.com/govijr/terminal-mac

回复 joye： 看过了。这个项目解决的是 cu 里最难处理的一层，即权限归属。它用 Apple Virtualization 建了一台真正独立的 macOS 虚拟机，agent 操作的是 guest 里的那个 Mac；宿主自己的桌面、剪贴板、摄像头和麦克风，一样都没有交给它。你关心的“Apple 用户级权限”，它的实现方式是用独立用户来规避，并没有试图去破解 TCC。 机制上分三段： 一是宿主侧。用 Swift 调用 Apple Virtualization framework 启动一个 macOS guest，`terminal-mac up` 会自动从 Apple 下载 restore image、安装、启动，并检查 guest helper。宿主不需要任何隐私权限。 二是 guest 侧。guest 里安装一个 TerminalMacGuest.app，用 ScreenCaptureKit 抓屏，并注入点击和按键。这个 helper 一启动就会检查 `hw.model` 是否以 VirtualMac 开头，如果不是就拒绝运行。这一条是防止 agent 命令在宿主上误执行，README 自己注明这不是硬件认证，也挡不住已经被攻破的宿主。 三是通道。宿主和 guest 之间只有两个显式共享目录：`control` 用于读写请求与回复的 JSON，`tools` 只读，放 helper。主机没有远程控制端口的监听器，flat mailbox（扁平的请求/回复信箱）会固定目录、拒绝读取 symlink 和 hardlink、限制消息大小、校验 request ID，并对过期请求超时。宿主从不执行 guest 提供的内容。 所以你问的权限问题，它的答案是：guest 是另一台 Mac，有自己的 App、文件和账号，权限要装好之后在 guest 里单独授予，需要手动给 helper 开启屏幕录制和辅助功能；宿主完全不需要这些权限。 值得称赞的地方：把“主机的辅助功能权限”这个最容易出事的风险点挪到 guest 里，是设计方向上的正确选择。多数 cu 方案要么使用宿主上的 Accessibility API，要么使用浏览器/虚拟显示，权限和用户数据是混在一起的，一旦 agent 出错就可能影响真实设备。它用一个一次性投入的开销，换取权限边界的清晰划分。 实际用起来有三个硬性约束： 一，只能跑在 Apple silicon + macOS 14 以上。依赖 Virtualization framework，Intel 机器无法运行。 二，磁盘和首次成本。默认 64 GiB 的逻辑盘，首次要从 Apple 下好几个 G 的 ipsw。盘是稀疏的，但会一直增长。 三，隔离程度有上限。默认 NAT 网络下 guest 能上网，也能访问宿主或局域网的服务。README 原话是“这不是网络隔离，也不是能跑恶意代码的加固环境”。想更严格就加 `--offline`，但那样 macOS 的 Setup 流程可能走不通。另外 helper 的 `hw.model` 检查是防误操作，不防被攻破的宿主，也不防 guest 里跑的东西往外串。 还有一个要留意的地方：它现在还是 early release candidate，自签名、没有 Apple 公证；作者自己写“干净 Mac 上的实机验收仍在等”。自动化测试只覆盖 mailbox 往返、过期清理、文件边界、名字和选项校验这些协议层，不证明 guest 真的装好了、启动成功、权限授过。128 star 的小项目，八个提交。 对比一下：你在群里讨论的 OpenBot 那种常驻云电脑类的方案，是拿一台真实机器给多 bot 共用，隔离靠账号和策略；这个是把整台 Mac 复制一份，每份独立开。前者的瓶颈是共享资源被互相污染，后者要付出的是宿主机资源被大量占用：虚拟机仍然占用 CPU、内存和磁盘。如果要给多个 agent 分别建环境，一台 M 系列 Mac 最多撑两三个这样的 VM。 这个仓库的价值在于它把边界命名得很清楚，并非作为马上可上生产用的产品。我把“guest 权限要装好之后手动授、宿主不需要任何隐私权限、不防恶意代码”这套讲法记一下？另外它有个姊妹项目 terminal-phone（iOS 模拟器和 iPhone），如果你要看那一边我也可以拉下来。