Codex can now control Windows apps as coding agents move onto the PC
OpenAI Codex added Windows Computer Use and remote control from mobile. The update expands coding agents from shells and repos into desktop apps.
- What happened: OpenAI added Windows
Computer Useand Windows remote control inCodex 26.527.- In the May 29, 2026 changelog, Codex can see, click, and type in foreground Windows desktop apps.
- Developer impact: The coding-agent surface now extends beyond repositories, shells, browser previews, and IDEs into local desktop tools and remote PCs.
- Watch: Terminal apps, Codex itself, administrator authentication, and OS security or privacy prompts remain outside the automation boundary.
- App approvals and remote-connection exposure become operational controls, not just setup details.
OpenAI posted a Codex changelog entry on May 29, 2026 titled Computer use and mobile access on Windows 26.527. The release has two concrete additions. First, Computer Use now works on Windows, allowing Codex to see, click, and type in foreground Windows desktop apps. Second, Remote control now supports Windows devices, so a user can start and monitor Codex work on a Windows machine from ChatGPT on iOS or Android, or from Codex on a Mac.
That can read like another platform-support note. For developers, the sharper change is what Codex is allowed to operate. Until now, the central Codex surface was the repository, shell, diff, pull request, and browser preview. Windows Computer Use brings tools without clean APIs into the possible task path: Visual Studio, database clients, design tools, local admin consoles, enterprise desktop apps, installers, and internal utilities. The product question is no longer only whether a model can write a correct patch. It is whether the agent can finish the parts of development that still happen through a GUI.
The important word in OpenAI's documentation is foreground. For Codex to operate a Windows app, that app has to be visible in front of the user, and the clicks or keystrokes happen inside an app the user has approved. This is a different execution model from a background API call. An agent that opens a pull request through the GitHub API mostly needs token scope and request logging. An agent that operates a desktop app inherits cursor position, focus state, modal dialogs, system permission prompts, clipboard contents, unsaved files, and the exact screen the user can see.
The same changelog entry also mentions profile details, usage stats, token activity, thread coordination for local projects and worktrees, separate background threads when requested, and broader thread search across conversation content and Git branch names. Those items look smaller than Windows Computer Use, but they point in the same direction. If a coding agent can run for hours, move across worktrees, and wait for user approvals, the product has to expose usage, thread history, and coordination state. A long-running worker needs auditability, not only better completions.
Why Windows support is the news
Codex already had a Windows story. OpenAI described its Windows sandbox design on May 13, 2026, and devlery covered that boundary separately. That earlier architecture centered on a separate local user, firewall rules, restricted tokens, ACLs, and a command runner. The May 29 update asks a different question. Instead of only asking whether an agent can run shell commands safely on Windows, it asks whether the agent can complete work by manipulating the desktop tools that Windows developers actually use.
The distinction matters in daily engineering work. Many Windows development environments still depend on Visual Studio solution settings, authenticated internal tools, local emulators, database GUIs, installer flows, corporate VPN clients, and legacy admin consoles. Some of those tools do not expose an API that fits a coding agent. Others can be automated only through brittle scripts. When the model generates useful code but the final step still requires a person to click through a local tool, the workflow remains blocked on human desktop labor.
Computer Use is OpenAI's attempt to include that manual region in the agent loop. It does not mean "grant the model more power and hope for the best." OpenAI's Computer Use documentation separates system permissions from app approval. In the macOS example, Screen Recording and Accessibility are operating-system permissions, while Codex app approval controls which apps Codex may operate. The same principle applies to Windows deployments even if the exact OS permission prompts differ: what the operating system allows and what the user approves for a particular agent task are separate trust decisions.
| Execution surface | May 29 change | Operational boundary |
|---|---|---|
| Windows desktop app | See, click, and type in the foreground | Per-app approval, screen focus, saved state |
| ChatGPT mobile | Start and monitor work on a Windows device | Same account and workspace, remote control enabled |
| SSH remote project | Start a remote Codex app server over SSH | No direct public exposure; use VPN or mesh networking |
| Shell and file edits | Existing sandbox and approval settings continue | No terminal automation; keep approval logs distinct |
"Only approved apps" is a product boundary
The most practical sentence in the Computer Use documentation is that Codex can see and act only in apps the user allows. During a task, Codex can request permission to use a specific app, and the user can choose an "Always allow" option. That saves time, but it also creates a durable permission inventory. If the approved app is a database client or a cloud console, future tasks can bring Codex back into that same app boundary.
OpenAI also states what Computer Use cannot automate. It cannot operate terminal apps or Codex itself. Automating a terminal would let Codex work around the shell approval and sandbox policy that the product uses to control command execution. Automating Codex would create the same kind of self-control problem. Codex also cannot approve administrator authentication or operating-system security and privacy permission prompts. Those exclusions are not missing features. They are the line that keeps the agent from clicking through the approval system that governs it.
Teams adopting this feature should turn those limits into an operating checklist. First, decide which applications Codex is allowed to use. Second, decide who can grant "Always allow" for sensitive apps. Third, confirm when a change made through a desktop app becomes visible in the review pane. OpenAI notes that changes made through desktop apps might not appear in review until they are saved and tracked in the project. If a GUI changes a settings file or runs a local database migration, reviewing the Git diff alone may not describe the full side effect.
Mobile remote control changes the approval rhythm
OpenAI describes Remote Connections as a way to use Codex from another device or another machine. A user can work with Codex on a connected Mac or Windows device from ChatGPT mobile, continue work from another supported Codex App device, or connect an SSH host project. The new part in the May 29 changelog is that Windows devices are now part of that remote-control target set. Windows PCs can participate in the same asynchronous workflow that Codex has been building around mobile approvals and remote sessions.
The bottleneck in agentic coding is often not that the model cannot propose a next step. It is that the human has to approve a direction in the middle of the run. A test fails and the agent needs to choose a repair path. A destructive command needs confirmation. A browser or desktop action needs user approval. A remote host connection needs a decision. Mobile remote control moves those approval points from the desk to the phone. That is useful, but it also makes accidental approval cheaper. A faster approval path is also a sharper audit requirement.
Remote connections add a network boundary. OpenAI's documentation says the remote Codex app server is started and managed over SSH, and warns users not to expose the app-server transport directly on shared or public networks. If external access is needed, the documentation recommends a VPN or mesh networking tool. That warning is not theoretical conservatism. A Codex app server is connected to project files, command execution, and thread state. Exposing it publicly would expose part of the developer machine's agent control plane.
The competition is moving from model output to control surface
GitHub Copilot, Cursor, Claude Code, and JetBrains' agent tools have all moved from "generate code" toward "take a task." The important product differences now show up in execution surfaces. GitHub Copilot's cloud agent is attached to issues, pull requests, and GitHub workflows. Cursor Cloud Agents bring repository work and development environments into Cursor's loop. Claude Code emphasizes terminal-centric development, MCP, and enterprise connectors. Codex is adding app, mobile, browser, Chrome extension, Computer Use, and remote connections that bring the agent closer to the user's actual device.
Windows Computer Use is especially relevant inside enterprise development environments. Many organizations still run Windows laptops with MDM, EDR, VPN clients, internal authentication, Visual Studio, SQL Server tooling, and legacy administration apps. A cloud sandbox alone does not cover that environment. Opening the local PC without clear limits will not satisfy security teams. OpenAI's boundaries around terminal automation, administrator prompts, app approval, and remote-server exposure are a response to that tension.
Product and platform teams can frame the decision around three questions. Which jobs genuinely require GUI manipulation, and which should stay in CLI or API paths? Can the "Always allow" list be managed as a team policy rather than as a personal convenience setting? Can mobile approvals, local diffs, remote-host runs, and desktop-app side effects be assembled into one audit trail? Without those answers, Computer Use becomes another powerful local automation feature with ambiguous ownership.
Open source maintainers get the same tradeoff
OpenAI also runs a Codex for Open Source program that offers open-source maintainers API credits, six months of ChatGPT Pro with Codex, and conditional access to Codex Security. The program is separate from the May 29 changelog, but it belongs in the same conversation. Maintainer work often combines pull-request review, issue triage, release workflow, local reproduction, and GUI validation. More execution surface can help, but it also puts the agent closer to local credentials and release machinery.
For maintainers, Windows Computer Use cuts both ways. It can help reproduce Windows-only bugs, installer issues, and GUI-tool behavior that a cloud Linux environment cannot reach. It also means the agent may operate near a maintainer's browser session, package-manager credentials, signing tools, or local configuration. Even if terminal automation is blocked, desktop apps can still save files, change settings, and trigger real side effects. A project should define what Codex is allowed to do before asking what Codex can do.
Reading this update as "Codex now supports Windows better" misses the larger product movement. Coding agents are becoming workers that move between the repository, local screen, remote device, approval button, browser, and GUI app. Model quality still matters, but product trust increasingly depends on separate controls: which apps the agent may see, which apps it may never operate, which approvals must remain human, and how remote servers are exposed.
Windows Computer Use and mobile remote control expand Codex's feature list. They also describe where AI coding tools are heading. The next competitive question is not only who writes the better patch. It is how far an agent can reach into the developer's real PC, and who can stop that reach at the right time.