洗个澡功夫，Codex 替我跟售后把退款要了回来

洗澡时，Codex悄悄磨赢了客服

整个过程听起来像科幻电影：用户只是简单交代了任务目标——每5分钟检查一次聊天窗口，一旦客服上线就缩短到每分钟检查一次，并尽量帮他把退款要回来。然后他就去洗澡了。等浑身清爽回到电脑前，Codex已经完成了与售后系统的拉锯战，直接替他要回了退款。没有人工盯屏，没有手动刷新排队，一个AI agent趁主人不在，跟另一套客服系统耗着、磨着，硬是把钱要了回来。这背后正是OpenAI Codex的“电脑操作”能力在起作用——它能看见屏幕、点击按钮、读取对话框，像人类一样与图形界面交互。

最宽的大门：Computer Use兜底所有无API的图形界面

这笔退款操作依赖的是Codex权限最宽的方案——Computer Use。它没有调用任何API接口，而是直接“看着”屏幕，识别售后页面的排队状态、客服头像、输入框和提交按钮，自行判断该点哪里。这种方式的优势在于：任何只有图形界面、没有结构化接口的软件它都能用，比如老旧的企业系统、没有开放API的聊天窗口或原生Mac应用。代价是效率偏低——它需要逐帧看屏幕、判断、点击、再等响应，视觉循环相当耗时。不过，在像“盯售后排队”这种需要长时间等待的场景中，慢反而不是问题：它可以在后台安静工作，用户该干嘛干嘛，回头一看它已经跑完了整个流程。OpenAI官方提醒，Computer Use适合跨应用任务和补位场景，但涉及资金、密码、隐私等操作必须有人在场监督。

带着你的身份：Chrome插件让Codex像你本人一样操作网页

如果任务全部发生在浏览器内，且需要账号登录态（比如GitHub、Gmail、Twitter），就更适合使用第二级权限方案——Chrome插件。它能直接利用用户已登录浏览器的Cookie、配置和本地标签页上下文，网站会把Codex的点击、提交、发消息统统当成用户本人在操作。一位工程师曾用它每天定时扫描Twitter长帖，把私信和值得关注的反馈归档进笔记库，全程无需重新登录。另一个例子是让它打开在线音乐编辑器，读完整首曲子后重写和声、调节奏、存档并继续播放——这些操作都带着用户的身份，能力强大但风险也更高，适合需要登录身份的持续性网页任务。

干净隔离的沙箱：应用内浏览器专治开发调试

权限最窄但最安全的是应用内浏览器。它不使用用户浏览器的任何Cookie、配置或登录态，独立运行在Codex对话中，像一个干净的沙箱。最适合本地Web开发调试、复现视觉bug、处理无需登录的公共页面。一个独特优势是交互反馈：开发者在审核本地页面时，可以直接在Codex的浏览器里圈出一块区域、留下批注（比如“这个层级反了”“这块别做成卡片”），Codex能立即理解并修改代码，再跑一遍渲染结果，直到交付预期效果。缺点是处理不了需要Google登录、passkey或依赖浏览器插件的网站，但它让页面本身变成了需求文档，极大提升开发沟通效率。

如何选择？OpenAI的权限体系设计哲学

OpenAI工程师Jason Liu专门撰文解释了三种操作权限的底层逻辑：结构化接口（如API调用）效率最高、可靠性最强，视觉操作（Computer Use）仅作为兜底补位。总结出一条简洁的使用规则：跨应用任务走Computer Use，需登录身份的网页任务走Chrome插件，独立干净的网页开发任务走应用内浏览器。除此之外还有第四项辅助功能Appshots（macOS上快捷键截图并发送上下文给Codex），它负责“指”，三种操作方案负责“动手”。这套权限体系让用户既能享受AI接管电脑的便利，又能根据场景风险选择恰当的授权边界——正如那位洗澡的用户，敢于把退款这么敏感的事交给Computer Use，正是因为它只是盯着一个应用界面反复检查，不触碰其他隐私。