Native GUI / Computer Use Tools for Desktop Automation

Resolved 💬 4 comments Opened Apr 3, 2026 by s-JoL Closed Apr 16, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI, App

What feature would you like to see?

Codex currently operates exclusively through CLI tools — it cannot see, click, or interact with graphical applications. Many real-world development tasks require GUI interaction: testing desktop apps, navigating browser-based tools, or automating repetitive UI workflows.

Claude Code shipped native computer use capabilities in its March 2026 research preview. Codex should have this too.

Working implementation

I've built a working implementation: codex-cua — a fork of Codex with native GUI / computer use tools integrated into the Rust codebase. It is fully functional on macOS today. See PR #3 for the full implementation.

Demo:

!GUI Demo

Tool set:

| Tool | Purpose |
|------|---------|
| gui_observe | Capture a screenshot and optionally ground a semantic target |
| gui_click | Click a UI element by semantic description or coordinates |
| gui_type | Type text into a focused or targeted input field |
| gui_key | Press keyboard shortcuts and special keys |
| gui_scroll | Scroll within a targeted area or the current surface |
| gui_drag | Drag from one element/location to another |
| gui_move | Move the cursor to an absolute position |
| gui_wait | Wait for a visual condition to appear on screen |

Implementation details

  • Semantic grounding — Rather than relying solely on the model to output raw pixel coordinates, the agent describes what it wants to interact with (e.g., target: "the Save button in the toolbar") and a grounding engine resolves the description to screen coordinates. This decouples targeting accuracy from the primary model's vision capabilities and is more robust across resolutions and layouts.
  • First-class observability — 8 GUI tools integrated as BuiltinToolCall turn items (like exec commands and MCP tool calls) with full lifecycle tracking (inProgress → completed/failed), visible in TUI/CLI and available in JSONL output.
  • Safety-first — Experimental feature flag (disabled by default), emergency stop via physical key (Escape), physical resource locking to prevent concurrent sessions, host window exclusion to prevent the agent from interacting with its own terminal, and automatic hiding of non-target apps during GUI actions.
  • Platform abstraction — A trait-based platform layer allows incremental platform support. macOS is implemented with a Windows stub ready.
  • Grounding engine — Multi-round validation with refinement cropping, HiDPI-aware capture across Retina displays, and dual grounding modes (simple prediction or complex multi-round validation with simulation overlays).

Background

The design of codex-cua's GUI tools was inspired by Understudy, my open-source local AI agent project (TypeScript). Understudy operates your entire computer — GUI, browser, shell, messaging — from a single instruction. The semantic grounding approach, observe-act-verify loop, safety layers, and platform abstraction pattern in codex-cua all originate from Understudy's architecture.

Additional information

Would love to hear from the community:

  • Is native GUI / computer use a direction the Codex team is considering?
  • What safety and security concerns should be addressed first?
  • Would a PR toward upstream integration be welcome?

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15838

Powered by Codex Action

m13v · 4 months ago

the codex-cua implementation referenced here is a solid start. from building a cross-platform desktop automation framework, a few thoughts on what makes GUI tools production-ready:

the screenshot+coordinate approach (like Claude's computer_20251124 tool) works for demos but breaks in practice. resolution changes, DPI scaling, notification popups, and dark mode toggles all shift pixel coordinates. the more reliable path is querying the OS accessibility tree (UI Automation on Windows, AXUIElement on macOS) to find elements by role and label, then clicking by element reference instead of pixel position.

for codex specifically, the biggest win would be a gui_find_element tool that returns a structured list of interactive elements from the accessibility tree. the model picks the element it wants, then calls gui_click with that element ID. no coordinate guessing, no vision model overhead per click, and it works even when the window isn't in the expected position.

the dual approach works best: accessibility tree for apps with good labels (most native apps, Electron apps with accessibility enabled), screenshot+vision for apps with custom-rendered UI. this covers the vast majority of desktop automation use cases while keeping the common path fast.

m13v · 4 months ago

the accessibility-based element interaction approach I described, implemented as a cross-platform Rust framework: https://github.com/mediar-ai/terminator/blob/main/crates/terminator/src/element.rs

handles UI Automation on Windows and AXUIElement on macOS behind a common interface. the MCP server wrapping it: https://github.com/mediar-ai/terminator/blob/main/crates/terminator-mcp-agent/src/server.rs

etraut-openai contributor · 4 months ago

We announced today that the new Codex app now supports computer use. This will work in normal Codex threads as well as threads created through automations.

See this article for more details.