选 Claude 还是 Codex，过去经常被当作一道单选题：喜欢谁的推理，就连同谁的工具一起用。一张署名 @argofowl 的帖子截图提出了另一种组合——让 Claude Code 负责判断，调用 ChatGPT／Codex 在 Mac 上的本地电脑操作能力，完成点击、输入和应用操作。
这个思路有公开的社区实现，但不能直接理解为 OpenAI 已经向 Claude 开放了一套受支持的桌面 API。它真正有意思的地方，是把“模型怎么想”和“动作怎么落到电脑上”拆开。下面先说明证据，再讨论如何验证这种组合是否值得使用。
资料核对：2026 年 10 月 4 日。线索来自读者提供的帖子截图；截图没有完整原帖链接、发帖时间和测试记录。本文核对了产品文档与社区项目，未在 Mac 上复现截图中的八项任务。
1. 截图里的发现，究竟是什么？
截图作者称，Codex 的电脑操作能力可以经由本地 MCP 接入 Claude Code，甚至可在 claude -p 非交互运行时使用。他给出的做法是查找本机插件缓存中的 cua_repl 配置，再将相应启动信息注册为名叫 codex-cu 的 MCP 服务。
这里容易出现两种误读。第一，调用“Codex 的电脑引擎”不必然等于调用 OpenAI 模型；第二，能读到一段 MCP 配置，不必然意味着另一个客户端复制后就能正常运行。模型、客户端、桥接程序和桌面服务各有自己的职责与运行条件。
在公开的 songkeys/claude-codex-computer-use 项目中，维护者明确把它描述为实验性的非官方 macOS 桥接工具，依赖已经安装并能工作的 OpenAI Computer Use。这个项目支持“跨客户端复用本地操作能力”的方向，不能单独证明截图里的配置复制法在所有版本都有效。
2. 拆成三层，就能看懂这套组合
第一层是做判断的模型：读任务、理解界面、决定下一步。第二层是传递工具请求的客户端与 MCP 接口：把“读取窗口”“点击按钮”等请求交给相应程序。第三层是执行动作的本地运行环境：定位应用、取得截图或界面结构、输入文字，并返回操作后的状态。
例如，目标是把一张图拖进画布。模型可能已经准确理解“插入图片”，但仍可能选错窗口、拿到过期坐标，或者调用了目标应用不接受的拖拽方式。反过来，即使底层点击十分可靠，模型也可能选错菜单。整条链路的完成率，需要同时考察理解、执行与验收。
因此，当“Claude 加另一套电脑工具”表现更好时，合理的问题是：哪一层减少了失败？是模型更会规划，还是观察信息更完整，或者同样的指令终于被正确送进应用？仅凭最后的成功数，无法把功劳全部归给模型。
3. 哪些已经有依据，哪些仍然只是报告？
| 说法 | 目前依据 | 阅读时的边界 |
|---|---|---|
| Claude Code 可以连接 MCP 工具 | Anthropic 官方文档 | 协议接入能力，不是对某个内部服务的兼容保证 |
| macOS 可以运行后台电脑操作任务 | OpenAI Computer Use 官方说明 | 受系统权限、应用支持和具体操作限制 |
| 通过社区桥接复用 OpenAI 本地运行环境 | 社区项目自述与公开代码 | 非官方集成，本文没有进行 Mac 实测 |
| Opus 5.5 加该引擎完成 6/8 项任务 | 读者提供的 @argofowl 截图 | 缺少任务集、日志、版本和重复次数 |
| 复制 cua_repl 配置即可长期稳定使用 | 本次未找到足够证据 | 不能作为稳定安装承诺 |
Claude Code 的 MCP 文档确认了本地服务、JSON 配置以及用户级作用域等接入方式。OpenAI 的 Computer Use 文档则说明了产品内的系统权限和平台能力。这两类官方支持都存在，但它们之间的非官方组合仍需要独立验证。
4. 后台操作、无头运行和不抢鼠标，不是一回事
非交互运行描述的是 Claude Code 如何接收任务；后台操作描述的是动作是否要求目标窗口占据前台；不移动用户光标描述的是输入方式。三者不能互相替代。命令行没有聊天界面，不代表桌面应用无需登录会话或系统权限。
OpenAI 当前文档支持 macOS 后台任务场景，并明确说明 Windows Computer Use 使用活动桌面、在前台工作。因而，截图中的 Mac 体验不能直接套到 Windows；即使两台电脑都安装了 ChatGPT，鼠标、焦点与窗口要求也可能不同。
截图对“CUA 驱动”的批评也需要加上版本条件。若这里指 Cua Driver，其当前平台说明列出 macOS 的 AppKit、Accessibility、Quartz/HID 与 ScreenCaptureKit，并注明部分后台滚动、拖拽方式会拒绝执行。这不足以复现截图中的旧测试，却足以说明“只靠辅助功能，所以画布操作全部不行”过于绝对。
同样，“没有悬停功能”只能暂时保留为截图作者针对其环境的观察。依赖悬停菜单、连续笔画、拖放或组合键的流程，应分别测试；一个普通按钮能点成功，覆盖不了这些动作。
5. 6/8 和四倍成本，能说明多少？
下面只整理截图中的数字，不把它们包装成 FindGoodAI 实测：
| 截图中的组合 | 作者报告的完成情况 | 仍需补齐的信息 |
|---|---|---|
| Opus 5.5 ＋ Codex 本地电脑引擎 | 6/8 | 模型参数、工具版本、每项任务的验收记录 |
| Codex 本身 | 6/8 | 使用的模型、预算，以及是否完成同一批任务 |
| CUA 驱动方案 | 3–4/8；截图称成本高 4 倍 | 具体产品、版本、计费口径与重复运行结果 |
八项任务里，一项就占 12.5 个百分点。两个组合都完成六项，也可能失败在完全不同的地方：一个不会拖拽，另一个误读保存对话框。对实际选型来说，失败类型往往比一个总分更有用。
成本也要拆开。模型调用、截图带来的输入、反复观察、重试时间、人工接管与订阅费用，不能混成一个“更便宜”。如果没有逐次用量和计费条件，“四倍”只适合作为继续调查的线索。它不能推导出 Claude 更便宜、Codex 免费，或者任何用户都能节省同样比例。
若要做自己的对照，先固定任务起点、允许的工具、超时与验收标准；每轮还原环境，保留失败，不为某个组合临时增加提示。至少分别记录：最终结果、人工接管次数、耗时、模型用量和动作错误。这样才能看出收益来自哪里。
6. 那段配置提示词，应该怎样理解？
截图提到的路径形态是：
~/.codex/plugins/cache/openai-bundled/
unified-computer-use/<版本目录>/.mcp.json这里的换行只是排版；它是一条本机缓存路径。<版本目录> 不是实际目录名，cua_repl 是作者要寻找的配置条目，codex-cu 是他建议使用的注册名称。这个名字本身不会安装运行环境或补齐宿主依赖。
迁移配置时，真正需要检查的是启动程序是否存在、参数是否有效、环境变量是否依赖原宿主，以及服务初始化能否完成。缓存里“最新”的目录也不一定就是当前应用加载的版本。将旧目录中的一段 JSON 原样复制出去，可能得到一个已登记却无法启动的服务。
可以先让自己的助手做只读检查：报告应用和插件版本、配置文件是否存在、相关条目的字段名及缺失依赖；不要把密钥或整段环境变量贴进聊天。在确认该版本支持外部客户端后，再决定如何接入。遇到拒绝或认证错误，应记录原因，不应以关闭权限检查作为“安装成功”的标准。
7. claude -p 到底证明了什么？
Anthropic 的程序化运行文档将 -p／--print 定义为非交互方式。它说明你可以从命令行提交任务，并不自动证明某个桌面 MCP 已连接、工具已获准，或当前 Mac 可以完成后台输入。
下面是为已完成接入的测试环境准备的验证示例，不是安装命令，也不是本站执行记录：
claude -p "仅使用已配置的 codex-cu 操作计算器，输入 12×12；读取计算器界面中的结果并报告调用证据。若工具不可用或需要人工授权，停止并说明。不要用心算或代码计算代替。"测试应在自己信任的目录中运行，并先完成正常的交互式权限配置。codex-cu 必须与实际注册名称一致。若只是输出一句“144”，却没有调用工具，测试仍然失败——语言模型本来就知道这道题。
8. 用三个小任务，验证“真的能操作”
建议把测试分成三次，而不是一开始就让它接管全部工作流：
- 计算器：操作前读取窗口，输入 12×12，操作后从界面读出 144。记录目标应用与调用过程，排除直接算答案的替代行为。
- 临时文本：在空白测试文档写入一句约定文字，保存到测试目录，再重新打开核对。分别验证输入、保存与持久化，不能只截取保存前的画面。
- 测试画布：在空白画布移动一个无关紧要的对象，比较操作前后位置。悬停、拖拽和绘制分开测试；失败时保留真实返回信息。
每次都写清预期结果、允许的操作范围、停止条件和可见证据。若要检验“不抢鼠标”，另加一项观察：操作者保持原来的工作窗口，记录任务是否改变了光标或焦点。计算器正确和用户不受打扰，是两个独立的验收项目。
9. 本地服务也要看清权限与数据去向
本地 MCP 只说明工具在哪里运行。截图、界面文字和工具结果仍可能进入所用模型的上下文；它不等于整段任务离线完成。验证时用空白文档与测试数据，比打开收件箱或客户后台更容易定位问题。
第三方桥接也可能改变交互行为。songkeys 项目的 README 明确写到自动接受应用访问请求。因此，不能假定移植后仍保留与官方应用完全相同的逐次确认体验。评估这类工具时，既要看它暴露了什么动作，也要看审批如何传递、用户停止后如何处理。本文不把自动放行列为推荐配置。
应用更新可能更换缓存位置或启动方式。适合保留的是已核对的版本、配置备份和一组可重复小测试。更新后重新跑这些测试，比看到服务名称还在列表里就继续批量操作更可靠。
10. 哪些人值得研究这种组合？
如果你已经在 Claude Code 中维护复杂工作流，又需要处理少量只有桌面界面的应用，这个方向值得研究：任务理解和代码工作留在原来的客户端，桌面环节通过独立工具完成。它也适合做受控实验，观察换一个执行层能否减少同类失败。
如果工作只是编辑文件、处理表格或调用已有 API，应先选可直接读写结构化数据的方法。为了改一个文本文件绕到屏幕上点击，通常多了一层窗口与焦点问题。对于长期无人值守任务，还要计算维护成本：升级后谁来验证，权限提示谁来处理，失败后如何恢复。
模型选型因此可以更具体：任务的主要难点在推理，还是在访问数据、识别界面和提交动作？先找出卡住的那一层，再更换组件，通常比反复切换整套产品更有方向。
11. 三个常见问题
这是官方支持 Claude 调用 Codex 吗？本次核对没有找到这种官方兼容承诺。官方 Computer Use 能力、Claude 的 MCP 支持与社区集成应分别看待。
Windows 能照着配置吗？截图与所查桥接项目以 macOS 为对象。OpenAI 有 Windows Computer Use，但官方文档注明其前台运行特点；把路径改成 Windows 格式，不能证明这套桥接就可用。
能省下 Codex 的费用吗？不能仅凭本地执行或截图下结论。是否调用某家模型、订阅是否仍有其他用途、Claude 消耗多少用量，以及重试与维护时间，都需要单独核算。
FindGoodAI 的判断是：这条线索值得跟踪，因为它让我们看见模型与桌面执行层可以分开评估。真正值得保留的成果，是一套能够反复跑通、知道何时失败、可以核对结果的工作流。
12. 参考资料与继续阅读
- 读者提供的 @argofowl 帖子截图：本文讨论的起点。原帖直链、发布日期和八项任务记录尚未核实；数字按截图归属作者。
- OpenAI：Computer Use——官方平台能力与权限说明。
- Anthropic：Claude Code MCP——连接与配置参考。
- Anthropic：程序化运行 Claude Code——非交互模式。
- songkeys：Claude Codex Computer Use——非官方社区桥接及其行为说明。
- Cua Driver：平台支持——理解不同操作路径的限制。
- 站内：Codex、Claude、ChatGPT MCP 插件接入教程。
资料与来源
Anthropic: Run Claude Code programmatically ↗
复制链接，保存或分享这篇文章。
