Codex, cross-platform, and accessibility APIs. There is no single API. There are three.

The Codex chat app does run on Windows (and the CLI runs on Linux), but the part of Codex that reads UI state from another app and clicks back into it (Computer Use) does not. OpenAI's Computer Use page is direct about this: computer use is currently available on macOS, except in the European Economic Area, the United Kingdom, and Switzerland at launch. Windows and Linux are described as on the roadmap with no published date. So if your question is can Codex read a value out of an open SAP window on Windows by walking the accessibility tree, today the answer is no. The Windows desktop app does not expose that surface yet.

Because shipping the same agent on three operating systems is three engineering projects, not one. macOS gives you AXUIElement and a Cocoa-shaped accessibility hierarchy. Windows gives you UI Automation (UIA), a COM-based API with a different tree shape, different role names, and a different permission model. Linux gives you AT-SPI over D-Bus, which is the assistive interface most desktop environments expose but plenty of apps under-implement. There is no library that hides all three behind one function call without losing fidelity. OpenAI shipped the macOS half first; until the other two land, Computer Use is single-platform.

There are abstraction layers, but they are thin and they leak. xa11y is an MIT-licensed Rust library that exposes a CSS-selector style query against AXUIElement, UI Automation, and AT-SPI2; it has Python and Node bindings. AccessKit goes the other direction: it is for UI toolkit authors who want to push accessibility data into the three platform APIs, not for agents that want to read it. Igalia's acacia inspects platform accessibility APIs but stops short of a one-line cross-platform call. In practice, any production agent that targets more than one OS ends up with a per-platform reader plus a shared schema, the same shape every browser uses internally. There is no one-line API, and pretending there is one is the fastest way to ship a brittle agent.

Per OpenAI's launch docs, Codex captures screenshots and the visible window content, and it can interact with windows, menus, keyboard input, and clipboard state. The MacStories writeup describes it as reading the accessibility hierarchy of any open macOS app, which lets the model produce precise coordinates instead of guessing from pixels. The data flow point worth knowing: screenshots and visible content become part of Codex's processing context and are subject to ChatGPT's data controls. That means the AX tree dump and the pixels both leave the Mac during a task. Different from a fully local agent that walks the same tree and never uploads it.

Fazm is macOS only by design, runs the same kind of AXUIElement loop Codex Computer Use does, and ships an open-source implementation you can read. The permission probe lives at Desktop/Sources/AppState.swift around line 488: it calls AXUIElementCreateApplication on the frontmost app, then AXUIElementCopyAttributeValue for kAXFocusedWindowAttribute, and if the call returns cannotComplete it tries again against Finder as a control to rule out Qt or OpenGL apps that don't implement AX. That fallback logic is macOS-specific and does not translate to UI Automation or AT-SPI. The honest version of cross-platform for the same team is shipping a second codebase, in our case the Windows-only Rust project at github.com/mediar-ai/terminator, which uses UI Automation. Two repos, one product family, because there is no shared reader.

If the app speaks AT-SPI cleanly (most GTK and Qt apps, browsers, Electron with a recent runtime), you can walk the tree directly with pyatspi2 or the AT-SPI D-Bus interface. If it doesn't, you fall back to one of the older techniques: scrape window state with xdotool, OCR a screenshot, or use the app's network traffic. The honest constraint: no large-vendor desktop agent ships AT-SPI today. Anthropic's computer use targets macOS and Windows. OpenAI's Codex targets macOS. Self-hosted is your option until that changes.

Because the per-turn cost is real and the model can hallucinate coordinates. Anthropic publishes a tool-definition cost of around 735 tokens and a system-prompt cost of around 480 tokens for the screenshot-driven Computer Use tool, plus the screenshot itself up to 1568 pixels on the long edge, every turn. A single AXUIElementCopyAttributeValue call returns structured text in one CoreFoundation round trip, and the model gets a string it can reason over instead of a region of an image it has to ground. For tasks that touch a button with a label, accessibility-API agents beat screenshot loops on speed, cost, and reliability. For tasks that touch a canvas (Figma, Photoshop, a video editor), the pixel-grounded approach wins. Pick by app, not by ideology.

It would need three readers (AXUIElement, UI Automation, AT-SPI), a unifier (probably the IAccessible2 / Core AAM mapping the W3C maintains, or a homegrown schema), and a per-OS permission flow (TCC on macOS, UIA registration on Windows, AT-SPI bus auth on Linux). The W3C Core Accessibility API Mappings spec exists precisely so the same role and property model maps across all three. Browsers already implement this internally. Whether OpenAI ships that publicly, and when, is unknown. There is no announcement as of mid-May 2026.

developers.openai.com/codex/app/computer-use is the OpenAI-published page, which contains the macOS at launch wording and the EEA / UK / Switzerland exclusion. The MacStories piece at macstories.net (April 19, 2026) confirms Mac-only at launch and describes the AX hierarchy approach. The Codex on Mac walkthroughs at findskill.ai and eesel.ai cross-check the platform constraint independently. For the three-stack cross-platform reality, xa11y.dev and the AccessKit GitHub repo are the canonical references on how the API abstractions actually work.