macOS Computer Use returns blank wrong-sized capture on sole external display and times out for LSUIElement apps

Open 💬 1 comment Opened Jul 10, 2026 by johnsilvavlogs

What version of the Codex App are you using?

ChatGPT desktop app 26.707.31428 (build 5059) with the bundled Codex Computer Use integration.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

  • Darwin 25.5.0 arm64 arm
  • macOS 26.5.1
  • MacBook in closed-clamshell mode
  • Exactly one active external HDMI display (QCQ90)
  • CGMainDisplayID=5, built-in flag 0, logical resolution 2304x1296, scale factor 2.0

What issue are you seeing?

A fresh Computer Use session does not consistently bind capture and app discovery to the sole active external main display. Two related symptoms reproduce in the same display topology:

  1. get_app_state for Finder returns Accessibility data quickly (about 307 ms) but the JPEG is blank and 1366x768, which does not match the active main display's 2304x1296 logical geometry. This is evidence of a wrong, stale, or synthetic capture canvas. It is not enough evidence to claim that 1366x768 is definitively the closed built-in panel.
  2. get_app_state for SystemUIServer, com.johnsilva.LidSwitch, or the LidSwitch app path each fails after about 5.05 s with SkyComputerUseError -10005: timeoutReached. Both SystemUIServer and LidSwitch are LSUIElement / UIElement-style targets. list_apps reports SystemUIServer as not running and omits the live LidSwitch process, even though both are live outside Computer Use.

Relevant logs during the failures contain:

AccessibilitySupport.UIElementError 0
AccessibilitySupport.UIElementError 2
Fetching all shareable content

There is no SCStreamErrorDomain -3811 in this reproduction. Finder AX succeeding also argues against a total Accessibility outage.

What steps can reproduce the bug?

  1. Connect one external display to a MacBook and use it in closed-clamshell mode.
  2. Verify the external display is the sole active main display. In this reproduction it is display ID 5, built-in 0, logical 2304x1296, scale 2.0.
  3. Start a fresh Codex/Computer Use task.
  4. Call list_apps.
  5. Call get_app_state for Finder.
  6. Observe that AX content returns but the screenshot is a blank 1366x768 JPEG rather than content sized/bound to the active external display.
  7. Call get_app_state for an LSUIElement app or menu-bar process, using its display name, bundle ID, and app path where available.
  8. Observe a roughly five-second SkyComputerUseError -10005: timeoutReached; also observe that live UIElement apps may be missing or marked not running in list_apps.
  9. Reopen the lid or disconnect/reconnect the external display and repeat to test display-topology invalidation.

What is the expected behavior?

  • Display capture should resolve the current CGMainDisplayID and active ScreenCaptureKit display at request time, and the returned image should correspond to that display rather than a stale or synthetic canvas.
  • list_apps should distinguish ordinary windowed apps from live LSUIElement/menu-bar apps instead of reporting a live process as absent or not running.
  • UIElement targets should return AX/capture state when supported, or fail immediately with a typed unsupported_target, no_window, or not_shareable diagnostic. They should not collapse discovery failures into a generic five-second timeout.

Additional information

This appears to be one target-resolution failure class with two adjacent surfaces: display selection for capture and process/window eligibility for UIElement apps. A systemic guard would snapshot and validate the active display/process topology before capture, invalidate cached display/window IDs on clamshell or reconnect changes, and reject a returned frame whose geometry/source metadata does not match the resolved target.

Suggested regressions:

  • Closed-clamshell, exactly one external display: Finder returns nonblank AX plus a frame sourced from the active external main display.
  • Clamshell transition and external-display disconnect/reconnect: cached display/window IDs are refreshed before the next request.
  • Live LSUIElement menu-bar app: inventory identifies it accurately, and state retrieval either succeeds or returns a typed immediate unsupported/no-window result.
  • Ordinary windowed app and UIElement app in the same session: the UIElement failure path must not poison subsequent normal capture.

Existing reports checked but not exact duplicates:

  • #21668 and #24301: wrong Space/window capture, not a blank wrong-sized frame with one active external display.
  • #27829 and #30797: cgWindowNotFound for normal windowed apps, not UIElement inventory plus timeoutReached.
  • #24086: locked Computer Use on a Mac mini with Studio Display; this reproduction is an unlocked MacBook in clamshell mode.
  • #30846: SCStreamErrorDomain -3811; that error is absent here.

Exact GitHub searches performed before filing included: "Computer Use" "external display", "blank screenshot" macOS, LSUIElement, SkyComputerUseError, timeoutReached, SystemUIServer, "Computer Use" clamshell, "Computer Use" monitor, "list_apps" macOS, UIElement "Computer Use", "menu bar" "Computer Use", "external monitor" "Computer Use", "external display" screenshot, "1366x768", and "timeout" "SystemUIServer", all scoped to repo:openai/codex is:issue.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