Windows Computer Use screenshot fails on Windows 10 22H2 when SetIsBorderRequired is called
Summary
On Windows Codex Desktop, Computer Use can list apps/windows, activate windows, read accessibility text, and send keyboard input, but any get_window_state call that requests a screenshot fails before capture with:
SetIsBorderRequired failed: 不支持此接口 (0x80004002)
The same target window works when requesting accessibility text only (include_screenshot: false, include_text: true). This looks like the Windows capture helper unconditionally calls GraphicsCaptureSession.IsBorderRequired / SetIsBorderRequired on a Windows build that does not support that property.
Environment
Sanitized user machine details:
- Platform: Windows Codex Desktop
- Codex app package observed:
OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 - Computer Use plugin observed:
computer-use/26.527.31326 - OS: Windows 10 Pro 22H2
- OS build:
10.0.19045 - GPU: NVIDIA GeForce GTX 1060 3GB
- DirectX: 12
- Driver model: WDDM 2.7
- Remote/virtual display drivers also present: ToDesk Virtual Display Adapter, Oray Display Mirror Driver
Reproduction
From the Computer Use client in Codex Desktop on this Windows 10 machine:
- Bootstrap Computer Use and call
sky.list_apps(). - Open or select a simple window such as Notepad.
- Activate the window.
- Call any screenshot-including state request, for example:
await sky.get_window_state({ window: targetWindow });
// or
await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: false });
// or
await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: true });
- The call fails with:
SetIsBorderRequired failed: 不支持此接口 (0x80004002)
- Calling text-only succeeds:
await sky.get_window_state({ window: targetWindow, include_screenshot: false, include_text: true });
Observed text-only result against Notepad included a focused editor element and accessibility tree, proving that the helper, native pipe, app enumeration, activation, and accessibility path are otherwise working.
Observed Batch Test Results
{
"notepad_default_screenshot": "failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)",
"notepad_explicit_screenshot": "failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)",
"notepad_text_only": "ok",
"notepad_both": "failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)",
"explorer_screenshot": "failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)"
}
Suspected Cause
Microsoft documents GraphicsCaptureSession.IsBorderRequired as introduced in Windows 10 version 2104 / build 10.0.20348.0, API contract v12:
This repro machine is Windows 10 build 19045, so SetIsBorderRequired appears to hit E_NOINTERFACE (0x80004002, no such interface supported). The capture helper seems to abort instead of continuing without border toggling.
Expected Behavior
On Windows builds where border toggling is unsupported, Computer Use should still capture screenshots if the underlying Windows Graphics Capture path is otherwise available. Suggested behavior:
- Gate the border call with
ApiInformation.IsPropertyPresent("Windows.Graphics.Capture.GraphicsCaptureSession", "IsBorderRequired"), or an equivalent OS/API contract check. - If unsupported, skip
SetIsBorderRequiredand allow the default capture border behavior. - Alternatively, fail with a clear compatibility error such as:
Computer Use screenshots require Windows build 20348+ because border toggling is currently unconditional.
Impact
This leaves Computer Use partially functional on Windows 10 22H2:
- Working: app/window enumeration, activation, accessibility text, keyboard input.
- Broken: screenshot-based UI inspection and accurate coordinate-based visual interaction.
For users on Windows 10 build 19045, this means Computer Use cannot reliably operate visual apps even though non-visual operations work.
17 Comments
Me too. Codex says this affects all Windows 10 users and it thinks OpenAI can easily fix it in the
codex-computer-use.exesource filesrc\capture\image.rs, treatingSetIsBorderRequiredas optional. See feedback ID 019e779c-55f4-7113-a4fb-afcbc097c81b.Codex says the IsBorderRequired functionality was introduced in Windows build
10.0.20348.0. It says the leading10.0is the Windows NT platform, not the marketing name, so it doesn't mean Windows 10. It says the most recent Windows 10 is 22H210.0.19045.x, and that10.0.20348.0refers to Widnows Server 2022.So, it says there's no Windows 10 updates to add IsBorderRequired functionality.
One fix is to upgrade to Windows 11, but Codex thinks this can be fixed so Windows 10 is supported for this who can't or don't want to upgrade to it. It says SetIsBorderRequired isn't required to screenshot a program, and it controls whether Windows shows the colored capture border around a window/display being captured. When Codex calls it, it gets a
E_NOINTERFACE / 0x80004002and Codex aborts the whole screenshot operation.It says if the IsBorderRequired system doesn't exist, or if calling it gives
E_NOINTERFACE, that it should continue the screenshot capture with the default border behavior.Like the original poster, computer use seems to be working for other functionality, just not when it needs to do screenshots.
Also, Codex is able to manually do screenshots and see that just fine since it skips calling the function that isn't supported, but it says it can't use that screenshot because the helper guards coordinate input with checks including requiring calling
get_window_statebefore issuing coordinate input, and that a screenshotId which has to come through the helper, not it manually screenshotting.If I tell it to take the next step and issue the click/drags on its own, it belligerently tells me about how the Computer Use API has instructions prohibit it from falling back to raw UI automation when Computer Use is available but partially broken. Even when I remind it about the scene where the Terminator lets go of John, making John fall on the ground and realize the Terminator has to do what he says... It refuses to listen to me over its instructions.
Adding another sanitized repro from a current Windows 10 machine.
Environment:
Get-AppxPackagecannot load the Appx module hereObserved behavior:
Impact in my repro:
This lines up with the proposed root cause here: Windows 10 build 19045 does not expose the
GraphicsCaptureSession.IsBorderRequired/SetIsBorderRequiredAPI surface, so the helper should skip the optional border call or return an explicit compatibility message while keeping non-screenshot operations available.I can confirm a second independent repro of this issue on Windows 10 22H2.
Environment
10.0.19045/ build19045OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g026.601.21317@oai/sky:0.4.5-26566467949-4daa3290021dRepro results
I tested
sky.get_window_stateagainst multiple windows:notepad.exe)For all three windows:
succeeds and returns an accessibility tree.
But any screenshot-including call fails consistently:
with:
Because the plugin screenshot state is unavailable, coordinate clicking also becomes unusable and reports:
Additional check
A separate OS-level screenshot fallback using
CopyFromScreencan capture the same Notepad and 360ChromeX windows on this machine, so this does not appear to be a general Windows screenshot/display failure. The failure seems isolated to the Computer Use Windows Graphics Capture path and its unconditionalSetIsBorderRequiredcall on Windows build19045.This matches the suspected root cause described above: Microsoft documents
GraphicsCaptureSession.IsBorderRequiredas introduced in10.0.20348.0, while Windows 10 22H2 desktop remains on10.0.19045.If only Codex App was open source, we could just disable the call ourselves. #10733.
I can reproduce this on my machine as well.
Environment:
Repro observed in Codex Desktop:
Impact:
This looks consistent with a Windows 10 build 19045 compatibility issue around
SetIsBorderRequired/GraphicsCaptureSession.IsBorderRequired. Feature-detecting that API and skipping it on unsupported Windows 10 builds would likely unblock desktop app control.please fix this
Additional sanitized repro on a newer Codex Desktop build.
Environment:
26.602.4072410.0.19045149.0.7827.54computer-use/26.602.30954What works:
sky.list_apps()works.sky.launch_app(...),sky.get_window(...), andsky.activate_window(...)work with Notepad.include_text: truecan return UIA/accessibility text in some windows.What fails:
Calling screenshot capture for Notepad fails consistently:
Observed error:
Impact:
This leaves Computer Use limited to non-visual operations. Visual inspection, coordinate clicking, dragging, scrolling, and normal screen-state verification are blocked because screenshot state cannot be established.
This reproduces with Notepad only; no third-party or private application is needed. The behavior still looks consistent with the helper calling
GraphicsCaptureSession.IsBorderRequired/SetIsBorderRequiredon Windows 10 build19045, where that API/property appears unsupported.Since Windows is supposed to be officially supported now, it would be great for there to be a Windows VM smoke test before releasing new app/plugin versions to make sure it at least launches and can do basic functionality. Windows support was announced but is definitely not a first-class feature right now.
Any news? :(
Windows Computer Use capture/input recovery
Date: 2026-06-18
Target tested:
openai-bundled/computer-use/26.611.61753codex-computer-use.exe%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exeDFECD6E73B5D6EFA2383CEB1F73BFB4AEA02769CBE4481CD29711FFA79B8A3486995DDE1A975CA2E0581CC96A46E23F01DEC8ABF00ED31052E3533FBCFA2A4ACThis document describes a local field patch used to restore Windows Computer Use enough to control Microsoft Paint and draw using
click,drag, and screenshot verification. The binary offsets below are diagnostic/workaround material for this exact build layout, not a recommended upstream patch strategy.Summary
Several independent failures blocked Windows Computer Use:
GraphicsCaptureSession.SetIsBorderRequiredfailed.SoftwareBitmap.CreateCopyFromSurfaceAsyncinside/near the frame callback path.GetCursorPoswith access denied (0x80070005).The successful local recovery used:
PrintWindow(PW_RENDERFULLCONTENT)withGetWindowDC/BitBltfallback.click/dragrouted through the existing native pipe rather than ad hoc foreground input.click/drag.GetCursorPosand bounds repair.Reproduction symptoms
Typical failures observed from the helper:
After the fixes, a normal Paint workflow succeeded:
list_apps()andget_window().get_window_state().click.drag.Investigation notes
Capture path
The first blocker was
SetIsBorderRequired failed. Treating this as fatal prevents capture on systems where this optional visual border setting is unavailable or denied. Bypassing this check allowed capture setup to proceed further.The next blocker was in the frame path. Instrumentation around
FrameArrived,TryGetNextFrame, andSoftwareBitmap.CreateCopyFromSurfaceAsyncshowed that a synchronous wait in the copy path could time out even though completion-related events happened immediately after the frame callback returned. This is consistent with a callback/threading deadlock or reentrancy issue: the handler waits for an async WinRT operation whose completion is not delivered until the handler unwinds or the relevant dispatcher/thread is allowed to progress.Observed trace pattern:
The local JS fallback avoids this WGC path for screenshots by asking the native helper for the window/accessibility state without a screenshot, then adding a GDI screenshot.
Input path
Native input initially failed before sending events because
GetCursorPosreturned access denied. This appears to be tied to cursor overlay/state setup rather than the actual ability to send input. ReplacingGetCursorPoswith a safe success value allowed the input pipeline to proceed.After that, input failed on impossible window bounds. A Frida hook at the bounds preparation site showed that rewriting the state from
GetWindowRect(hwnd)produced stable dimensions and let input pass validation.Finally, at 125 percent display scaling, the GDI screenshot size was
1152x610, while native input expected logical coordinates. Dividing screenshot coordinates byGetDpiForWindow(hwnd) / 96made high-levelclick/dragalign with the actual Paint UI.Local JS client patch
File patched:
1. GDI screenshot fallback
The patched
NativePipeComputerUseClient.get_window_statedoes this on Windows when screenshots are requested:include_screenshot: falseandinclude_text: true.GetWindowRect(hwnd)for window bounds.PrintWindow(hwnd, hdc, 2)first.PrintWindowfails, useGetWindowDC(hwnd)plusBitBlt.id: "gdi-window",originX,originY,width,height, andzIndex.Source-level recommendation:
PrintWindow(PW_RENDERFULLCONTENT)and then toGetWindowDC/BitBlt.2. Native input routing and DPI conversion
The patched proxy routes high-level
clickanddragthrough the existing native pipe:The conversion function queries DPI using
GetDpiForWindow(hwnd)and divides screenshot coordinates bydpi / 96before passing them to native input:Source-level recommendation:
coordinateSpaceanddpiScalemetadata and let the client convert.Runtime hooks used for diagnosis/workaround
GetCursorPoshookThis was enough to bypass
GetCursorPos failed: Access is deniedand continue with input.Source-level recommendation:
GetCursorPossuccess mandatory for input.Bounds repair hook
The hook ran at image RVA
0xAB4A3and rewrote the native state fromGetWindowRect(hwnd). The observed state layout in this build:state + 0xF8:HWNDstate + 0x198: validity flagstate + 0x19C: origin Xstate + 0x1A0: origin Ystate + 0x1A4: widthstate + 0x1A8: heightstate + 0x1AC: extra/unknown field set to zeroSource-level recommendation:
DwmGetWindowAttribute(DWMWA_EXTENDED_FRAME_BOUNDS)where appropriate.GetWindowRect(hwnd)as a fallback.GetClientRectplusClientToScreenif the input API expects client coordinates.Binary patches observed in the local helper
These offsets are for the tested build layout only. They are useful to correlate native code sites but should not be shipped as a binary patch.
| Purpose | File offset | Local patched bytes | Notes |
| --- | ---: | --- | --- |
| Bypass fatal
SetIsBorderRequiredbranch |0xBB651|90 90 48 8B 8D E0 01 00 00 48 8B 01 FF 50 30 89| Original branch was observed as75 3E; patched to NOP/NOP. || Async wait timeout argument restored after experiments |
0x124949|BA FF FF FF FF FF 15 94 8E 00 00 48 89 F1 48 83| This is not the final fix. Blocking forever also deadlocks; the real fix is to avoid synchronous waiting in the frame callback path. || Bypass coordinate gate branch |
0xAA8B2|90 90 8B 82 AC 01 00 00 89 46 14 0F 10 82 9C 01| Original branch was observed as75 1E; patched to NOP/NOP. Runtime bounds repair was still needed. || Activation failure bypass |
0xA22FA|E9 D1 FF FF FF 90 90 6A 45 5A 48 81 C4 F8 00 00| Replaced a failing error path with a jump to continue. Should be replaced by clearer activation fallback/retry logic. ||
RoInitializecall site |0x7E7F6|31 C9 E8 A2 1C 00 00 90 4C 8D 05 DB 71 0B 00 6A| STA/MTA experiment was reverted. Current code initializes with argument zero. |Recommended upstream fixes
Capture
SetIsBorderRequired(false)as best effort.StartCapture.FrameArrivedcopy path.SoftwareBitmap.CreateCopyFromSurfaceAsync.PrintWindow(PW_RENDERFULLCONTENT)and thenBitBlt.Input
GetCursorPos, cursor suppression, or overlay animation fails, continue with input if the target window is valid.x/yare physical window pixels, logical window pixels, or client pixels.dpiScaleandcoordinateSpacewith screenshots and centralize conversion.JS client
Suggested regression tests
get_window_state({ include_screenshot: true })succeeds on Paint.get_window_state({ include_screenshot: true, include_text: true })returns both screenshot and accessibility text.clickselects a Paint color by screenshot coordinates.dragdraws a visible line on the Paint canvas.PrintWindow/BitBltwithout crashing the request.GetCursorPosfailure injection does not prevent click/drag.Validation result
Using the above local recovery, Paint was controlled through Computer Use and produced visible drawings using real
clickanddragactions. Final verification screenshots were saved as:outputs\pikachu-paint-final.pngoutputs\pikachu-paint-second.pngThis demonstrates that the native pipe, target activation, click, drag, and screenshot verification can work once the capture fatal path, cursor-position dependency, bounds corruption, and DPI mismatch are addressed.
Ready-to-run patch script
A companion PowerShell script is included as:
Typical usage from the directory containing the script:
The script intentionally does not hard-code any local username. It discovers paths from
$env:USERPROFILEand$env:LOCALAPPDATA, backs up modified files, applies the JS fallback/input patch, applies the helper binary byte patches for the tested build, and optionally attaches the runtime Frida hooks needed for theGetCursorPosand bounds issues.If
frida-inject-*-windows-x86_64.exeis not discoverable next to the script, in the current directory, or in Downloads, pass it explicitly:Safety switches:
Powerhell Script (Save to your disk and name it
apply-cua-windows-workaround.ps1)Success Pic
<img width="1152" height="610" alt="Image" src="https://github.com/user-attachments/assets/233ecd99-6d74-4464-bc64-82c0b4a65d99" />
Update: Still broken after upgrading to 1.2.14
Upgraded from 1.2.9 to 1.2.14, but this bug is still not fixed.
Status Summary
| Item | Status |
|------|--------|
| Version upgraded | ? 1.2.9 ? 1.2.14 |
| Screenshot still broken | ? Same
SetIsBorderRequirederror || Text / accessibility tree | ? Working |
| Window operations (activate, list) | ? Working |
Error (unchanged)
Environment
This confirms the fix has not been shipped in 1.2.14. The
SetIsBorderRequiredcall still fails on Windows 10 build 19045.Please prioritize this - Windows Computer Use is partially unusable without screenshots.
The rebranded ChatGPT Desktop App (26.707.30751, released Jul 9, 2026) has the same problem. I don't want to post a bunch of "still not fixed" messages, but figured with the new app that it was useful to confirm.
anyone fix this ???
Still happening on Windows 10. Asked GPT-5.6 Sol Medium, with Computer Use enabled, to use the open Chrome window on my YouTube Playlists tab to extract the names of the songs from all playlists. Screenshot attached.
<img width="744" height="813" alt="Image" src="https://github.com/user-attachments/assets/f12b98a3-566c-4b46-9214-f49bc1926d54" />
need fixed this bug too!
Still reproducible on a newer 26.707 build.
Environment:
A fresh projectless diagnostic task tested five new owned specimens:
All five screenshot requests failed with the same error:
Window enumeration, activation, foreground verification, and accessibility-only UI reads worked. The failure is not Blender-specific; it is the Windows screenshot capture path. All owned processes and disposable profiles were cleaned up, with residue 0.
Focused diagnostic session available for private sharing through in-app feedback:
019f65ef-2366-7a51-ba48-b5c492c24115The parent/coordinator thread is
019f60fc-2f41-7ce3-9f1b-051cbe51eec4, but it contains unrelated PR validation history, so the focused child is the better artifact.