Windows Computer Use fails at EnumWindows with 0x80070003

Summary

The bundled Computer Use helper starts, but both sky.list_apps() and
sky.list_windows() fail immediately with:

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

The failure survives a full Windows restart and a Codex restart.

Environment

Windows 10 Home 22H2, build 19045.6466
Codex Windows package: OpenAI.Codex_26.730.8199.0_x64
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Computer Use runtime: cua_node/fb8898c05a62885e
WebView2 Runtime: 151.0.4129.59

Verified behavior

node_repl.exe starts and imports @oai/sky successfully.
codex-computer-use.exe exists and starts.
sky.list_apps() fails with the error above.
sky.list_windows() fails with the same error.
A direct Win32 EnumWindows diagnostic outside the helper returns normally.
The Windows desktop was unlocked and active.

Process context

node_repl.exe runs as the signed-in Windows user.
codex-computer-use.exe runs as CodexSandboxOffline in the same Windows session.

The isolated account's Desktop and Pictures values referenced local paths that
did not exist. Empty compatibility folders were created at those exact paths,
Codex was fully restarted, and the same EnumWindows error remained. The missing
folders were therefore ruled out as the cause.

Troubleshooting already completed

Uninstalled and reinstalled the Codex desktop app.
Restarted Windows multiple times.
Verified the helper executable, Node runtime, and package files exist.
Verified the signed-in user's OneDrive Desktop and Pictures paths exist.
Created the isolated account's missing local Desktop and Pictures paths.
Confirmed both lightweight enumeration APIs still fail after restart.

Expected behavior

sky.list_apps() and sky.list_windows() should return app/window objects so
Computer Use can target Windows applications.

Actual behavior

The native helper connects but aborts its first window enumeration with Windows
error 0x80070003, so no desktop application can be targeted or controlled.

I can reproduce the same regression on the same current package/plugin family, but my helper returns Win32 error 2 rather than error 3:

EnumWindows failed: The system cannot find the file specified. (0x80070002)

Environment

Windows x64, build 26200.8875
Codex Windows package: OpenAI.Codex_26.730.8199.0_x64
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Computer Use runtime: cua_node/fb8898c05a62885e
Helper SHA-256: 627B317CCFD3C7386A2D5BC4FB4E97FF30E30425945A7A5370006AD89CF3605A

Update/failure timeline (UTC)

Last successful sky.list_windows(): 2026-08-04 23:59:52Z
Store update completed: 2026-08-05 04:05Z
- package 26.727.6591.0 → 26.730.8199.0
- app-server 0.146.0-alpha.9.2 → 0.147.0-alpha.1.2
- Computer Use plugin 26.727.51351 → 26.730.61639
First observed failure: 2026-08-05 05:53:02Z

The AppX update completed successfully with no deployment warnings or errors.

Narrowing completed

Disabling/re-enabling Computer Use, restarting Codex, and restarting Windows did not change the result.
The Computer Use native pipe reports startup ready.
The helper executable exists, starts, and its diagnostic-state request succeeds; only window enumeration fails.
The working and broken app versions used the same cua_node runtime, @oai/sky version, and helper binary/hash.
A direct read-only Win32 EnumWindows probe outside the Codex sandbox succeeds (319 top-level handles enumerated), so the host Windows API and active desktop are functioning.
The current helper execution context uses the CodexSandboxOffline token. Its inherited environment/profile references and its token-resolved profile do not agree, which may be relevant to a per-window executable/icon/profile lookup performed during the enumeration callback.

This looks like a 26.730 app-server/sandbox/window-enumeration integration regression rather than a missing helper binary. The 0x80070002 versus this issue's 0x80070003 may reflect different missing filesystem objects reached by the same enumeration callback path.

I can reproduce this on a Windows ARM64 Qualcomm PC.

Codex package: OpenAI.Codex_26.730.8199.0_arm64
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Runtime: cua_node/f1359d6e9a17bb1d
Error: EnumWindows failed: The system cannot find the path specified. (0x80070003)

The elevated sandbox and runtime permissions were repaired and verified. Both bundled x64 and ARM64 helpers produced the same error after full Windows and Codex restarts; the official x64 helper was restored. This confirms the regression also affects ARM64 and does not appear to be caused by helper architecture.

I am encountering a closely related failure with the same Computer Use plugin version, 26.730.61639, on Windows 11 x64.

Both sky.list_apps() and sky.list_windows() fail, but my error is slightly different:

EnumWindows failed: The system cannot find the file specified. (0x80070002)

I also found an apparent mismatch between the bundled Computer Use skill and @oai/sky. The module loads and exposes sky, but the documentation API required by the skill is absent:

TypeError: sky.documentation is not a function

The failure persisted after restarting Windows and the desktop app, reinstalling the plugin, starting a new task, and resetting the JavaScript runtime.

In-app diagnostic feedback ID: 019fd4c4-f84e-7fc0-a66d-a4ba7255bff7

The matching plugin version and failing enumeration calls suggest this may share the same underlying Windows helper/runtime problem, despite the difference between 0x80070002 and 0x80070003.

I can reproduce the same failure on a separate Windows 11 environment.

Environment

Windows 11 Pro x64, version 10.0.26200 (build 26200)
Codex Windows package: OpenAI.Codex_26.730.8199.0_x64
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Computer Use runtime: cua_node/fb8898c05a62885e
Target application: Power Automate Desktop, visible on the active unlocked desktop
Any app access enabled in Settings > Computer use

Observed behavior

@oai/sky imports successfully, but sky.list_apps() fails before any target application can be selected:

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

The bundled codex-computer-use.exe exists at the expected package path.

Additional troubleshooting completed

