案例日期：2026-11-10
关键词：ChatGPT、Computer Use、Windows 10、Windows.Graphics.Capture、FrameArrived、PowerShell、SHA256、PE、Authenticode

文章目录

  1. 摘要
  2. 1. 故障环境与现象
  3. 2. 先区分三件事：系统截图、窗口识别、Computer Use 图像捕获
  4. 3. 确认 Windows、应用版本和真正运行的 helper
  5. 4. 为什么 Win+Shift+S 正常，Computer Use 仍然失败？
  6. 5. 社区补丁为什么与本机不匹配？
  7. 6. 针对 0EBB47 构建生成离线候选补丁
  8. 7. 安装前的安全检查、脚本问题与修正
  9. 8. FIX2 安装与安装后复核
  10. 9. 当前功能验证状态：黄色框不等于截图已成功回传
  11. 10. 本次案例的经验总结
  12. 免责声明

摘要

本案例记录一次 Windows 10 环境下 ChatGPT / Codex Computer Use 截图失败的排查过程。现象是：Computer Use 能识别到记事本窗口标题，但无法稳定取得窗口画面，错误包括：

window capture timed out: timed out waiting on channel
FrameArrived timed out: timed out waiting on channel

Windows 自带 Win + Shift + S 截图可以使用，但这并不能证明 Computer Use 自己的截图链路正常，因为两者不是同一条捕获路径。

排查过程中确认了实际运行的截图辅助程序、Sky 版本和原始 SHA256；发现现成社区补丁按 SHA256 白名单匹配，不支持本机的 0EBB47... 构建，因此没有强行套用。随后基于该构建生成离线候选文件，制作专用安装器，完成独立备份、预检查、安装和安装后哈希复核。

最终状态更新 · 2026-11-10

后续测试结果：完成 FIX2 安装后，用户已确认 ChatGPT Computer Use 目前可以正常截图。因此，本案例从“补丁已安装、功能待验证”更新为“基本截图功能已恢复”。

目前确认的是截图功能已恢复；连续 5 次 / 30 次截图、跨应用截图及长时间稳定性测试尚无完整记录。本文不会将尚未测试的项目写成已通过，也不把一次功能恢复等同于长期稳定性验收。

1. 故障环境与现象

本次记录的环境如下：

项目实际信息
操作系统Windows 10 22H2
OS Build19045.7807
ChatGPT Windows 应用26.1103.7773.0
截图辅助包@oai/sky
Sky 版本0.7.17
原始辅助程序codex-computer-use.exe
原始文件大小1,548,592 bytes
原始 SHA2560EBB47BFAAF729E22BCDB08DCFCE1419EEFEDA80AFAEFED3EDBC088C24A2E778

图1：Computer Use 初始截图失败现象

实际测试中，Computer Use 返回过“窗口截图超时”，随后进一步测试发现：它可以识别“无标题 - 记事本”窗口及窗口句柄，但截图获取失败。

图2：已识别记事本窗口，但截图获取失败

这条证据很重要：窗口枚举 / 目标识别成功，不等于图像帧已经成功捕获，更不等于图像已经成功回传给模型。

2. 先区分三件事：系统截图、窗口识别、Computer Use 图像捕获

本案例中最容易混淆的是下面三个阶段：

  1. Windows 原生截图：Win + Shift + S 可以正常使用，说明系统自带截图工具的路径可用。
  2. 窗口识别：Computer Use 能识别记事本标题和窗口句柄，说明至少窗口发现 / 目标选择阶段有响应。
  3. 图像捕获与回传：FrameArrived timed out 表示截图链路在等待帧或等待内部通道结果时超时；本次失败发生在这个阶段附近。

可以把流程理解为：

Computer Use 请求
    |
    v
启动 / 调用截图辅助进程
    |
    v
枚举窗口、识别目标窗口
    |
    v
请求窗口画面 / 等待 FrameArrived
    |
    v
读取帧并转换图像
    |
    v
通过内部通道返回截图结果

Win + Shift + S 使用的是 Windows 自带截图工具；Computer Use 则调用自己的辅助程序和捕获链路。前者成功只能作为对照，不能直接证明后者没有问题。

3. 确认 Windows、应用版本和真正运行的 helper

3.1 确认操作系统版本

通过 winver 确认本机为 Windows 10 22H2、Build 19045.7807。

图3：Windows 10 版本信息

3.2 不要只看 cua_node\bin，要继续定位到实际 helper

