Codex 能读 Windows 窗口却截不了图？按故障阶段排查
结合公开故障报告区分窗口发现、文字读取、截图与坐标操作，提供最小测试和脱敏记录模板，不把权限拒绝或源码修复误当成截图问题已解决。
Ofox 
Codex 能列出 Windows 应用、读到文字，却无法截图或获得点击坐标时，应把这几项分别记录。读到文字不证明截图通道正常；截图失败也不能反过来证明应用从未获得授权。
本文基于 OpenAI 官方文档和公开仓库报告，提供故障定位流程，不是 Windows 实测修复教程。2026 年 10 月 18 日，我们的本地权限检查在原生文字、截图和点击之前就停止了，没有复现 Windows 截图故障，也没有测试 Intel Mac。这里交付的是一套能区分访问许可、初始化、截图和交互的记录方法。
本文由 Ofox 发布。更换模型供应商或购买 API 额度，不是已经证实能修复本地 Computer Use 截图问题的办法。
先找出第一个失败操作
桌面任务有几个可以观察的阶段。只执行已获授权的下一步，并保留最早出现的错误。
| 阶段 | 最小观察 | 成功能证明什么 | 还不能证明什么 |
|---|---|---|---|
| 发现窗口 | 获取可用应用或窗口列表 | 工具返回了清单 | 可以读取和操作所有列出的应用 |
| 访问应用 | 选择已批准的测试应用 | 访问已进入该应用 | 文字、像素或交互都正常 |
| 读取文字 | 读取一段独特的无敏感内容 | 文字通道能返回当前内容 | 截图一定可用 |
| 截图 | 获取同一窗口的新截图 | 该窗口当前像素可用 | 坐标和点击也可用 |
| 交互 | 操作一个无副作用控件，再读新状态 | 指定操作改变了目标界面 | 所有控件和坐标操作都支持 |
文字测试可以在新建的临时文档放入 CU-CHECK-20261018。避免使用私人聊天、凭据或生产管理后台。记录实际应用与版本；换一个应用测试只是对照，不能证明原应用已经恢复。
若访问阶段被拒绝，就停在这一行。之后应写“截图未测试”，不能写“截图失败”。不要换工具或换聊天绕过拒绝。单独获准的文件任务可能仍能完成，但应另列结果。
Windows 报告提供了哪些证据
问题 #54235记录了 Windows 10 LTSC build 19044 环境：应用发现或文字读取可用，但截图与指针坐标出现故障。报告还记录了一次虚拟显示隔离尝试，未恢复出错通道。因此，不能把该尝试推荐为这个问题的必然解法，更不能据此推导所有 Windows 环境有同一个根因。
问题 #54139提供了另一份截图失败报告。如果自己的日志出现 FrameArrived 超时，就保留精确原文以及触发它的操作。不要因为别人的 issue 出现过这段错误，就将它写进自己的复现记录。
这些报告本身不足以确定完整因果链。文字读取正常与截图超时可以同时发生，因为两次观察经过的通道不同。不能据此直接判定显示驱动损坏、模型能力不足，或者所有 Windows 安装都受影响。
作为对照，问题 #54225与 #54157涉及 MXC、0x80070003 一类初始化故障。若浏览器或应用清单还没返回就失败，应先排查这个更早的阶段。只有真正执行到截图，才有截图故障可分析。
先做最小测试，不急着改环境
先按官方 Computer Use 设置说明核对受支持的使用条件。文档要求 Windows 目标应用位于当前活动桌面并保持可见。确认选择的是预期窗口、桌面会话可用，不要一上来就重装应用或改显示驱动。
可以给 Codex 下面的限定任务：
仅使用指定测试应用及其中新建的合成文档。
不读取其他窗口，不更改系统或安全设置。
记录应用、操作系统及能获取到的版本信息。
1. 列出可用的目标窗口。
2. 获得授权后，读取所选窗口中的测试短语。
3. 获取同一窗口的一张当前截图。
4. 只有必要观察与坐标信息可用时，操作一个无副作用控件，
再读取操作后的状态。
在第一次失败时保留精确操作和错误，后续阶段标为未测试。
不根据旧截图或猜测坐标点击，不更改权限或驱动。无副作用控件可以是展开菜单，或切换两个测试标签页。控件应从当前界面确认，而不是猜一个位置。如果语义控件可以点击、坐标操作却失败，就分别记录，不要统称“所有交互失效”。
截图必须反映当前状态。另一个应用、旧窗口尺寸或上个会话的成功截图，不能支持本次坐标点击。截图失败后应停止依赖坐标的动作，而不是把旧图当作备用方案。
权限失败不能记成截图失败
本次本地尝试在应用打开前返回了未批准访问；另一次独立浏览器导航也被来源授权拒绝。清单读取成功，但后两项都不能证明截图出了问题。我们没有绕过这两次拒绝。
| 本地观察 | 记录结果 |
|---|---|
| 应用和浏览器清单 | 成功返回 |
| 原生应用访问 | 未获批准 |
| 浏览器访问指定来源 | 授权被拒绝 |
| 原生文字、截图和交互 | 未测试 |
| Windows 截图修复 | 未尝试 |
这是真实的权限边界观察，不是 Windows 故障复现。它说明诊断表为什么除了成功、失败，还必须有“未测试”。把所有做不到的动作都归为截图故障，会让后面的排查找错组件。
macOS 的系统录屏、辅助功能与单个应用的访问批准也相互独立，官方文档对此有明确说明。因此，即使系统开关已打开，也不能据此确认某个应用请求已批准。这类较宽的访问问题由既有Computer Use 权限排查承接，不应套用 Windows 显示相关建议。
对照环境有用，但不能直接宣布修复
浏览器与原生应用的对照有助于缩小范围：例如浏览器文字和截图都正常，某个原生窗口却截不下来。但浏览器本身被拒绝访问时，就没有这个“浏览器正常”的对照证据。记录实际浏览器、配置、任务类型和观察结果，不要只填一句“浏览器能用”。
问题 #51927涉及不同任务创建路径的表现。另一种任务路径可以是获准的对照，却不是通用恢复方法，也不能用于逃避已发生的拒绝。问题 #42514涉及 Intel Mac 原生服务；平台和架构不同，应与 Windows 截图问题分开分析。
上游源码修复也不等于桌面版已验证发布。声称某次更新修好了问题之前，应确定实际安装的桌面版本、对应发布证据，以及更新后同一个最小任务的结果。独立 CLI 的版本号不能代表桌面应用内所有组件。
准备一份有用且脱敏的故障记录
完成限定测试后，可以按这个模板整理：
观察时间与时区：
操作系统版本、build、CPU 架构：
桌面应用版本与安装渠道：
Computer Use 插件版本（如界面可见）：
任务类型、目标应用及版本：
第一个失败阶段、精确操作：
精确错误（移除凭据和私人路径）：
窗口发现结果：
应用访问批准结果：
测试短语读取结果：
截图结果：
交互方法及实际结果：
此前成功的对照及其环境：
本次只改了哪一项（如有）、同任务复测结果：
哪些后续阶段没有测试：不要把完整配置、私人截图或令牌上传到公开 issue。保留最小相关片段和平台信息即可。上游如果要求补充诊断，也应先检查其中包含什么数据，再决定如何分享。
真正的恢复证据，是原先失败的操作在目标环境中成功，且下一项必要动作也经过验证。issue 已关闭、权限开关打开、重启成功或文字可读，都不能单独证明截图恢复。尚未恢复时，写清哪些操作能用、哪一步仍失败。如果用户只需要文档产物，明确授权的文件验收流程可以完成那个独立任务，但不能把它描述成桌面截图问题已修复。
