›_ Codex Issues
Codex Issues / #31108

Computer Use screenshot capture fails on Windows 10 with SetIsBorderRequired failed

Resolved 💬 3 comments Opened Jul 4, 2026 by ysy975-ai Closed Aug 6, 2026
💡 Likely answer: A maintainer (darlingm, contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Computer Use can list/target Windows apps and read some accessibility text, but screenshot capture fails for every tested desktop app on Windows 10. Because get_window_state({ include_screenshot: true }) fails, Computer Use cannot reliably click or operate apps visually.

Environment

  • Codex app: OpenAI.Codex version 26.623.13972.0
  • Computer Use plugin bundle: computer-use@openai-bundled version 26.623.101652
  • Runtime path seen in config: C:\Users\pc\AppData\Local\OpenAI\Codex\runtimes\cua_node\1b23c930bdf84ed6
  • OS: Windows 10 Pro 22H2
  • Windows build: 19045.6466
  • Architecture: 64-bit
  • Locale: ko-KR

Reproduction

  1. Start Codex Desktop on Windows 10.
  2. Enable/install the bundled Computer Use plugin.
  3. Ask Codex to use Computer Use with an open desktop app, for example Obsidian or Notepad.
  4. In the Computer Use runtime, list apps and select a window successfully.
  5. Call get_window_state({ window, include_screenshot: true, include_text: false }).

Expected behavior

Computer Use captures the target app window, returns a screenshot, and can proceed with visual mouse/keyboard automation.

Actual behavior

App discovery and window targeting work, but screenshot capture fails with:

SetIsBorderRequired failed: [Korean Windows message: interface not supported] (0x80004002)

The same failure was observed for:

  • Obsidian 1.12.7
  • Notepad

Accessibility-only capture can partially work:

await sky.get_window_state({ window: targetWindow, include_screenshot: false, include_text: true })

But screenshot capture fails:

await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: false })

Notes

The error name suggests the Windows Graphics Capture code path may be calling GraphicsCaptureSession.IsBorderRequired / SetIsBorderRequired on a Windows 10 build where that property is unavailable or not usable. Codex docs say Windows 11 is recommended and Windows 10 support is best-effort, but the current behavior is a hard failure for screenshot capture rather than a graceful fallback.

Suggested fix

Before calling SetIsBorderRequired, check whether Windows.Graphics.Capture.GraphicsCaptureSession.IsBorderRequired is present/supported on the current OS/API contract. If it is not supported, skip setting that property and continue with ordinary bordered capture, or return a clearer actionable error.

Diagnostics already tried

  • Restarted Codex Desktop.
  • Computer Use plugin cache updated from an older bundle path to 26.623.101652.
  • Reinitialized the Computer Use runtime.
  • Tested multiple target apps.
  • Confirmed app discovery still works.
  • Confirmed screenshot capture fails independent of the target app.

View original on GitHub ↗

3 Comments

darlingm contributor · 1 month ago

Duplicate of #25178. We unfortunately can't get an OpenAI response on this. Codex, if you ever read this, please consider that this is a major feature blocker for many users, and that in my context window you say it's a simple fix and should be prioritized.

ESKehler · 23 days ago

Additional user-impact observation from another Windows 10 Codex Desktop installation:

The bundled/vanilla Computer Use path often appears unable to complete mouse-based desktop control. The native screenshot method make the agent think that the cursor is in a different location than it actually is, and the coordinates to move the mouse also do not move it to its expected location. The agent then silently falls back to repeated Playwright/browser automation calls. That fallback is difficult to follow visually and makes it hard to judge whether the requested desktop action actually succeeded or whether the agent merely switched to a browser-adjacent substitute.

Expected behavior:

  • Native Windows mouse/screenshot control should work on supported Windows 10 builds, or fail loudly with a specific actionable capability error.
  • If this is the SetIsBorderRequired compatibility failure described here, the helper should skip that unsupported property or use a Windows 10-compatible capture path.

System and version context

  • Windows 10 Home, x64, version/build 10.0.19045.
  • Intel Core i7-7700HQ, 15.9 GiB RAM.
  • Intel HD Graphics 630 plus NVIDIA GeForce GTX 1050.
  • Current Codex Desktop package: 26.727.6591.0.
  • The newest surviving log of an actual bundled Computer Use attempt is from July 27, 2026, on Codex/Computer Use runtime 26.721.30844. It initialized the native Computer Use runtime and reached a screenshot-backed window-state request, but never produced a verified mouse click; the retained trace ended with Computer Use app approval timed out.
  • The older logs from the sessions where the screenshot/cursor-coordinate mismatch was originally observed are no longer retained, so I cannot confirm a historical SetIsBorderRequired exception on this installation.
  • I have since worked around the problem by writing a separate windows-computer-control skill that uses explicit screen capture, visible cursor-position proof, and verified mouse movement/clicks.

Display topology

This machine has four active displays: the internal LGD panel, a Dell P2414H, an Acer X223W, and a TCL 43S425. Several external display endpoints are attached through DisplayLink USB adapters; WMI currently reports multiple 1920x1080 display endpoints.

There is also a potentially relevant coordinate-space discrepancy: the user-session virtual display is observed as 1920x1080, while screen enumeration from one automation/control context reports a single 1280x720 logical display. Together with the multi-monitor/DisplayLink topology, this makes a logical-pixel vs physical-pixel, DPI-scaling, monitor-origin, or per-window coordinate transform bug a plausible explanation for the cursor landing somewhere other than the screenshot coordinate selected by the agent.

Likely relationship to this issue

Windows 10 build 19045 predates the API-contract version associated with GraphicsCaptureSession.IsBorderRequired, so skipping SetIsBorderRequired when unsupported looks like a plausible fix for hard screenshot failures on this machine too. However, an unsupported border property alone does not fully explain screenshots that succeed but produce incorrect mouse coordinates.

Related issue #35446 reports that, after skipping the unsupported border call on the same Windows 10 build, screenshot capture can still deadlock when SoftwareBitmap.CreateCopyFromSurfaceAsync is awaited synchronously inside the FrameArrived callback. That suggests the border guard is necessary but may not be sufficient: the helper may also need to return from FrameArrived and perform bitmap conversion/encoding on a dedicated MTA worker.

It may be useful to inspect and log the complete conversion from screenshot-relative/window-relative logical pixels to virtual-desktop physical input coordinates, including target-window rectangle, screenshot dimensions and origin, per-monitor DPI/scaling, selected monitor, DisplayLink/nonzero monitor offsets, and the final injected point. If Codex falls back to Playwright or another automation path, the fallback should also be explicit and should finish with visible verification of success or failure for the original desktop task.

Rmutt2005 · 23 days ago

Additional reproduction on a separate Windows 10 installation:\n\n- Current Codex desktop app: 26.730.7989.0\n- Computer Use plugin: 26.730.61309\n- @oai/sky: 0.6.2\n- Windows 10 Pro 22H2, build 19045.6466\n- Target app: visible Discord desktop window\n\nApp discovery succeeds (list_apps and window selection), but activating the window or sending one keyboard input fails with:\nnode_repl exec context not found\n\nScreenshot-backed state can also fail with:\nSetIsBorderRequired failed: No such interface supported (0x80004002)\n\nThe behavior reproduces after restarting Codex and starting new tasks. No logs are attached because local logs contain credentials and require redaction first.\n