这是前一篇《Codex 可以操作电脑，但还不能和我抢同一个桌面》的补充。
上一篇我写的是一个更粗的判断：普通 Computer Use 操作 macOS 桌面时，容易和用户抢前台窗口、抢键盘焦点、抢 Space。所以短期内，不要把它当成一个可以和你并行使用同一台 Mac 的后台同事。
后来继续试，结论要改得更精确一点。
而是如果 prompt 没写清楚，它经常会选择一条会打扰用户的路径：切 workspace、切 window、activate app、open 前台窗口，或者用脚本把某个窗口拉到前面。
但如果你强制它只走另一条路径，也就是指定 app，读取 accessibility tree，再按 element index 点击、输入、验证，它确实可以操作不在当前 Space 的 app，而且可以不把用户当前 workspace 切走。
Computer Use 至少要分成两层看：全局窗口 / workspace 编排层，以及指定 app 的 accessibility 操作层。这两个东西不能混着用。
第一层是最容易出事的。
比如切 workspace、切 window、打开 Mission Control 、发送 Control+数字、Command-Tab、点击 Dock、activate app、open 前台窗口，或者任何会让目标窗口变 active 的脚本。
这些动作本质上都在改全局桌面状态。
它们不是“只操作 Codex 自己的工作区”，而是在操作用户正在用的那台 Mac。
所以，第一层不是不能用，而是它不适合“后台、不打扰”的任务。它的核心问题不是单个动作准不准，而是这些动作会改变全局焦点、当前 Space 或 active window。
第二层可以不切 Space 操作
真正有意思的是第二层。
这一层不是让 Codex 去切桌面，也不是让它猜窗口在哪个 Space。
而是只指定 app： {"app":"Safari"} {"app":"Google Chrome"}
然后 Computer Use 返回这个 app 的 accessibility tree。接下来只对 tree 里的元素操作：click、type_text、press_key、set_value。
这条路径实测可以不切走用户当前 Space。
关键证据是 Safari 。
用户当时在 ws2 打开了一个 Safari，而且其他 workspace 没有 Safari。用户自己还在 ws1 工作。
Codex 调用 Computer Use 读取 Safari 的 accessibility tree，拿到了 ws2 里 Baidu 页面上的元素：window title 是“百度一下，你就知道”，有文本输入区，有“百度一下”按钮。
然后 Codex 没有切到 ws2，而是直接通过 element index 点击输入框，输入 codex，点击搜索按钮。
用户没有被切走。
这条证据说明：Computer Use 的 app accessibility 操作，不一定依赖“当前屏幕正在显示那个窗口”。它可以操作另一个 Space 里的 app/window。
图 1：Codex 一开始并不知道自己可以在不切换 workspace 的情况下，直接通过 Computer Use 操作另一个 Space 里的 app。
这张截图暴露的是 prompt 问题：如果直接对 Codex 说“操作 ws2 里的 Safari”，模型很容易被 ws2 这个目标带偏，自动进入“先切 workspace，再操作窗口”的思路。
更好的说法不是“去 ws2 做什么”，而是“目标 app 已经打开，只用指定 app 的 accessibility tree 操作；不要切 workspace；如果拿到的不是目标窗口就停止”。也就是说，不要让 Codex 去指定 ws，而是让它指定 app。
上一篇里“普通 Computer Use 会抢桌面”的判断还成立，但要补一句：抢桌面不是 Computer Use 唯一路径。
但它不能指定 ws，也不能指定窗口
这里也不能过度乐观。
Computer Use 现在能指定的是 app，不是 workspace，也不是 window。
当用户 ws1 和 ws2 都有 Chrome 窗口时，get_app_state({"app":"Google Chrome"}) 不是返回所有 Chrome 窗口，也没有参数让你指定 ws2。
它会返回某一个 Chrome 窗口。
再读取 Chrome tree，返回的是 Baidu 窗口。
这里要补充一句：ws2 的 Chrome 是专门拿来测试的窗口，当时只打开了 Baidu。所以返回 Baidu 更像是“Chrome 最近/相关窗口变成了这个测试窗口”，不是 Computer Use 可以直接指定 ws2 或指定 Baidu tab。
所以更准确的理解是：Computer Use 的 app tree 更像是“这个 app 当前 key / focused / 最近使用 / accessibility 认为相关的窗口”。
它不是稳定的 window id API，也不是 workspace = 2 API。
这决定了一个使用前提：如果你想让 Codex 不打扰地操作另一个 Space 里的 app，最好让目标 app 只有一个窗口。
如果同一个 app 有多个窗口，那就要接受一个限制：Codex 只能拿到它拿到的那个最近窗口。如果不是目标窗口，它应该停止，而不是开始切 Space 找窗口。
Ghostty 是另一个边界
这次还有一个容易误读的点：Ghostty。
最开始用户让 Codex 用 Computer Use 在 ws2 打开 Ghostty，运行 pwd。
Codex 调用 Ghostty 的 app state 时返回： Computer Use is not allowed to use the app 'com.mitchellh.ghostty' for safety reasons.
这不是 Space 问题，也不是 Codex 不知道怎么点终端，而是安全策略直接禁止操作 Ghostty。
所以后面 Safari / Chrome 能跨 Space 操作，不代表终端类 app 也能被 Computer Use 操作。
prompt 应该怎么写
如果目标是“不打扰用户”，prompt 不能只写一句“不要打扰我”。
它应该把禁止动作和允许动作都写清楚。
用 Computer Use 操作目标 app，但不要打扰用户当前 workspace。
不要把任务理解成“去某个 ws / Space 里操作”。Computer Use 只能指定 app，不能指定 ws/window。目标 app 应该已经打开；如果返回的不是目标窗口，就停止。
只使用指定 app 的 accessibility 操作层：先调用 get_app_state，只传 app 名或 bundle id；检查返回的窗口标题、URL、selected tab 和关键元素；确认是目标窗口后，只用 element_index 执行 click、type_text、press_key、set_value。
禁止切换 workspace / Space / Desktop，禁止 Control+数字、Control+方向键、F3、Mission Control，禁止 Command-Tab，禁止点击 Dock / 菜单栏 / 窗口标题栏，禁止 activate，禁止 open / open -a / open -na，禁止 AppleScript bring to front，禁止为了找到目标窗口而猜 workspace 编号。
如果 get_app_state 返回的不是目标窗口，停止并报告当前拿到的窗口标题、URL、selected tab，以及 Computer Use 只能按 app 拿最近/key/accessibility 窗口，不能直接指定 workspace/window。
这段 prompt 的核心不是“礼貌请求 Codex 别打扰”，而是把执行路径限制住。
只允许第二层，禁止第一层。
上一篇文章的结论可以保留，但要升级：
普通 Computer Use 不能被默认当成“不会打扰用户的后台同事”。
但这不等于它一定会打扰用户。
如果 Codex 使用全局窗口 / workspace 编排层，它大概率会打扰用户。
如果 Codex 只使用指定 app 的 accessibility 操作层，并且返回的 tree 正好是目标窗口，
所以使用策略也要变：网页任务优先用 Browser 或 Chrome；桌面 GUI 任务只有在必须用 Computer Use 时才用；如果用户还要继续工作，就必须给 Computer Use 一个强 prompt。
这个强 prompt 的重点是：不切 Space，不切 window，不 activate，不 open 前台窗口，不猜 ws，只读 app accessibility tree，只按 element index 操作，拿错窗口就停。
这才是“Codex 不打扰用户”的真正条件。
不是靠模型自觉。
是把不该走的路径写死。
全部评论