macOS Computer Use can deliver coordinate clicks at the physical cursor position in SDL windows

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.70816

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS 26.5.1)

What issue are you seeing?

Summary

On macOS, a coordinate click requested through Codex Desktop Computer Use can reach an SDL canvas at the current physical cursor position rather than the requested target coordinate. When the cursor is outside the target window, SDL receives a clamped edge coordinate. The action reports success, but the intended control is not activated.

This is distinct from a visual coordinate-scaling problem: the LVGL button geometry is correct, while the application's SDL event log records a different input location.

Environment

• ChatGPT / Codex Desktop: 26.908.70816
• Computer Use helper: 26.913.1001067
• macOS: 26.5.1 (Darwin 25.5.0 arm64 arm)
• Target: local SDL/LVGL simulator, 1280 x 800 content area

Observed result

The simulator's Verify button occupies window-local x=1025..1195 and y=243..283, with center (1110, 263). A Computer Use click aimed at the visible Verify button was requested through the app surface. The tool call completed without error, but the application's SDL event watch logged:

event SDL_MOUSEBUTTONDOWN xy 1279 799 window 3
event SDL_MOUSEBUTTONUP   xy 1279 799 window 3

The click therefore landed at the bottom-right edge instead of on Verify, so no UI state change occurred. Repeating the call with a different requested coordinate follows the actual cursor location/clamping behavior rather than reliably reaching the requested point.

The target window was focused and Screen Recording and Accessibility permissions were available. The app has no accessibility element for the canvas control, so AX state does not reveal this failure.

What steps can reproduce the bug?

1. Run an SDL application with a 1280 x 800 window and an input control centered at window-local (1110, 263).
2. Add an SDL event watch that records SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP event.x/event.y.
3. Put the physical cursor outside the target window (or at another known point).
4. Use Codex Desktop Computer Use to click the visible control by coordinates.
5. Compare the requested target with the SDL log.

Expected for the control above: SDL receives down/up at (1110, 263).

Observed in this reproduction: SDL received down/up at (1279, 799), consistent with an off-window physical cursor being clamped to the target window bounds.

A useful control is to move the physical cursor to (1110, 263) with a real global HID move/click before testing: SDL then receives (1110, 263) exactly.

What is the expected behavior?

Coordinate-based Computer Use actions should deliver mouseMoved, mouseDown, and mouseUp to the requested target point in the target window. A successful tool response must not silently substitute the physical cursor position. If reliable coordinate delivery is unavailable for a window, the tool should return a clear failure rather than report success.

Additional information

Related but not identical: https://github.com/openai/codex/issues/43119 reports coordinate-action failures in other macOS applications. This report focuses on silent misdelivery to an SDL canvas with application-side event-log evidence. No screenshots, logs containing personal data, or external files are attached.

Start by tracing the macOS Computer Use coordinate-action path and compare its requested target with the SDL event watch output described in the report. Reproduce with the cursor outside the target window, then verify that SDL receives the requested coordinates rather than the clamped physical cursor position and that unsupported delivery reports failure instead of success.