›_ Codex Issues
Codex Issues / #37553

Cant open windows apps from chatgpt

Open 💬 5 comments Opened Aug 8, 2026 by lukehamelsmith-hash
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.803.41515

What subscription do you have?

pLUS pLAN

What platform is your computer?

Windows 11

What issue are you seeing?

Proposed issue title

[Windows] Computer Use helper starts but cannot enumerate the active desktop from elevated sandbox

OpenAI feedback submission

  • Feedback/session ID: 019fddf4-0052-7bf3-b346-fbb8c50a29f1
  • Submitted: 8 August 2026
  • Preserve this ID when following up with OpenAI or opening a related GitHub issue.

Summary

On Codex Desktop for Windows, the bundled Computer Use runtime initializes and the OpenAI-signed native helper is present, but list_windows() fails. A direct Win32 test in the same Codex sandbox identity shows that EnumWindows is denied access and returns no windows.

This differs from reports where the plugin is missing, the Node REPL fails to start, or the native pipe is absent. Here, the runtime and helper are available; enumeration of the visible desktop is the failing boundary.

Environment

  • Windows: version 25H2, build 26200.8973, x64
  • Codex Desktop package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
  • Computer Use plugin cache: 26.803.41515
  • @oai/sky: 0.6.2
  • Computer Use runtime hash: f1bf3cd3a5929acd
  • Windows sandbox setting: elevated
  • Sandbox identity observed from the tool session: DESKTOP-IUQ9HE0\CodexSandboxOffline

Reproduction

  1. Install and enable the bundled Computer Use plugin in Codex Desktop on Windows.
  2. Start a Windows-native local task using the elevated sandbox.
  3. Initialize the bundled Computer Use runtime.
  4. Call sky.list_windows().

Actual result

Computer Use fails with:

EnumWindows failed: The system cannot find the path specified. (0x80070003)

A direct P/Invoke of user32!EnumWindows from the same task returns:

Succeeded: false
LastWin32Error: 5 (Access denied)
WindowCount: 0
VisibleWindowCount: 0
Identity: DESKTOP-IUQ9HE0\CodexSandboxOffline

Expected result

Computer Use should enumerate the active user's visible top-level windows, or report a precise actionable desktop/window-station isolation error.

Controls and negative tests

  • The native helper exists at the expected bundled runtime path.
  • Its Authenticode signature is valid and signed by OpenAI.
  • The Codex sandbox group has read/execute access to the helper.
  • Direct non-elevated child launches of cmd.exe and PowerShell succeed with UseShellExecute=false.
  • No general child-process failure remains.
  • Reset, reinstall/update checks, plugin/cache repair, ACL repair, and Chrome/Edge extension tests did not resolve the problem.
  • sandbox_private_desktop = false has now been applied while retaining sandbox = "elevated"; the result will be retested in a fresh sandbox.

Why this appears to be a sandbox/desktop bridge issue

The raw Windows API call is denied when executed as the dedicated sandbox identity and sees zero windows. The helper's higher-level error is 0x80070003, so it may be translating or surfacing the desktop bridge failure imprecisely.

Could you confirm:

  1. Whether the Computer Use helper is expected to bridge from the elevated sandbox/private desktop to the active user desktop.
  2. Whether windows.sandbox_private_desktop = false is the intended Windows compatibility setting for Computer Use.
  3. Whether Windows build 26200.8973 has a known compatibility issue with this bridge.
  4. Whether the helper can return the underlying window-station/desktop access error rather than 0x80070003.

Privacy

This report omits account names, email addresses, browser data, task content, credentials, and raw user files. It includes only product versions, Windows build information, the sandbox identity, and the minimum diagnostic results needed to reproduce the defect.

What steps can reproduce the bug?

Feedback ID: 019fddf4-0052-7bf3-b346-fbb8c50a29f1

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 20 days ago

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

  • #37436
  • #37383
  • #37306
  • #37255
  • #37043

Powered by Codex Action

lukehamelsmith-hash · 20 days ago

Retest result: confirmed workaround and narrowed cause

I enabled Settings → General → Full access, then selected Full access in the task's permissions menu. Without restarting Windows, the same bundled Computer Use runtime initialized successfully and cua.computer.list_windows() returned seven visible windows, including ChatGPT, File Explorer, Task Scheduler, Chrome, Windows Settings, and Microsoft Store.

This was a read-only test; no windows were clicked or modified.

Key comparison:

  • Ask for approval / elevated restricted sandbox: window enumeration fails with EnumWindows / access denied and returns zero windows.
  • Full access: window enumeration succeeds immediately.
  • Settings → Computer use → Any App was already enabled in both cases.

This strongly suggests the failure is coupled to the restricted Windows sandbox identity or its access to the active desktop/window station. Full access is a functional diagnostic workaround, but it is not an acceptable permanent workaround because it grants unrestricted filesystem, command, and network access.

Could you confirm whether Computer Use is expected to work in the normal Ask for approval mode, independently of the task's command/filesystem sandbox, and whether this result matches the known issue in #37436?

zjedzmojegacie · 20 days ago

Additional diagnostics: runtime/plugin version skew and sandboxed helper launch

Additional diagnostics from the same Windows Codex Desktop configuration:

  • Desktop package: OpenAI.Codex_26.803.5235.0_x64
  • Computer Use plugin/skill: 26.803.41515
  • Bundled @oai/sky: 0.6.2
  • Runtime hash: f1bf3cd3a5929acd

There appears to be runtime/plugin version skew. The installed Computer Use skill expects sky.documentation() and the desktop config enables SKY_CUA_NATIVE_PIPE=1, but bundled @oai/sky 0.6.2 does not expose documentation() and its Windows transport still uses child_process.spawn() to launch the helper.

In the normal restricted/elevated sandbox:

  1. Importing @oai/sky from the configured LocalAppData runtime fails with:

EPERM: operation not permitted, lstat 'C:\Users\<profile>\AppData\Local\OpenAI\Codex'

  1. Loading the same package from the trusted WindowsApps application resources succeeds.
  2. sky.list_apps() and sky.list_windows() then fail with:

spawn EPERM

Full application restarts, Windows 8.3 short paths, alternate module roots, and a project-local mcp_servers.node_repl.args = ["--disable-sandbox"] override did not resolve the issue. The project override appears to be superseded by the desktop-generated MCP configuration.

This suggests two related defects:

  • the Computer Use skill/plugin and bundled @oai/sky runtime are not version-aligned;
  • the bundled Windows runtime depends on a helper-spawn path that is blocked by the default Codex Desktop sandbox.

Expected behavior: bundled plugin/runtime versions should be aligned, and Computer Use should work in normal “Ask for approval” mode through the native transport without requiring Full Access.

SpoofingMyName · 19 days ago

Same issue, feedback Id - 019fe2c0-f468-73b3-b3bf-bccf44f2d8af

Doesn't work even with full access enabled

SpoofingMyName · 17 days ago

Fixed as of 2026-08-11.