最初在 runtimes\cua_node\<runtime-id>\bin 下只看到 Node 运行时文件和 node_modules，没有直接看到 windows 文件夹。这并不代表 helper 不存在。实际文件位于更深层的 npm 包目录中。

搜索命令：

$root = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node"

Get-ChildItem $root -Recurse -File -Filter "codex-computer-use.exe" `
    -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty FullName

图5：搜索 CUA / Sky 截图辅助程序

本机搜索结果中同时出现了 @oai\cua、@oai\sky 以及 Swift 版本的相关文件。不能只凭文件名选择补丁目标，应以实际运行进程的 ExecutablePath 为准。

3.3 通过进程反查实际运行路径

Get-CimInstance Win32_Process -Filter "Name='codex-computer-use.exe'" |
    Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

本次实际运行目标为：

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\
76f5b5935a63c7ba\bin\node_modules\@oai\sky\bin\windows\
codex-computer-use.exe

图6：通过进程信息确认实际运行路径

这一步解决了两个问题：

  • cua_node\bin 是 Node 运行时目录，不是最终 helper 所在目录。
  • 同一运行时可能同时包含不同包路径、普通版和 Swift 版 helper；应以当前进程路径为准，不要误改 codex-computer-use-swift.exe 或其他包中的同名文件。

3.4 核对版本、哈希和签名

$helper = "实际的 codex-computer-use.exe 完整路径"

Get-FileHash -LiteralPath $helper -Algorithm SHA256
Get-AuthenticodeSignature -LiteralPath $helper |
    Select-Object Status

本机普通版 helper 的结果：

  • SHA256：0EBB47BFAAF729E22BCDB08DCFCE1419EEFEDA80AFAEFED3EDBC088C24A2E778
  • Authenticode：Valid
  • 文件大小：1,548,592 bytes

图7：原始 helper 的 SHA256 与签名状态

进一步读取 @oai/sky 的 package.json，确认版本为 0.7.17。

图8：确认 @oai/sky 版本为 0.7.17

4. 为什么 Win+Shift+S 正常，Computer Use 仍然失败？

两条路径不同：

  • Windows 自带截图工具能工作，说明系统层面存在一条可用的屏幕截图路径。
  • Computer Use 的窗口识别已经有响应，但获取帧时返回 FrameArrived timed out。
  • 因此不能把问题简单归结为“Windows 截图功能坏了”。

本案例也检查过 Windows 图形设置，包括“窗口化游戏优化”“硬件加速 GPU 调度”和应用程序自定义图形首选项。

图4：Windows 图形设置排查

这些设置可以作为排查分支，但本次没有证据证明它们就是根因，也没有证据表明调整它们能够修复 FrameArrived 超时。不要把图形设置开关当作本案例的最终修复方案。

另外，本机曾重新安装 ChatGPT 应用，但故障仍然存在。重新安装应用不一定能清理或重建用户目录下的独立运行时缓存，因此也不能据此排除 helper / runtime 层问题。

5. 社区补丁为什么与本机不匹配？

这是本次排查中最关键的安全点：版本号相同，不代表二进制文件相同。

5.1 第一份 workaround 的哈希不匹配

最初下载的 Repair-Capture.ps1 内部固定了原始文件哈希：

$originalHash = "B6B0E4979B89E5C22DAB866F0974BC817C0D08CB359E1C2DD7BE3DCCB9E181EB"
$candidateHash = "4F1BF5FAD6750D712CD1DA91848FAE410CB87C407B7F791025B68D6F45C68810"

脚本要求的原始文件长度为 1,551,152 bytes，而本机文件为 1,548,592 bytes，SHA256 也不同。脚本返回：

Unsupported helper hash.
No file or process was changed.

图9：旧补丁因 SHA256 不匹配而拒绝处理

这不是脚本“太严格”，而是它在保护不同构建之间的二进制差异。不能通过删掉哈希判断、强行覆盖或修改脚本白名单来绕过。

5.2 另一个通用脚本也没有本机 0EBB 构建

后来检查的 patch-computer-use-helper-win10.ps1 中，@oai/sky 0.7.17 配置包含以下原始哈希前缀：

  • FC0447EF
  • 1F0DDEE3
  • 87ECB164
  • 7F73CF56

本机实际哈希前缀是 0EBB47BF，不在该脚本支持列表中。

因此，虽然包版本同为 0.7.17，但仍然不能直接套用这些补丁配置。正确做法是停止并做构建级核对，而不是强制安装。

6. 针对 0EBB47 构建生成离线候选补丁

本次由 Codex 基于原始文件生成离线候选文件和静态分析 JSON。原始文件没有被直接修改。

6.1 原始文件与候选文件哈希

项目原始文件候选文件
文件名codex-computer-use.execodex-computer-use-0EBB47-win10-candidate.exe
大小1,548,592 bytes1,548,592 bytes
SHA2560EBB47...C24A2E778CF46A153...CE6873B1
数字签名ValidNotSigned

候选文件完整 SHA256：

CF46A153F6BC98A8F8B5DBE852D6DCEF753FD5D0325346DC1AD0F491CE6873B1

6.2 静态报告能说明什么？

Codex 生成的 JSON 报告记录：

  • 参考配置：@oai/sky 0.7.17 helper 87ECB164 guarded transformation
  • 比对区域：13 个
  • 与参考配置完全一致：11 个区域
  • 不完全一致：2 个区域
  • pe-checksum：3 字节不同
  • mta-wrapper-and-unwind：35 字节不同
  • 候选文件总差异：552 bytes
  • PE 节区数量：9 增加到 10
  • 新增节区：.cuw10
  • Exception Directory / .pdata 信息被扩展
  • 报告记录新增 2 条 Runtime Function
  • Security Directory 被清除，候选文件不再保留原始 Authenticode 签名

这些信息来自本次生成的静态报告。它们可以帮助确认补丁的结构和修改范围，但不能代替 Windows 运行时验证，也不能证明 COM / WinRT 线程生命周期一定正确。

6.3 补丁的技术意图与根因边界

静态报告中的区域名包括：

  • frame-arrived-busy-return
  • frame-arrived-once-flag
  • frame-arrived-vtable
  • mta-section-header
  • mta-wrapper-and-unwind

从命名和新增 MTA 相关代码区域看，该候选补丁的设计方向是调整 FrameArrived 回调的执行 / 调度方式，并补充对应运行时函数和 Unwind 元数据。

但目前没有 WinDbg 线程栈、ETW 轨迹或运行时 COM 错误记录，不能把“COM Apartment 不匹配”或“回调死锁”写成已经证实的根因。更准确的表述是：

当前证据指向 Computer Use helper 的窗口帧捕获 / 回调等待链路超时；MTA 调度调整是针对该链路的实验性修复方向，根因仍需运行时证据确认。

7. 安装前的安全检查、脚本问题与修正

7.1 必须先确认 helper 进程已经退出

本次发现 codex-computer-use.exe 的父进程是 ChatGPT.exe。示例进程关系：

ChatGPT.exe                 PID 18532
└── codex-computer-use.exe  PID 9064

图10：确认截图辅助进程由 ChatGPT.exe 启动

只关闭窗口不一定能退出后台进程。安装前应保存工作并完全退出 ChatGPT，再检查：

Get-CimInstance Win32_Process |
    Where-Object {
        $_.Name -in @("ChatGPT.exe", "codex-computer-use.exe")
    } |
    Select-Object ProcessId, ParentProcessId, Name

确认目标 helper 不再运行后，再执行安装器的 Check。不要为了安装补丁而结束所有 Node.exe 或其他无关进程。

7.2 PowerShell 执行策略问题

直接执行：

.\Install-Codex-Capture-0EBB47.ps1 -Mode Check

曾被本机执行策略拦截。

本次使用的是一次性启动独立 PowerShell 进程的方式：

powershell.exe -NoProfile -ExecutionPolicy Bypass `
    -File ".\Install-Codex-Capture-0EBB47.ps1" -Mode Check