Fully quit and restarted Codex.
Toggled Any app access off and back on.
Reinstalled Codex in place from the current official, validly signed x64 MSIX.
Confirmed the reinstalled AppX package reports status Ok.
Moved the entire cua_node/fb8898c05a62885e runtime aside and restarted Codex, allowing the runtime to be downloaded and regenerated from scratch.
Confirmed the regenerated runtime manifest, node_repl.exe, Node runtime, @oai/sky, and codex-computer-use.exe all exist.
The same EnumWindows error persisted after regeneration.
An earlier sandbox traversal failure on the Codex parent directory was corrected with minimal read/execute access for CodexSandboxUsers; after that, @oai/sky loaded, but enumeration still failed with 0x80070003.

No application window can be enumerated or controlled, and Power Automate Desktop is never touched. This appears to be within the Windows Computer Use helper/enumeration layer rather than the target application.

I can reproduce this on Windows 11 Pro x64 with the same Codex package.

Environment

Windows 11 Pro 25H2 x64
Windows build: 10.0.26200.8875
Codex Windows package: OpenAI.Codex_26.730.8199.0_x64
Workspace Dependencies bundle: 26.805.11740

Observed behavior

In a fresh task, I asked Computer Use only to list the titles of the currently visible top-level Windows applications, without clicking, typing, launching, closing, or modifying anything.

It failed immediately with:

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

The failure occurs before Chrome or any other target application can be selected or approved.

Troubleshooting completed

Fully restarted Windows.
Fully restarted Codex.
Started a new, minimal task specifically for window enumeration.
Disconnected all external USB devices.
Completely exited PowerToys.
Confirmed the Windows desktop was active and unlocked.
Reinstalled the Workspace Dependencies bundle.
Ran the Workspace Dependencies diagnostic, which reports that the dependencies are healthy.

The reinstall changed the Workspace Dependencies version, but the EnumWindows failure remained identical.

Impact

I was using Computer Use to drive and visually validate development of a Chrome extension. Since Codex can no longer enumerate or inspect any Windows application, the automated UI-testing and acceptance-testing portion of that workflow is completely blocked.

This appears to be the same Windows Computer Use helper/enumeration regression reported here rather than a Chrome approval, peripheral, PowerToys, or Workspace Dependencies issue.

I can reproduce this on a Windows 11 Arm64 environment, with the same Computer Use plugin/runtime family.

Environment

Windows version: 10.0.26200.8973
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
Computer Use runtime: cua_node/f1359d6e9a17bb1d
Helper SHA-256: 627B317CCFD3C7386A2D5BC4FB4E97FF30E30425945A7A5370006AD89CF3605A

Observed behavior

Both sky.list_windows() and sky.list_apps() fail before any target app can be selected:

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

The same failure persisted after resetting the JavaScript runtime and retrying the lightweight enumeration calls.

Additional narrowing

I also called the bundled helper directly over its JSON-line protocol. The helper executable starts and diagnostic_state succeeds, so this does not look like a missing helper binary or a Node import problem.

Direct helper behavior differed depending on request metadata:

list_windows with no Codex turn metadata: ok=true, result=[]
list_windows with turn_id only: EnumWindows failed: The operation completed successfully. (0x00000000)
list_windows with session_id + turn_id: EnumWindows failed: The system cannot find the path specified. (0x80070003)

Arbitrary fake session_id + turn_id values reproduced the same 0x80070003, so the exact IDs do not appear to matter; the metadata shape does.

This suggests the native helper may be taking a turn-scoped path when turn_id/session_id metadata is present, and then reporting a stale or unrelated GetLastError() value as an EnumWindows failure after enumeration aborts. The 0x00000000 case especially looks like EnumWindows returned FALSE without a meaningful Win32 error being set.

A related Windows observation from another task: the helper was installed and enabled, but trying to open NetEase Cloud Music failed before any app could be targeted. The observed error was spawn EPERM rather than 0x80070003, and restarting/resetting did not restore sky.list_apps() or sky.list_windows(). This may be a separate earlier failure stage in the same native Computer Use helper path. Environment: Codex Desktop 26.730.8199.0, Computer Use plugin 26.730.61639, @oai/sky 0.6.2, Windows x64.

Verified root cause and working fix/workaround

Short version: codex-computer-use.exe was healthy, but it inherited an empty private Windows desktop named Winsta0\CodexSandboxDesktop-.... EnumWindows therefore found zero top-level windows. The documented compatibility setting below makes sandboxed children use the interactive Winsta0\Default desktop instead:

[windows]
sandbox = "elevated"
sandbox_private_desktop = false

After changing %USERPROFILE%\.codex\config.toml, fully exit every Codex/ChatGPT process and relaunch Codex. A normal task restart is not sufficient because the sandbox desktop and native pipe are created by the desktop-app process.

This fixed Computer Use on the affected machine. After restart, sky.list_windows() returned real Chrome, Steam, and Codex windows, and Computer Use worked normally.

This option is documented in the current Windows sandbox guide as the compatibility switch for the older Winsta0\Default behavior. It preserves the elevated filesystem/network sandbox, but it intentionally gives up the stronger private-desktop UI isolation. Treat it as a compatibility workaround until the product correctly routes Computer Use to the active input desktop while private-desktop isolation is enabled.

Root cause

The reported HRESULT is misleading. The failure was not a missing file/path, plugin binary, marketplace, native pipe, target app, or broken Windows EnumWindows API.

The actual sequence was:

Codex launched node_repl.exe and then codex-computer-use.exe on a private desktop: Winsta0\CodexSandboxDesktop-<id>.
That desktop contained no user application windows.
The helper's list_windows path called EnumWindows directly on its current thread desktop. It did not call OpenInputDesktop or SetThreadDesktop first.
Inside user32!EnumWindows, win32u!NtUserBuildHwndList returned STATUS_SUCCESS, but the returned list had needed = 1, meaning only the terminating null entry and therefore zero enumerated windows.
This Windows build returns FALSE from EnumWindows for that empty-list case without setting a new Win32 error.
The helper converted the thread's stale GetLastError() value into an HRESULT. On this machine it happened to be Win32 error 3 (0x80070003); other reports showing error 2 or even error 0 are consistent with the same stale-error behavior.

