[macOS] Computer Use cannot target Godot window: noWindowsAvailable / timeoutReached despite live CoreGraphics window

Summary

On macOS, Codex Computer Use cannot reliably target a visible Godot 4.6.3 editor window.

Initially, Computer Use could acquire Godot, read its accessibility tree, capture a current screenshot, and interact with a native menu. However, a coordinate click on the visible Run button immediately failed with:

Computer Use server error -10005: noWindowsAvailable

Manual clicking of the same Run button launched the project successfully.

Later, Computer Use stopped being able to reacquire Godot at all:

Computer Use server error -10005: timeoutReached

This persisted even though CoreGraphics showed a live, titled Godot editor window owned by the editor process, and persisted after restarting only SkyComputerUseService.

A macOS Accessibility workaround that targeted the exact existing Godot editor PID and sent Godot's macOS Play shortcut (Command+B) launched the project successfully. This isolates the failure to Computer Use's Godot app/window targeting path rather than Godot, CoreGraphics, or macOS Accessibility.

Environment

• ChatGPT desktop: 26.908.70816
• Codex CLI: 0.154.0
• Godot: 4.6.3
• Platform: macOS, Apple Silicon
• Project: local Godot project
• Godot bundle ID: org.godotengine.godot

Initial reproduction

1. Open the Godot editor with a local project.
2. Acquire Godot with:

   cua.getApp('org.godotengine.godot')
   

3. Fetch a fresh full Computer Use state.
4. Confirm Computer Use can:
   • read the editor accessibility tree;
   • capture a current screenshot;
   • see the visible Run/Play icon;
   • interact with a native Godot menu.
5. Perform a coordinate click on the visible Run button.
6. Observe immediate failure:

   Computer Use server error -10005: noWindowsAvailable
   

7. Manually click Run in the same editor.
8. The project launches normally.

No game process appeared from the failed Computer Use coordinate click.

Accessibility-element route

A fresh full accessibility state exposed only the Godot editor window/menu-bar structure. The visible Run/Play toolbar button was not exposed as an accessibility element, so an element-ID click could not be used as a workaround.

Subsequent acquisition failure

After further read-only diagnostics, direct acquisition began consistently failing:

await cua.getApp('org.godotengine.godot')

Result:

Computer Use server error -10005: timeoutReached

Fresh state requests through the existing Godot binding also timed out.

At one point, another Codex session briefly ran headless Godot tests. Those tests finished, and the failure persisted with only the interactive editor process remaining. The original noWindowsAvailable click failure had already been observed before this became relevant, so multiple Godot processes are not required for the original failure.

Independent window evidence

CoreGraphics enumerated multiple windows owned by the remaining interactive Godot editor process, including a titled main editor window with normal full-editor bounds.

The main window title had the expected Godot format:

<scene> - <project> - Godot Engine

A separate System Events query could see the Godot application process but reported zero windows, while CoreGraphics clearly enumerated the titled editor window and Computer Use had intermittently captured it earlier.

Helper restart did not recover targeting

With the other Codex session idle, only SkyComputerUseService was restarted. The helper PID changed, confirming that the service process restarted.

After the helper restart:

await cua.getApp('org.godotengine.godot')

still returned:

Computer Use server error -10005: timeoutReached

Godot itself and the Codex sessions were not restarted.

Verified workaround

Using ordinary shell execution, macOS Accessibility/System Events targeted the same existing editor PID and sent Godot's macOS Play Project shortcut:

EDITOR_PID=<current Godot editor PID>

osascript \
  -e 'tell application "System Events"' \
  -e "set targetProcess to first application process whose unix id is $EDITOR_PID" \
  -e 'set frontmost of targetProcess to true' \
  -e 'delay 0.5' \
  -e 'keystroke "b" using {command down}' \
  -e 'end tell'

The AppleScript exited successfully and launched the project.

Verification found a new Godot game process, and CoreGraphics registered its debug game window with normal bounds. A verification screenshot visibly confirmed that the game reached its title screen.

No project files were modified.

Expected behavior

Once Computer Use can capture/read a visible Godot editor window, coordinate input should resolve to that same window. If the app/window association becomes stale, cua.getApp() should rediscover/rebind to the live CoreGraphics window instead of returning noWindowsAvailable or repeatedly timing out.

It would also be useful for Computer Use to support unambiguous PID/CGWindow selection when an application may create multiple processes with the same bundle ID.

Actual behavior

The Computer Use read/capture and input/targeting paths become inconsistent:

• the Godot editor is visibly present;
• CoreGraphics can enumerate its titled window;
• manual input works;
• direct Accessibility input to the exact Godot PID works;
• but Computer Use coordinate input returns -10005: noWindowsAvailable;
• later cua.getApp('org.godotengine.godot') returns -10005: timeoutReached;
• restarting only SkyComputerUseService does not recover the Godot binding.

Related reports

This appears related to, but is not an exact duplicate of:

• #36459 — fresh macOS app state succeeds, coordinate click fails with -10005: noWindowsAvailable
• #38508 — Computer Use loses scrolling/input control across macOS apps
• #43119 — coordinate click/drag fails with -10005: noWindowsAvailable in Safari/Krita while other paths work
• #43386 — app-specific cua.getApp() -10005: timeoutReached while Computer Use remains otherwise available

This report adds a Godot-specific reproduction, direct CoreGraphics window enumeration, failure to recover after restarting only the Computer Use helper, and a successful exact-PID macOS Accessibility launch as a control/workaround.

Start by reproducing the failure through cua.getApp('org.godotengine.godot'), fresh state capture, and a coordinate click while observing SkyComputerUseService. Compare the Computer Use target with the live CoreGraphics window and the exact-PID Accessibility workaround; done means a visible Godot window can be reacquired and coordinate input succeeds without noWindowsAvailable or timeoutReached.