该参数作用于本次启动的 PowerShell 进程，不等于永久修改系统执行策略。若企业策略明确禁止执行，应遵循组织策略，不应擅自绕过。

图11：直接执行 PS1 被执行策略拦截

7.3 FIX1 的两个脚本问题

专用安装器也经历了两次修正：

  1. 初版 Check 报 Join-Path 的 Path 参数为空，属于脚本目录初始化问题。
  2. FIX1 安装时，.NET File.Replace 因替换备份路径参数不合法而失败。

图13：FIX1 安装阶段的 File.Replace 路径错误

FIX2 将替换过程改为使用唯一的临时备份路径，并在替换后校验旧文件哈希和新文件哈希。这里要强调：安装器本身也需要检查和测试，不能因为它声称有备份 / 回滚功能就默认可信。

7.4 独立备份先于安装器自动备份

在安装前，先单独复制原始 EXE，并验证：

  • 原始文件 SHA256 = 预期值
  • 备份文件 SHA256 = 同一预期值
  • 原始文件 Authenticode = Valid
  • 备份文件 Authenticode = Valid

独立备份路径：

%USERPROFILE%\Downloads\补丁\0EBB47-安装前备份\
codex-computer-use.exe.original

图12：独立备份的 SHA256 与数字签名验证

8. FIX2 安装与安装后复核

