Feature request: Full Computer Use support for Codex Desktop on Windows

Open 💬 17 comments Opened Apr 24, 2026 by htazq

What variant of Codex are you using?

Codex Desktop App on Windows, with WSL2 / PowerShell workflows. Browser Use is available, but full native Windows desktop Computer Use is not available.

What feature would you like to see?

I would like Codex Desktop on Windows to support full native Computer Use, similar to the macOS Computer Use workflow.

Today, Codex Desktop on Windows is already useful for projects, Git, Browser Use, terminal workflows, PowerShell, and WSL2. However, Browser Use only controls the in-app browser. It does not allow Codex to inspect or operate the actual Windows desktop, native Windows applications, settings dialogs, GUI tools, installers, IDE windows, or other non-browser workflows.

For many developers, Windows is the primary workstation. In my case, I use Windows for daily work and WSL2 for Linux development. I also work with remote Linux systems, terminal tools, Git workflows, browser dashboards, and desktop applications. The current Windows Codex App is helpful, but the missing full Computer Use support means I would need to buy and maintain a separate Mac only to access this workflow.

I actually tried using a Mac mini for this purpose, but the platform switch was uncomfortable for my existing workflow: keyboard behavior, mouse behavior, copy/paste habits, window management, monitor setup, and general daily usage were all friction points. I would strongly prefer to keep using my Windows workstation and let Codex operate there directly.

The feature I am requesting is official full Computer Use support for Codex Desktop on Windows, including:

  • Screen inspection / screenshot understanding
  • Mouse movement, clicking, double-clicking, dragging, scrolling
  • Keyboard input and hotkeys
  • Clipboard-aware workflows
  • Operation of native Windows desktop applications
  • Operation across normal developer tools such as VS Code, Cursor, terminals, browsers, file explorer, installers, configuration panels, and GUI-only tools
  • Compatibility with Windows + WSL2 development workflows
  • Clear user permission prompts and approval gates for sensitive actions

Why this matters:

Windows is a first-class development platform for many users. A large number of engineers use Windows together with WSL2, VS Code / Cursor, browsers, local GUI tools, remote Linux servers, and internal enterprise applications. Browser Use is valuable, but it only solves browser-contained workflows. It does not solve real desktop automation.

Without Windows Computer Use, Windows-first users need to buy or maintain a Mac only for this one capability. That is a significant barrier, especially when their main work environment, files, terminals, VPNs, enterprise tools, and developer setup already live on Windows.

Expected behavior:

Codex Desktop on Windows should expose a full Computer Use capability, ideally similar to the macOS implementation. Users should be able to explicitly enable it, grant the required permissions, and then let Codex inspect and operate the Windows desktop under user supervision.

Safety expectations:

I would be completely fine with this being opt-in and permission-gated. For example:

  • Per-session approval before enabling screen control
  • Visible indication when Codex is observing or controlling the desktop
  • Confirmation before destructive, financial, security-sensitive, or credential-related actions
  • Ability to pause or revoke control immediately
  • Activity logs for actions performed by Codex

This would make Codex much more useful for Windows-first developers and engineering users. It would also remove the need to switch to macOS only to use Computer Use.

Additional information

Windows is my primary workstation, and I believe this is true for many developers.

Codex on Windows already feels close to being a complete engineering assistant: it can work with projects, Git, terminals, WSL2, browser workflows, and development files. The missing piece is the ability to operate the real Windows desktop environment.

Full Windows Computer Use would make Codex useful for end-to-end workflows that combine code and GUI operations, such as testing desktop apps, configuring tools, operating dashboards, reproducing UI bugs, using Windows-only software, and coordinating browser + terminal + desktop workflows.

This is not just a convenience feature. It determines whether Windows users can use Codex as their main AI agent on their main machine, or whether they need to buy and maintain a separate Mac only to access Computer Use.

I personally tried using a Mac mini for this workflow, but switching platforms introduced too much friction for my daily setup: keyboard behavior, mouse behavior, copy/paste habits, window management, monitor setup, and general usage habits. I would strongly prefer to use Codex Computer Use on my existing Windows workstation.

View original on GitHub ↗

16 Comments

johanThiborgEricson · 2 months ago

1+ for testing end-to-end testing Windows only desktop apps. The Codex App with Computer Use could speculate on regression bugs based on git history or manuals as compared to source code, try to reproduce those bugs, and report findings in one continuous loop. This would remove the bottleneck of Codex having to explain with text to the tester the potential regression bugs and how to reproduce them, and the tester instead takes the role of a guardrail.

Madex1987 · 2 months ago

+1 Computer use is very important for the Codex App to be the super App good also for every day business / knowledge work

emiliauh · 2 months ago

+1, would be great especially across multi-platform development.

eliowang6 · 2 months ago

+1

m13v · 2 months ago

this is the same pattern every time someone tries to ship cross-OS Computer Use. screenshot+vision works everywhere but latency and token bill kill real workflows, you can't loop on it for actual desktop automation. accessibility-tree control is fast but per-OS glue cost is the killer. Windows UIA quality is wildly inconsistent across Win32, WPF, WinUI, Electron, MFC, half the enterprise apps you'd actually want to drive expose almost nothing usable in the tree. macOS AX is more uniform across cocoa and catalyst, which is why agents land there first. it's not a priority slight against windows users, the per-app integration cost on windows is several multiples higher and that math doesn't change just because the user demand is real.

AbdulWaheedorg · 2 months ago

+1

nybotic · 2 months ago

+1

sal562 · 2 months ago

+1 got used to constantly using on Mac and now feel incredibly limited using codex on windows boxes.

Activeman2 · 2 months ago

+100 we need Codex computer use for Windows ASAP.

homearanya · 2 months ago

+1

jiangjinmingwu · 2 months ago

+1

shaike1 · 2 months ago

+1

spboxer3 · 1 month ago

+1

ianbotts · 1 month ago

I am seeing the same Windows gap.

Environment:

  • Windows 11, United States
  • ChatGPT Pro account ($100/month)
  • Codex Desktop app: running app product version 26.519.41501, file version 3044
  • Windows AppX package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
  • Embedded Codex CLI observed from running processes: 0.133.0-alpha.1
  • Settings > Computer use shows Google Chrome enabled and connected
  • "Any App" is disabled with "Disabled by your organization or unavailable in your region"

Local evidence:

  • openai-bundled plugin cache includes browser and chrome
  • openai-bundled plugin cache does not include computer-use
  • generated bundled marketplace includes browser/chrome/latex, but not computer-use

This does not look like a Pro subscription issue or a US region issue, because Chrome control is connected. It looks like full native Windows "Any App" Computer Use is not yet available or is separately gated from Chrome.

thyagarajanqc · 1 month ago

+100 this is absolutely mandatory for Windows.

chrisyang96 · 1 month ago

Could someone please help me? My Codex is missing the "Computer Use" feature. I checked the plugins section, but it wasn't there either. I'm running Windows 10.

Showing cached comments. Read the full discussion on GitHub ↗