So the useful diagnostic signature is not the exact 0x80070002/0x80070003 suffix. It is: helper is alive + native transport works + EnumWindows returns false + helper is attached to an empty CodexSandboxDesktop.

How this was debugged

Environment reproduced here:

Codex Windows package: OpenAI.Codex_26.730.8199.0_x64
Computer Use plugin: 26.730.61639
@oai/sky: 0.6.2
helper SHA-256: 627B317CCFD3C7386A2D5BC4FB4E97FF30E30425945A7A5370006AD89CF3605A
helper: ...\@oai\sky\bin\windows\codex-computer-use.exe

1. Separate bootstrap failures from enumeration failures

First verify that:

the Computer Use plugin is installed/enabled;
@oai/sky imports;
codex-computer-use.exe starts;
SKY_CUA_NATIVE_PIPE_DIRECTORY exists and the named pipe is present;
sky.list_windows() reaches the helper and returns the EnumWindows failed message.

If those are true, marketplace junctions and the native pipe are no longer the failing layer. Reinstalling the plugin/runtime does not address this desktop-selection failure.

2. Attach CDB to the live helper

Microsoft CDB was available at:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe

Find the helper PID:

Get-Process -Name codex-computer-use | Select-Object Id, Path, SessionId

A first breakpoint around EnumWindows captured the return value, stack, and last-error state:

.symfix
.reload
bp user32!EnumWindows ".printf \"ENUM_ENTRY callback=%p lparam=%p\\n\", @rcx, @rdx; kb; gu; .printf \"ENUM_RETURN rax=%p\\n\", @rax; !gle; qd"
g

Observed:

ENUM_RETURN rax=0000000000000000
LastErrorValue: 0x3 ERROR_PATH_NOT_FOUND
LastStatusValue: 0xc000003a STATUS_OBJECT_PATH_NOT_FOUND

The helper call stack led to codex_computer_use+0x1eed1, with the list_windows caller near +0xad6d9 in this exact binary.

3. Disassemble `user32!EnumWindows` and inspect the returned HWND-list count

The system implementation can be inspected without a live target:

& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe' `
  -z 'C:\Windows\System32\user32.dll' `
  -c '.symfix;.reload /f user32.dll;uf user32!EnumWindows;q'

On this Windows build, a breakpoint immediately after NtUserBuildHwndList showed:

status   = 00000000   # STATUS_SUCCESS
capacity = 40
needed   = 1

The relevant CDB tracepoint was:

bp user32!EnumWindows+0x64 ".printf \"status=%08x capacity=%x needed=%x\\n\", @eax, poi(@rsi), poi(@rsi+4); dq @rsi L8; g"

user32 offsets are Windows-build-specific; run uf user32!EnumWindows first and place the breakpoint after the NtUserBuildHwndList call on the machine being diagnosed.

This proved that the syscall succeeded and returned an empty desktop window list. The stale LastError was unrelated to that successful syscall.

4. Rule out the helper callback

LLVM's PE tools were sufficient; Ghidra was not required:

llvm-readobj.exe --coff-imports codex-computer-use.exe
llvm-objdump.exe -d --x86-asm-syntax=intel codex-computer-use.exe

For helper SHA-256 627B...605A, the EnumWindows callback was near RVA 0xBDB32. Static disassembly showed every normal exit converging on:

push 1
pop  rax
ret

In other words, the callback returns TRUE; it was not aborting enumeration because of a failed executable/icon/profile lookup.

Breakpoints on this helper's OpenInputDesktop, SetThreadDesktop, GetThreadDesktop, and CloseDesktop call sites showed that none of them ran before list_windows called EnumWindows. This is important because SetThreadDesktop is thread-specific.

5. Read the helper's inherited desktop from the PEB

With CDB attached:

.symfix
.reload /f ntdll.dll
dt ntdll!_RTL_USER_PROCESS_PARAMETERS poi(@$peb+0x20) DesktopInfo

Observed:

DesktopInfo : _UNICODE_STRING "Winsta0\CodexSandboxDesktop-44beec266b651ad5ec23705884b0804a"

A direct PowerShell/Win32 probe running under the same Codex sandbox also reported a CodexSandboxDesktop-* name and EnumWindows = FALSE, count 0.

6. Compare with the real input desktop

On a fresh diagnostic thread, the following sequence succeeded:

OpenInputDesktop(...)
SetThreadDesktop(inputDesktop)
GetUserObjectInformationW(..., UOI_NAME, ...) returned Default
EnumWindows(...) returned TRUE and enumerated 295 handles

As a final controlled proof, the unchanged signed helper was launched with STARTUPINFO.lpDesktop = "Winsta0\\Default" while keeping the same stdio protocol and arguments. It immediately returned three real target windows. No helper binary patch was required.

7. Apply the supported compatibility setting and restart

Back up %USERPROFILE%\.codex\config.toml, add:

[windows]
sandbox_private_desktop = false

If [windows] already contains sandbox = "elevated", add the new key to that existing table; do not create a duplicate TOML table.

Then fully terminate all ChatGPT.exe/Codex processes and relaunch the AppX app. Verify that:

the Computer Use named pipe is newly created;
the bundled plugin remains installed/enabled;
sky.list_windows() returns actual windows;
Computer Use can inspect a permitted app.

Reusable prompt for future incidents

Investigate Codex Windows Computer Use failing with:
"EnumWindows failed: The system cannot find the file/path specified"
(0x80070002, 0x80070003, or 0x00000000).

First separate plugin/native-pipe bootstrap from native window enumeration. If
@oai/sky imports, codex-computer-use.exe is alive, the pipe exists, and
sky.list_windows() reaches the helper, inspect the helper's Windows desktop.

Use CDB to:
1. attach to codex-computer-use.exe;
2. break on user32!EnumWindows and inspect its return;
3. disassemble user32!EnumWindows, break after NtUserBuildHwndList, and inspect
   the HWND capacity/needed fields;
4. read PEB ProcessParameters.DesktopInfo;
5. trace OpenInputDesktop/SetThreadDesktop before EnumWindows.

If DesktopInfo is Winsta0\CodexSandboxDesktop-* and NtUserBuildHwndList succeeds
with needed=1 (zero windows), back up config.toml, set this in the existing
[windows] table:

sandbox_private_desktop = false

Fully exit all Codex/ChatGPT processes and relaunch Codex so the desktop and
named pipe are recreated. Verify sky.list_windows() returns real windows.
Do not patch/reinstall the helper first; 0x80070002/3 may be a stale GetLastError.
Also report the UI-isolation tradeoff of using Winsta0\Default.

Useful search keywords:

CodexSandboxDesktop
windows.sandbox_private_desktop
Winsta0\Default
codex-computer-use.exe EnumWindows
@oai/sky list_windows
NtUserBuildHwndList needed=1
EnumWindows stale GetLastError 0x80070003 0x80070002
OpenInputDesktop SetThreadDesktop

The product-side fix should ideally keep private-desktop isolation for ordinary sandboxed commands while dispatching Computer Use enumeration/capture/input onto the active input desktop (or explicitly switching the dedicated Computer Use thread before enumeration), and it should not convert an unset/stale GetLastError() into a misleading path/file HRESULT.

Follow-up: the window-enumeration workaround fixed only the first half of Windows Computer Use. Screenshot capture and mouse input required resolving a second sandbox-identity problem.

Short version

This combination restored end-to-end window discovery, screenshots, and coordinate mouse input on the affected build:

[windows]
sandbox = "unelevated"
sandbox_private_desktop = false

After changing the existing [windows] table, fully exit every Codex/ChatGPT process and relaunch the desktop app. A task restart alone is not sufficient.

On this build, the task also had to use task-scoped Full Access. Keep reading before using that workaround because it has significant security implications.

Second root cause: Windows Graphics Capture ran under the wrong user context

With sandbox = "elevated" and sandbox_private_desktop = false:

sky.list_windows() worked and returned real windows.
sky.get_window_state({ include_screenshot: true }) reached Windows Graphics Capture.
IGraphicsCaptureItemInterop::CreateForMonitor failed with:

The specified service does not exist as an installed service. (0x80070424)

The same error occurred against unrelated desktop windows, ruling out the target application and graphics injector/overlay.

The OneCore per-user capture-service template and signed system DLL were present and correctly registered. Its user-specific service instance was manual/demand-start and stopped, which is normal. The actual mismatch was that the elevated Codex sandbox used a dedicated offline sandbox identity, while Windows creates the per-user capture-service instance for the signed-in interactive user.

A minimal read-only A/B probe of the exact API confirmed this:

dedicated elevated-sandbox identity: CreateForMonitor -> 0x80070424
restricted token derived from the signed-in user: CreateForMonitor -> SUCCESS

Therefore, deleting/recreating the capture-service registry keys was neither necessary nor the correct first fix. Switching to windows.sandbox = "unelevated" put capture back in the interactive user's context.

Third blocker: nested helper launch under the unelevated sandbox

After switching to unelevated, the bundled @oai/sky Windows client could no longer start its helper while the task used the normal workspace sandbox:

spawn EPERM

The bundled @oai/sky version launches the Windows Computer Use helper as a child process. A separate benign child-process probe reproduced the same EPERM inside the unelevated sandbox, so this was not an application allowlist or capture-service failure.

Selecting Full Access for the individual task removed that nested-process restriction. End-to-end verification then succeeded:

sky.list_windows() returned the permitted window.
sky.get_window_state() returned a correctly rendered screenshot.
A coordinate click in a known non-interactive background area completed.
A second screenshot succeeded and confirmed that the application UI remained unchanged.

If node_repl exec context not found appears during an app-approval callback, reset the Node kernel, then import @oai/sky, reacquire the window, capture, and perform the action in the same live JavaScript call.

Security implications

This workaround deliberately weakens three isolation layers:

sandbox_private_desktop = false places sandboxed UI work on Winsta0\Default, so it gives up private-desktop UI isolation.
sandbox = "unelevated" uses a restricted token derived from the signed-in user instead of the stronger dedicated offline sandbox account. It is the documented compatibility/fallback mode and provides weaker isolation than the elevated implementation.
Full Access disables the task's normal filesystem sandbox and enables broad local command access. This is the largest risk.

Recommended precautions:

Use Full Access only for the specific trusted task that needs Computer Use.
Do not make sandbox_mode = "danger-full-access" a global default.
Keep the Computer Use application allowlist narrow.
Return the task to Workspace access immediately afterward.
Do not enter secrets or leave unrelated sensitive applications visible while UI control is active.

Suggested product-side fix

Ideally, Windows Computer Use should enumerate, capture, and inject input through a desktop-owned broker/native pipe running in the interactive user's context, while ordinary commands remain inside the elevated filesystem/network sandbox. The runtime should not require an extra helper child that the unelevated sandbox rejects. That would preserve strong command isolation without losing access to the active desktop or the signed-in user's per-user Windows Graphics Capture service.

Follow-up: security-preserving workaround for Windows screen capture and input (verified)

Short version: the strong Windows command sandbox does not need to be disabled. The workable design is to keep model-authored shell processes on the dedicated private desktop, while exposing screen capture and UI input as a separate, narrowly scoped, approval-gated capability launched by the trusted interactive Codex host.

The failure was architectural: the bundled helper inherited the sandbox process's window station, desktop, identity, and per-user service context. On that private desktop, EnumWindows correctly found no interactive-user windows, and Windows Graphics Capture could not activate the interactive user's capture service. Patching only the stale GetLastError() handling would improve the diagnostic, but it would not make the user's windows or capture service available there.

I verified a local proof-of-concept that keeps these settings enabled:

[windows]
sandbox = "elevated"
sandbox_private_desktop = true

[plugins."secure-windows-computer-use@personal".mcp_servers.secure-windows-computer-use]
enabled = true
default_tools_approval_mode = "prompt"

This is a local workaround/prototype, not an official OpenAI fix.

Architecture

Trusted Codex desktop host (interactive user / interactive desktop)
    |
    | private inherited stdio + Codex MCP approval for every tool call
    v
Local Computer Use broker (no network listener or global IPC endpoint)
    |
    | loads the installed @oai/sky package and starts the unmodified helper
    v
codex-computer-use.exe
    |
    +-- EnumWindows / accessibility on the interactive desktop
    +-- Windows Graphics Capture in the interactive user's service context
    +-- mouse and keyboard input after explicit approval

Model-authored shell/file commands
    |
    v
Dedicated elevated sandbox identity
    |
    v
Private desktop + filesystem/network policy boundaries

The important distinction is that interactive UI control is treated as a separate privileged capability, not as a side effect of granting the shell access to the user's desktop.

Security properties

The command sandbox remains elevated and on its private desktop; Full Access and sandbox_private_desktop = false are not required.
The broker uses inherited stdio only. It opens no TCP/HTTP listener, Windows service, globally reachable named pipe, or other endpoint that a sandboxed process could connect to.
Every Computer Use tool call is configured to prompt for approval. Do not set this server to automatic approval if preserving this boundary is a requirement.
The broker launches the vendor helper unchanged; this workaround uses no executable patching, DLL injection, debugger attachment, compatibility shim, registry weakening, driver change, or security-policy relaxation.
Sensitive target classes are denied in the broker (for example terminals, the Codex/ChatGPT UI itself, elevation or authentication dialogs, security settings, and credential entry). Input sizes and coordinates are validated.
Starting the broker code from inside the command sandbox does not grant access to the interactive desktop: it inherits the sandbox identity and private desktop and fails closed. Only the trusted host's inherited stdio child has the required context.
Approval is meaningful only if the user checks the target and requested action. Any UI automation capability can read visible content and send input when authorized, so this is capability isolation and explicit consent—not a claim of zero risk.

Verification performed after a full Codex restart

The replacement MCP server exposed the expected window discovery, screenshot/state, activation, click, scroll, drag, keyboard, text, value-setting, secondary-action, and app-launch tools.
Window enumeration and a full screenshot succeeded without the prior empty-window, process-spawn, or Windows Graphics Capture activation errors.
A disposable GUI test was captured before the action, clicked using coordinates derived from the returned screenshot geometry, captured again, and the expected state change was confirmed. The test process was then closed.
A separate probe executed from the command sandbox still could not activate Windows Graphics Capture for the interactive desktop. That failure is expected and confirms that the sandbox did not silently gain screen access.
The bundled failing Computer Use plugin was disabled only after the replacement was installed and verified, avoiding duplicate/conflicting tool servers.

Reusable implementation prompt

The implementation is large enough that pasting machine-specific files into this issue would be both noisy and unsafe. The following prompt captures the design and validation requirements without including any account name, computer name, local path, process ID, window title, or application-specific data:

Implement a security-preserving Windows Computer Use replacement for Codex Desktop.

Goal
Keep the normal Windows command sandbox enabled with:
  sandbox = "elevated"
  sandbox_private_desktop = true

Do not use Full Access, do not disable the private desktop, and do not weaken the
filesystem, network, registry, service, UAC, or process-isolation policies. Do not
patch codex-computer-use.exe, inject a DLL, install a compatibility shim, add a
driver/service, or expose a TCP/HTTP/global named-pipe listener.

Root cause to account for
The bundled helper can inherit the model-authored shell process's isolated account
and private desktop. EnumWindows then has no interactive-user windows to enumerate,
and Windows Graphics Capture cannot activate the interactive user's per-user capture
service. Clearing or fixing GetLastError only fixes the misleading HRESULT; it does
not cross the desktop/session boundary.

Required architecture
1. Back up every file that may change and provide an exact rollback procedure.
2. Create a personal Codex plugin containing:
   - a skill describing the approval and safety rules;
   - a local stdio MCP server launched directly by the trusted Codex desktop host;
   - a portable launcher that resolves the user's personal plugin/cache locations
     from standard environment data, with no hard-coded account or machine path.
3. The server must use JSON-RPC over inherited stdin/stdout only. It must create no
   network listener, Windows service, scheduled task, shared/global named pipe, or
   remotely reachable IPC endpoint.
4. From that trusted-host process, locate the newest valid installed @oai/sky package
   and its Windows codex-computer-use helper. Validate that both expected files exist,
   log only non-sensitive version/integrity metadata, dynamically import @oai/sky,
   and launch the vendor helper unchanged on the interactive user's default desktop.
5. Bridge the helper's tools through MCP. At minimum expose window/app listing,
   screenshot or window state, activation, click, scroll, drag, key press, text entry,
   value setting, secondary action, and approved app launch. Preserve image content
   returned by the helper.
6. Require Codex approval for every MCP tool call using:
     default_tools_approval_mode = "prompt"
   The helper's internal app approval may be accepted only while handling an already
   approved MCP call; it must never become a general unattended approval channel.
7. Add strict validation and fail-closed behavior:
   - reject malformed or oversized arguments and out-of-bounds coordinates;
   - deny terminals, command shells, the Codex/ChatGPT UI, elevation/authentication
     dialogs, security settings, credential entry, and any other sensitive targets;
   - never bypass secure-desktop/UAC protections;
   - never log screenshots, typed text, window titles, account names, hostnames,
     local absolute paths, tokens, or other personal data;
   - stop if the server is running under the sandbox identity/private desktop instead
     of as a direct child of the trusted interactive Codex host.
8. Keep the existing elevated private-desktop command sandbox enabled. Disable the
   bundled failing Computer Use plugin only after the replacement validates, so that
   there is one unambiguous Computer Use server.
9. Account for Codex builds that do not reliably resolve plugin-relative MCP command
   paths. Use a portable environment-resolved launcher rather than embedding a real
   username or machine-specific absolute path. Validate the plugin manifest and use
   the normal personal-plugin cache-busting/reinstall flow.
10. Fully exit and restart Codex so the trusted host recreates the MCP stdio process.

Verification gates
A. Configuration audit: elevated sandbox is true, private desktop is true, the
   replacement plugin/server is enabled, and every tool call prompts.
B. Broker-context audit: prove the stdio server is a child of the trusted interactive
   host, has no listening socket/service/global IPC endpoint, and is not reachable
   from model-authored sandbox commands.
C. Positive UI test: use a disposable non-sensitive GUI app. List windows, capture a
   screenshot, derive coordinates from the returned image, perform one harmless click
   after approval, capture again, and verify the expected visual/accessibility change.
D. Negative isolation test: from the normal command sandbox, attempt a read-only
   Windows Graphics Capture probe. It should remain unable to capture the interactive
   desktop. Treat success here as a security regression.
E. Negative target tests: confirm the broker refuses terminal, Codex/ChatGPT,
   elevation/authentication, security-setting, and credential-entry targets.
F. Restart test: fully restart Codex and repeat A-D to ensure this is persistent and
   not relying on stale processes.

Report
Provide the architecture, changed generic configuration keys, test results, known
limitations, and rollback steps. Redact all personal information, including account
and computer names, local paths, identifiers, window titles, screenshots, and tested
application names. If any verification gate fails, roll back or leave the bundled
plugin disabled only if that is safer, and explain the failure without weakening the
sandbox.

Recommended product-level fix

The durable upstream solution is the same separation implemented as a supported Codex component: keep shell execution in the private desktop sandbox, and have the trusted desktop host own a narrow, approval-gated Computer Use broker on the interactive desktop. The broker should authenticate its parent/channel, expose no ambient IPC surface, enforce target restrictions, and emit privacy-safe audit events. Separately, the helper should clear/check last-error state correctly around EnumWindows so an empty desktop produces an accurate diagnostic rather than a stale HRESULT.

That approach fixes window discovery, Windows Graphics Capture, and mouse/keyboard control without granting general shell processes access to the interactive desktop.

Update: correct Computer Use lifecycle cleanup

A later failure-recovery test found two separate lifecycle bugs in the prototype broker:

A rejected tool call poisoned the serialized MCP promise queue. Every later call on that server, including the cleanup call, replayed the old rejection without executing.
The broker cached the Computer Use client/transport beyond the end of a UI turn. That allowed stale in-memory window records and a helper process to survive after the requested UI work was complete.

The corrected broker now:

uses a recovering serial queue: each caller receives its own failure, while the internal queue tail is always settled so subsequent calls still execute;
provides an explicit finish_computer_use tool that ends the helper turn, closes the client/transport, clears every cached client reference and lifecycle flag, and forces the next UI operation to create a fresh client;
performs the same disposal after a tool failure, request cancellation, stdio shutdown, or a bounded idle timeout;
keeps the stdio MCP server alive while its Codex task is active, which is expected, but retains no Computer Use helper, transport, or window state between UI turns.

The live failure-recovery sequence now passes: normal enumeration succeeds; an intentional nonexistent-window request fails as expected; the following finish call executes instead of replaying the earlier error; no helper remains attached; a subsequent enumeration succeeds through a fresh client; and the final finish again leaves no helper attached.

This cleanup does not weaken the security boundary. The elevated private desktop remains enabled for model-authored commands, every broker action remains approval-gated, target restrictions remain enforced, and no listener, service, shared endpoint, or broadly accessible IPC mechanism was added.

For future implementations, add these requirements to the reusable prompt above:

Implement a recovering serialized request queue; never cache a rejected queue tail. Treat the Computer Use client and transport as per-turn resources. Add an explicit finish tool that sends the helper end-turn signal, closes the transport, clears cached state, and makes the next operation construct a fresh client. Run the same idempotent cleanup on tool error, cancellation, stdio shutdown, and bounded idle timeout. Add a regression test with this exact sequence: success, intentional failure, finish, verify zero attached helpers, fresh success, final finish, verify zero attached helpers. The long-lived stdio MCP server may remain alive, but no helper, transport, foreground mode, or window record may survive a finished or failed turn.

Update from the originally affected machine:

Setting the supported compatibility option below and fully restarting every Codex/ChatGPT process restored real window enumeration:

[windows]
sandbox = "elevated"
sandbox_private_desktop = false

Current result:

sky.list_windows() succeeds and returns real desktop windows.
helper still runs as 550W\CodexSandboxOffline.
the original 0x80070003 EnumWindows failure no longer reproduces.

This supports the private-desktop diagnosis already documented in this issue.

However, two separate failures remain after enumeration is restored:

A later independent node_repl/js call fails with:
Error: node_repl exec context not found
In workspace-write/windows_elevated mode, a same-execution screenshot attempt fails with:
IGraphicsCaptureItemInterop.CreateForMonitor failed:
The specified service does not exist as an installed service. (0x80070424)

Full access previously allowed same-call screenshot/launch operations, but did not fix the cross-call exec-context failure. Therefore the EnumWindows compatibility setting fixes the enumeration layer only, not the complete Computer Use workflow.

I can reproduce the same failure in a separate Windows Codex Desktop session on 2026-08-06.

Environment

Platform: Windows, Codex Desktop
Computer Use plugin: 26.730.61639
Runtime entry point: bundled cua_node with @oai/sky
Target application: an existing Brave browser window on the active desktop
In-app diagnostic feedback ID: 019fd61e-c1ae-7b10-996a-8c642778157f

Exact failure

@oai/sky imports successfully, but the first window discovery call fails immediately:

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

The failure occurs at sky.list_apps(), before any target window can be returned, activated, captured, or controlled. Brave was never touched and no UI input was sent.

Recovery attempts completed

The same error was reproduced after each of the following:

Waiting two seconds and retrying the lightweight sky.list_apps() call.
Resetting the persistent Node REPL kernel.
Re-importing @oai/sky in the fresh kernel.
Retrying from a separate user-requested Computer Use attempt.
Resetting the kernel again before that second attempt.

Every attempt failed at the same enumeration boundary with 0x80070003.

Separate bundled skill/runtime mismatch

The installed Computer Use skill instructs callers to load its required guidance with:

await sky.documentation("guidance")
await sky.documentation("confirmations")
await sky.documentation("api")

However, the loaded sky object does not expose a documentation function:

TypeError: sky.documentation is not a function

The runtime exposed these methods:

target
activate_window
get_window_state
click
scroll
drag
press_key
type_text
launch_app
list_apps
list_windows
get_window
perform_secondary_action
set_value
transport

The installed Markdown documentation files were readable locally, so this API mismatch did not cause the EnumWindows error itself. It does indicate that the bundled skill instructions and the loaded @oai/sky API are out of sync in the same installation.

Expected result

sky.list_apps() should return the currently available applications and windows, after which Computer Use should be able to select the existing Brave window and proceed through the normal safety controls.

Actual impact

Computer Use is completely unavailable because failure occurs before app or window selection. The required recovery procedure was exhausted, and the task had to stop without inspecting or changing the target application.

I'm facing the same issue. Installed Computer Use and it just doesn't work. Windows 11. Tried all the workarounds it suggested: rebooting, re-installing etc.

Still reproducible after the current Codex/Computer Use update on 2026-08-07.

Environment:

Windows x64, version 25H2, build 26200.8875
Codex desktop package: OpenAI.Codex_26.803.5235.0_x64
Computer Use plugin: 26.803.41515
Bundled @oai/sky: 0.6.2

Observed result:

EnumWindows failed: Das System kann den angegebenen Pfad nicht finden. (0x80070003)

The failure persists after a full Windows restart, reinstalling and re-enabling the Computer Use plugin, starting a completely fresh Node REPL session, running the Windows Repair action for the Codex app without resetting app data, and restarting Codex.

There is also still a bundled skill/runtime mismatch: the installed skill requires sky.documentation("guidance"), but typeof sky.documentation is "undefined". The loaded runtime exposes list_windows, list_apps, and the UI-control methods, but no documentation method.

The failure occurs before any target application can be selected or accessed.

Update: I now have end-to-end Windows Computer Use working on the same affected machine.

Working combination

[windows]
sandbox = "elevated"
sandbox_private_desktop = false

For the individual UI-testing chat, I selected Full access from the permissions control under the composer. I did not change the global sandbox_mode to danger-full-access.

In a fresh task, one live Computer Use execution successfully:

listed the visible windows;
acquired Windows Calculator;
captured its initial state;
clicked the 7 button;
captured the state again;
verified that the display changed from 0 to 7.

This confirms that, on this machine, elevated + sandbox_private_desktop = false + chat-scoped Full access restores window discovery, screenshot capture, and input. Ordinary Workspace access had continued to fail screenshot capture with 0x80070424.

Separate startup/config snag encountered while testing

I briefly changed the Windows sandbox to unelevated. Codex then became stuck on Finish Windows setup, and Continue with limited access hung and disappeared without opening the normal app. Returning the config to elevated did not immediately recover startup.

A TOML validation/recovery pass then exposed an unexpected invalid line in config.toml that I did not knowingly add. After removing that line, fully terminating all ChatGPT/Codex, node_repl, and codex-computer-use processes, and restarting, the app loaded normally again. I cannot determine what inserted the line, so I am not attributing it to a specific component.

The least-disruptive workaround currently working here is therefore:

keep sandbox = "elevated";
set sandbox_private_desktop = false;
use Full access only for the dedicated Computer Use/UI-acceptance chat;
keep window acquisition, capture, action, and verification in one live Computer Use execution.

This is still a workaround rather than an upstream fix, but it restores the Chrome-extension UI-testing workflow that was blocked by this regression.

Confirmed on another Windows 11 Pro 25H2 x64 system.

The problem persists after:

fully closing Codex and ChatGPT Classic
restarting only Codex
one controlled Computer Use retest
updating Codex through the Microsoft Store
fully restarting the updated app
one additional controlled retest

Environment after the update:

Codex desktop package: OpenAI.Codex_26.803.5235.0_x64
Computer Use skill: 26.803.41515
bundled @oai/sky: 0.6.2
typeof sky.documentation: "undefined"

Exact failure:

TypeError: sky.documentation is not a function

The bundled skill requires:

sky.documentation("guidance")

but the loaded runtime does not expose a documentation method.

Before the update:

Codex package: 26.730.8199.0
Computer Use skill: 26.730.61639
@oai/sky: 0.6.2

After the update:

Codex package: 26.803.5235.0
Computer Use skill: 26.803.41515
@oai/sky: still 0.6.2

All checked runtime hashes and the export list remained unchanged through the
update.

node_repl starts successfully and @oai/sky imports. The failure occurs before
the first Computer Use UI method, so the visible Notepad test window was not
focused, edited, saved, or closed.

The Windows sandbox setup, command runner, sandbox accounts, firewall rules,
Defender state, and local ACL operations were checked separately and did not
show a blocker for this reproduction.

No fallback automation, runtime patching, ACL changes, security changes, app
reset, or repeated retries were used.

Independent reproduction from another Windows installation on 2026-08-07.

Environment

Codex Desktop MSIX: 26.730.8199.0 (x64)
Computer Use plugin/skill: 26.730.61639
Bundled @oai/sky: 0.6.2
Windows x64

Reproduction

The supported package import succeeds, but both discovery calls fail immediately:

sky.list_apps()
sky.list_windows()

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

The failure reproduced in two separate Codex tasks:

019fde1e-db6b-7200-808e-ab3f7f52ebd1
019fdad4-a5c2-7e90-bfe8-fbda4dd3b7f6

Additional diagnostics

The helper executable exists, launches, and remains running in the same interactive Windows session as its parent Node runtime.
Closing the helper through sky.close(), resetting the Node runtime, re-importing @oai/sky, and retrying did not change the failure.
Rehydrating a freshly verified window by numeric handle through sky.get_window({ id }) also failed with the same EnumWindows error.
Passing a constructed window reference directly to sky.get_window_state(...) bypassed that enumeration error, but failed with foreground window did not report a process id.
An independent, read-only elevated Windows process/window scan successfully found 14 top-level windows. Every corresponding executable path resolved and existed, so this does not appear to be one ordinary visible process carrying a stale executable path.
Microsoft Store reported no newer Codex package available from the configured sources.
The bundled skill/runtime mismatch is also present: the skill requires sky.documentation(...), while typeof sky.documentation is undefined in @oai/sky 0.6.2.

No ACL, private-desktop, sandbox, cache, or configuration changes were made. No fallback mouse or keyboard input was sent. These results seem consistent with the private-desktop/window-station boundary described above rather than a missing helper binary or stale Node session.

An in-app feedback upload is still pending because it requires a manual action in the Codex composer; I can add its ID afterward.

Same here
Codex 26.803.5235.0, plugin 26.803.41515, @oai/sky 0.6.2, and errors sky.documentation is not a function plus spawn EPERM
Win 11 , Codex Pro Max plan

Additional confirmation that this regression persists in the newer Windows Computer Use bundle (observed 2026-08-30).

Environment:

Codex CLI/runtime: 0.151.0
Computer Use plugin: 26.818.32112
@oai/sky: 0.6.17-202608171537-pr-1300023-7efba775c041
Windows sandbox initially configured as elevated, with sandbox_private_desktop omitted (therefore using the documented private-desktop default)

Verified behavior:

In Workspace access, both sky.list_apps() and sky.list_windows() failed with EnumWindows failed: The system cannot find the path specified. (0x80070003).
A direct Win32 EnumWindows diagnostic outside the helper succeeded and returned hundreds of windows.
The failure survived full Codex restarts, a Windows restart, closing ordinary applications, testing an older complete Computer Use runtime, and restoring the current runtime.
Adding the documented compatibility setting below and fully restarting Codex immediately restored window discovery:

[windows]
sandbox = "elevated"
sandbox_private_desktop = false

With that setting and normal Workspace access, sky.list_apps() successfully returned real interactive-desktop windows. However, sky.get_window_state() then failed at the next layer with:

IGraphicsCaptureItemInterop.CreateForMonitor failed: The specified service does not exist as an installed service. (0x80070424)

Switching only that chat to task-scoped Full Access made discovery and screenshot capture work end to end. Returning the chat to Workspace access removed Full Access again.

This strongly supports the private-desktop / sandbox-identity diagnosis already documented here. The compatibility flag fixes enumeration, but complete Computer Use still requires unnecessarily broad task access on this build. A product-side broker for approval-gated window discovery, capture, and input in the interactive user's context would preserve the normal Workspace command sandbox and avoid this cumbersome security tradeoff.

Windows Computer Use fails at EnumWindows with 0x80070003 #37043

Description

Summary

Environment

Verified behavior

Process context

Troubleshooting already completed

Expected behavior

Actual behavior

Activity

kitmu commented on Aug 5, 2026

Environment

Update/failure timeline (UTC)

Narrowing completed

kaungacespsycoz-gif commented on Aug 5, 2026

Aphroditas commented on Aug 6, 2026

daigo-tamura commented on Aug 6, 2026

Environment

Observed behavior

Additional troubleshooting completed

pszemraj commented on Aug 6, 2026

Environment

Observed behavior

Troubleshooting completed

Impact

dingwen07 commented on Aug 6, 2026

Environment

Observed behavior

Additional narrowing

jiangyuShiro commented on Aug 6, 2026

dinwkey commented on Aug 6, 2026

Verified root cause and working fix/workaround

Root cause

How this was debugged

1. Separate bootstrap failures from enumeration failures

2. Attach CDB to the live helper

3. Disassemble user32!EnumWindows and inspect the returned HWND-list count

4. Rule out the helper callback

5. Read the helper's inherited desktop from the PEB

6. Compare with the real input desktop

7. Apply the supported compatibility setting and restart

Reusable prompt for future incidents

dinwkey commented on Aug 6, 2026

Short version

Second root cause: Windows Graphics Capture ran under the wrong user context

Third blocker: nested helper launch under the unelevated sandbox

Security implications

Suggested product-side fix

dinwkey commented on Aug 6, 2026

Follow-up: security-preserving workaround for Windows screen capture and input (verified)

Architecture

Security properties

Verification performed after a full Codex restart

Reusable implementation prompt

Recommended product-level fix

Update: correct Computer Use lifecycle cleanup

CosMoss114 commented on Aug 6, 2026

GodsBoy commented on Aug 6, 2026

Environment

Exact failure

Recovery attempts completed

Separate bundled skill/runtime mismatch

Expected result

Actual impact

geotavros commented on Aug 7, 2026

kurtwerners-stack commented on Aug 7, 2026

pszemraj commented on Aug 7, 2026

Working combination

Separate startup/config snag encountered while testing

CrazyProf commented on Aug 7, 2026

LunarHarbor commented on Aug 7, 2026

Environment

Reproduction

Additional diagnostics

gkdataio commented on Aug 10, 2026

krexil commented on Aug 31, 2026

Metadata

Metadata

Assignees

Labels

3. Disassemble `user32!EnumWindows` and inspect the returned HWND-list count