8.1 安装前 Check

FIX2 的安装前检查结果为：

  • State = Original
  • CurrentSHA256 = 0EBB47...
  • OriginalSignature = Valid
  • BackupState = VerifiedOriginalBackup
  • MatchingHelperProcessCount = 0
  • InstallAllowedByPreflight = True

图14：FIX2 安装前检查通过

8.2 执行安装

本案例使用的命令为：

powershell.exe -NoProfile -ExecutionPolicy Bypass `
    -File ".\Install-Codex-Capture-0EBB47.ps1" -Mode Install

安装器返回：

Install completed and candidate SHA256 verified.
Original backup retained at:
...\codex-computer-use.exe.original-0EBB47.bak

The candidate is unsigned. No security controls were disabled.

图15：FIX2 安装成功并校验候选哈希

8.3 安装后再次 Check

安装成功不代表功能修复成功，还必须再次核对当前文件：

  • State = CandidateInstalled
  • CurrentSHA256 = CF46A153...CE6873B1
  • BackupState = VerifiedOriginalBackup
  • MatchingHelperProcessCount = 0

图16：安装后状态为 CandidateInstalled

这一步证明候选文件已经替换到目标路径，且安装器保留的原始备份仍然通过校验。

9. 当前功能验证状态：黄色框不等于截图已成功回传

安装后桌面出现了黄色窗口 / 区域高亮框。

图17：安装后出现黄色窗口 / 区域高亮框

这个现象可以作为“目标窗口 / 区域选择界面出现了可见反馈”的证据，但不能单独证明以下三件事：

  1. FrameArrived 已经稳定返回帧；
  2. 图像转换已经完成；
  3. 截图数据已经成功回传到 ChatGPT 对话。

根据最新反馈，基本截图功能已确认恢复；以下将已确认结果与尚未完成的稳定性验证分开记录：

验收项状态
原始文件 SHA256 与签名确认已完成
独立备份验证已完成
候选文件离线静态报告已生成
FIX2 安装成功已完成
安装后候选 SHA256 复核已完成
黄色窗口 / 区域高亮反馈已观察到
记事本截图实际回传已确认成功
连续 5 次截图待测试
连续 30 次截图待测试
跨应用截图（记事本 / Chrome / 剪映）待测试
长时间稳定性 / 线程与内存观察待测试

建议的最终验收顺序

  1. 启动 ChatGPT。
  2. 先对记事本执行一次“只截图、不点击、不输入”的 Computer Use 请求。
  3. 确认对话中实际返回了记事本图像，而不只是出现黄色边框。
  4. 连续截图 5 次，记录成功次数和错误文本。
  5. 再测试 Chrome、剪映等不同窗口。
  6. 最后进行 30 次连续截图，观察是否再次出现 FrameArrived timed out。
  7. 若 ChatGPT 无法启动、辅助程序被安全策略拦截或截图仍异常，停止测试并回滚。

回滚命令（仅适用于本案例 FIX2 脚本和匹配的 0EBB / CF46 文件）：

powershell.exe -NoProfile -ExecutionPolicy Bypass `
    -File ".\Install-Codex-Capture-0EBB47.ps1" -Mode Rollback

回滚后还应执行 -Mode Check，确认 State = Original、原始 SHA256 正确、Authenticode 为 Valid。

相关 GitHub Issue 与技术参考

以下 Issue 来自 openai/codex 仓库，记录了 Windows 10 下 Computer Use 原生窗口截图超时、FrameArrived 回调等待及社区修复思路。它们可作为本案例的外部技术参考，但不能直接证明本机 0EBB47 构建具有完全相同的内部根因。

Issue #59303：Windows 10 Computer Use WGC timeout

重点讨论 Windows Graphics Capture 场景下，FrameArrived 回调持有 D3D 锁，而 SoftwareBitmap 转换又等待相关资源，导致回调内同步等待无法完成的问题。该 Issue 提供了独立 Windows API 复现及线程/锁分析，适合用于理解本案例中的 FrameArrived 超时现象。

查看 GitHub Issue #59303 →

Issue #55185：Windows 10 Computer Use async/task deadlock 与可回滚 workaround

这是社区实验性补丁的重要参考，记录了将原始回调处理转移到 MTA Worker 的实现思路，以及针对特定原始 SHA256 的可回滚方案。该 Issue 的验证环境为 @oai/sky 0.7.8，原始 helper SHA256 为 B6B0E4979B89E5C22DAB866F0974BC817C0D08CB359E1C2DD7BE3DCCB9E181EB；本案例使用的是 Sky 0.7.17，原始 SHA256 为 0EBB47BFAAF729E22BCDB08DCFCE1419EEFEDA80AFAEFED3EDBC088C24A2E778。两者不是同一构建，因此不能直接使用该 Issue 附带的旧补丁。

查看 GitHub Issue #55185 →

Issue #54784：将 FrameArrived 处理转移到 MTA Worker

该 Issue 讨论在 FrameArrived 回调中尽快返回，再由独立 MTA Worker 执行帧处理的修复方向，并记录了 Sky 0.7.8 环境下的本地验证。它属于社区提出的修复方案，不等同于 OpenAI 已发布的官方修复。

查看 GitHub Issue #54784 →

版本适配提醒： GitHub Issue 中的错误现象、分析结论和补丁不能仅凭错误字符串或 Sky 版本号直接移植。本案例的候选补丁以本机原始 helper SHA256 为适配基准；任何其他构建均应重新核对文件哈希、PE 结构、回调路径、重定位及异常展开信息。上述 Issue 均为技术参考，不代表本案例补丁获得官方认可。

10. 本次案例的经验总结

  1. 先定位失败阶段，不要把“窗口识别失败”和“截图帧获取失败”混为一谈。 本次记事本窗口已识别，但 FrameArrived 等待超时。
  2. Win + Shift + S 正常，不代表 Computer Use 的截图链路正常。 两者使用不同的实现路径。
  3. 补丁匹配必须以 SHA256 为准。 Sky 0.7.17 只是包版本，不足以证明二进制兼容。
  4. 遇到 Unsupported helper hash 应停止。 不要删掉保护校验或强行套用其他构建补丁。
  5. 通过进程的 ExecutablePath 确认实际目标。 不要误改 Swift 版或其他 npm 包中的同名文件。
  6. 先做独立备份，再做安装器备份。 两份备份都要校验 SHA256；原始文件还要检查 Authenticode。
  7. 安装成功不能直接等同于功能修复。 本次已由用户确认实际截图恢复；连续运行和跨应用场景仍需单独验收。
  8. 不要把推测写成根因。 没有 WinDbg 栈、ETW、DMP 或更完整日志时，COM / WinRT / GPU 只能作为待验证方向。

免责声明

本文是一次特定 Windows 10 / ChatGPT 应用版本 / @oai/sky 0.7.17 构建下的实验性排查记录，不是 OpenAI 官方修复方案。候选 EXE 清除了原始安全目录，Authenticode 状态为 NotSigned，可能受到 Windows 或企业安全策略拦截。不要将本文的候选文件、哈希或安装器用于其他版本；不要关闭 Defender、SmartScreen 或企业安全控制。发布时不应公开分发未经官方签名的二进制补丁。

最终结论：本案例已完成 0EBB47 构建的候选补丁生成、独立备份、FIX2 安装及安装后 SHA256 复核。根据后续实际使用反馈，ChatGPT Computer Use 目前已经可以正常截图，基本截图功能已恢复。连续截图、跨应用及长时间稳定性仍需进一步验证，因此本案例结论为“基本功能恢复，稳定性验收待补充”。

# windows
Logo
AtomGit AI 社区

AtomGit AI 社区提供模型库、数据集、Agent、Token等资源

更多推荐

如果你需要“产出”，它是目前最省事的选择之一

市面上关于 NoteGPT 的讨论，经常把它和otter, fireFiles 甚至 ChatGPT 放在同一张对比表里。Otter 和 Fireflies 强在“记录已经发生的事情”——一场会议、一节课、一次对话，把它们忠实转成文字和纪要。ChatGPT 强在“你给上下文，它给你回答”。——文档、幻灯片、表格、研究报告、播客音频、图像。它不负责“记录”，也不停留在“回答”，它的终点是。

avatar AtomGit AI 社区
cover

黄仁勋辞任之后，真正值得追问的不是八卦：如何用 AI 把热点变成一条可验证、可复用的工作流

avatar AtomGit AI 社区
cover

Fix the gray Send button in ChatGPT Work on Windows

avatar AtomGit AI 社区