Computer Use on Windows fails during app/window discovery with 0x80070003

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

• #37306
• #37255
• #37215
• #37043
• #37201

Powered by Codex Action

Independent RDP-specific reproduction on the current Windows build:

Environment

• Codex Desktop MSIX: 26.803.5235.0 (x64)
• Computer Use plugin: 26.803.41515
• Bundled @oai/sky: 0.6.2
• Windows 11 build 26100
• Target application: mstsc.exe (RDP client 10.0.26100.8875)

Regression

The same RDP-screen inspection workflow worked normally in the Codex Desktop version installed before this update. After updating to 26.803.5235.0, Computer Use can no longer see the active RDP window.

Observed behavior

1. Importing the bundled Computer Use runtime initially fails with:

EPERM: operation not permitted, lstat '%LOCALAPPDATA%\OpenAI\Codex'

1. As a diagnostic only, after making the bundled dependencies importable from a normal temporary user path, the installed skill/runtime mismatch becomes visible:

sky.documentation is not a function

The current skill explicitly requires await sky.documentation("guidance"), but @oai/sky 0.6.2 does not expose that method.

1. sky.list_windows() then returns an empty array even though two mstsc.exe processes exist in the same interactive Windows session.

1. The current Codex configuration parses successfully, uses the supported Windows sandbox value, and explicitly allows mstsc.exe, so this does not appear to be a missing app allowlist entry.

Expected behavior

Computer Use should initialize from the bundled runtime without filesystem workarounds and enumerate/capture the visible RDP client window, as it did before the Desktop update.

No full session logs or configuration files are attached because they can contain private project and remote-system details; a sanitized trace can be provided if needed.

Independent confirmation from another Windows installation.

Environment

• Computer Use plugin: 26.803.41515
• Bundled @oai/sky: 0.6.2
• The Computer Use helper binary was refreshed by the August 7, 2026 update and starts successfully.
• Codex and the helper are running in the same active Windows session.

Reproduction after the update

1. Fully exit and restart Codex.
2. Reset the persistent JavaScript session.
3. Import @oai/sky according to the bundled skill.
4. Call sky.list_windows() or sky.list_apps().

Both calls fail immediately with:

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

The helper process remains running after the error, so this is not a helper-spawn failure. Also, typeof sky.documentation is still undefined, although the bundled SKILL.md requires sky.documentation("guidance").

The same enumeration failure was reproduced on plugin 26.730.61639 before updating to 26.803.41515. The update and a clean restart did not resolve it. No raw logs, local paths, or configuration files are attached.

Additional reproduction from Codex Desktop on Windows:

• Codex Desktop: 26.803.5235.0
• Computer Use plugin: 26.803.41515
• Bundled @oai/sky: 0.6.2
• Authentication mode: API connection rather than ChatGPT account sign-in
• sky.list_apps() and sky.list_windows() both fail immediately with EnumWindows ... (0x80070003)
• nodeRepl.homeDir is null
• nodeRepl.env is empty
• sky.documentation is undefined even though the bundled skill requires it

Recovery attempts that did not help:

1. Reset the JavaScript runtime and reinitialized @oai/sky
2. Restarted Codex
3. Used Windows Apps > Codex > Repair
4. Reinstalled the Computer Use plugin
5. Rebooted the full Windows PC

Computer Use worked earlier before the Codex Desktop update. No Windows security or privacy settings were changed.

Independent confirmation on Windows with Codex/Computer Use 26.803.41515.

In my case, sky.list_apps() succeeds and returns my custom app, and sky.get_window() resolves its window successfully. However, the first sky.get_window_state({ window, ... }) call fails immediately with Error: node_repl exec context not found.

This persists after resetting the runtime, restarting Codex, restarting the target application, and fully rebooting Windows. The failure reproduces against my custom app, so it is not limited to Calculator or Reliability Monitor.

This appears to be a variant where discovery succeeds but the Computer Use bridge fails when it attempts to capture or attach to the selected window.

I can independently confirm the same behavior reported by @FlyOverCoderKY.

My current environment is:

• Codex Windows app: 26.803.5235.0
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2
• Windows 11

In my case, sky.list_windows() succeeds and returns the available windows. However, when the persistent @oai/sky client is reused in a subsequent Node REPL execution, the sky.get_window_state() sequence fails with:

Error: node_repl exec context not found

I performed some additional isolation with Codex:

1. Reset the Node REPL runtime.
2. Imported @oai/sky.
3. Listed the windows.
4. Selected the Codex window.
5. Called get_window_state().

When all of these steps were performed within the same Node REPL execution, the operation succeeded.
Both of the following tests succeeded in a single execution:

• Accessibility-only state retrieval with include_screenshot: false and include_text: true
• Real screenshot capture with include_screenshot: true, producing one valid 1440 × 1256 screenshot

The failure returns when @oai/sky is initialized in one Node REPL execution and get_window_state() is called from a later execution.

This suggests that the remaining issue is not Windows Graphics Capture, GPU support, window discovery, or basic startup of codex-computer-use.exe. It appears to involve stale or incorrectly propagated Node REPL execution context when the persistent @oai/sky client is reused across executions.

The deployed node_repl implementation checks whether the stored asynchronous execution ID matches the current active execution ID. If they differ, it throws exactly:
throw new Error("node_repl exec context not found");

The bundled skill/runtime mismatch also remains. SKILL.md requires:
await sky.documentation("guidance")
but the loaded @oai/sky 0.6.2 object does not expose a documentation method.

As a temporary workaround, resetting the Node REPL and performing the import, window discovery, and Computer Use operation within a single execution works. However, this is difficult to use for normal multi-step Computer Use workflows that require repeated observe/action cycles.

No Computer Use runtime files were modified during these tests.

※I had this text written for the Codex, so I'm not sure if the English is correct...

Root-cause analysis for this issue. Still reproducing on 2026-08-09 with
Codex Desktop 26.803.5235.0 (26.803.41515), Windows 11 Pro 26200.

The helper is spawned inside the Windows sandbox, so it has no interactive desktop

codex-computer-use.exe runs as the sandbox account CodexSandboxOffline,
not as the logged-in user:

ChatGPT.exe -> <logged-in user>
+- codex.exe app-server -> <logged-in user>
+- node_repl.exe -> <logged-in user>
+- codex.exe sandbox -- node.exe kernel.js
+- codex-command-runner-0.147.0-alpha.6.5.exe -> CodexSandboxOffline
+- node.exe kernel.js -> CodexSandboxOffline
+- codex-computer-use.exe -> CodexSandboxOffline

A process running under a different user account is not attached to the
interactive window station (WinSta0). The window-station/desktop object path
cannot be resolved, and that surfaces as ERROR_PATH_NOT_FOUND (0x80070003)
from EnumWindows.

The helper binary itself is fine

Running the exact same codex-computer-use.exe directly as the logged-in
user and sending {"id":1,"method":"list_apps","params":{}} on stdin returns
40 apps with their windows arrays populated. This is not a missing
dependency or a bad build - it is purely which account the helper is
launched under.

Why it ends up in the sandbox: the app implements the escape hatch, the bundled runtime does not

The app already provides an out-of-sandbox path:

• it hosts a named pipe and logs

[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-<guid>

• it writes SKY_CUA_NATIVE_PIPE = "1" and

SKY_CUA_NATIVE_PIPE_DIRECTORY = '\\.\pipe\codex-computer-use-<guid>'
into [mcp_servers.node_repl.env] in ~/.codex/config.toml

But the bundled @oai/sky 0.6.2 (cua-node 0.0.6/20260723162306):

• contains zero references to SKY_CUA_NATIVE_PIPE in any file
• has native-pipe.js only under

dist/project/cua/sky_js/src/targets/mac/ - there is no
targets/windows/native-pipe.js

• the only Windows transport is targets/windows/helper_transport.js, whose

WindowsHelperTransport calls spawn(helperCommand, ...) and speaks
JSON-lines over stdio, so the helper inherits the sandbox token

The same version skew explains sky.documentation is not a function that
several people reported here: the bundled plugin SKILL.md (26.803.41515) says
to call await sky.documentation("guidance"), but sky 0.6.2 exposes only
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.

Refreshing the runtime does not help

The cua_node runtime bundled inside the app package
(app/resources/cua_node) declares the identical
runtime_archive_version 0.0.6/20260723162306 and ships the same sky 0.6.2
with no Windows native-pipe client. Clearing
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash> just re-extracts the
same code.

[windows] sandbox = "unelevated" is only a partial mitigation

It does make the sandboxed process run as the logged-in user - verified with
codex sandbox -c 'windows.sandbox="unelevated"' -- cmd /c whoami, which
returns the real user instead of CodexSandboxOffline - and the hard
EnumWindows error goes away. But every app then comes back with
windows: 0, so it is still unusable.

Suggested fix

Ship a cua_node runtime whose @oai/sky implements the Windows native-pipe
client that the app already stands up, so the helper runs outside the
sandbox as the logged-in user.

Independent local verification on 2026-08-08, without modifying the bundled runtime.

Environment

• Codex Desktop: 26.803.5235.0
• Computer Use plugin: 26.803.41515
• Bundled @oai/sky: 0.6.2
• cua_node runtime archive: 0.0.6/20260723162306-088049353ddc

Confirmed locally

• Codex config contains SKY_CUA_NATIVE_PIPE=1 and a configured Computer Use pipe path.
• That exact named pipe exists while Codex is running.
• The installed @oai/sky package contains no references to SKY_CUA_NATIVE_PIPE or SKY_CUA_NATIVE_PIPE_DIRECTORY.
• A native-pipe implementation exists under the macOS target, but not under the Windows target.
• The Windows WindowsHelperTransport uses child_process.spawn(helperCommand, ...) and JSON-lines over stdin/stdout.
• Dynamic enumeration of the installed sky object returns 15 methods and does not include documentation, while the bundled SKILL.md requires await sky.documentation("guidance").
• On this installation, resetting the Node REPL and performing import plus sky.list_windows() in one execution still fails with EnumWindows ... 0x80070003, so the same-execution workaround reported for the separate node_repl exec context not found variant does not resolve this machine.

This independently supports a Desktop/plugin/runtime version skew where the Windows runtime does not consume the host native pipe and instead follows the in-process helper-spawn path.

One attribution should remain provisional: these observations do not yet prove that EnumWindows itself produces ERROR_PATH_NOT_FOUND solely because the helper is not attached to WinSta0. EnumWindows has no path argument, and #37595 reports that a missing interrupt-marker path can be surfaced under the same error label. Instrumentation around the exact native call, GetProcessWindowStation, GetThreadDesktop, and immediate GetLastError handling would distinguish those cases.

The most direct compatibility fix still appears to be shipping a matched cua_node/@oai/sky runtime with the Windows native-pipe client already expected by the Desktop app, plus aligning the bundled skill with the runtime API. The helper should also treat a missing interrupt marker as "not interrupted" and preserve the real error source.

No runtime files or Codex configuration were modified during this verification.

Additional confirmation + one useful data point.

Same environment: Codex Desktop 26.803.5235.0, Computer Use plugin 26.803.41515, bundled @oai/sky 0.6.2, Windows 11, console session active. sky.list_windows() / sky.list_apps() fail immediately with EnumWindows failed: The system cannot find the path specified. (0x80070003).

Key data point: running the exact same bundled runtime (@oai/sky 0.6.2 from cua_node) from a normal PowerShell launched by the logged-in user, sky.list_windows() returns 16 windows successfully. So the failure is specific to how the app spawns the helper (sandbox account CodexSandboxOffline / non-interactive desktop), not the runtime or the machine.

Also confirmed: config.toml contains SKY_CUA_NATIVE_PIPE=1 plus the native-pipe directory, but the bundled @oai/sky 0.6.2 Windows transport does not consume it (helper_transport spawns the helper directly and inherits the sandbox token). Consistent with the root-cause analysis above.

Thanks for the bug report. We understand the problem and have a fix that will be included in the next release.

Additional reproduction on Windows with Computer Use plugin 26.803.41515.

Observed consistently:

• @oai/sky imports, but the loaded sky object does not expose documentation; sky.documentation("guidance") fails with sky.documentation is not a function.
• sky.list_windows() fails with EnumWindows failed: The system cannot find the path specified. (0x80070003).
• The problem affects Windows Calculator, Krita, and Live2D Cubism Editor.
• Resetting the persistent Node kernel, disabling/re-enabling Computer Use, restarting the desktop app, closing duplicate application windows, and retrying from another task did not restore enumeration.
• Application/file launching may still occur even though existing windows cannot be detected. This caused Cubism to open multiple duplicate instances.
• In one separate task, every underlying Calculator discovery/launch/window call failed, but the task nevertheless reported that Calculator displayed 12. This makes the failure particularly risky because a task may claim successful UI interaction without a successful Computer Use call.

Direct file verification confirmed that the versioned Krita and Cubism files created during the test were only byte-for-byte copies; no claimed visual inspection or UI edit could be verified.

No personal file contents or account information are included in this report.

It appears that the error 0x80070003 has been fixed in 26.803.61601. sky.documentation is still unavailable, though, but computer use is somewhat usable now.

Thank you for the update, @Artem-B. I installed the Codex update and can confirm that Computer Use package 26.803.61601 fixes the original 0x80070003 window-enumeration failure on my system: sky.list_windows() now successfully detects both Krita and Live2D Cubism.

However, UI capture still fails for both applications. Calling sky.get_window_state({ window }) with a window object returned by sky.get_window({ id }) produces:

SetIsBorderRequired failed: No such interface supported (0x80004002)

No UI actions were attempted after that failure. Also confirming that sky.documentation remains unavailable (TypeError: sky.documentation is not a function). So the update makes window discovery usable, but screenshot/state capture—and therefore safe visual control—is still blocked on this machine.

Retested after installing the latest Windows Codex update.

Current versions:

• Codex app: 26.803.10989.0
• Bundled Computer Use connector: 26.803.81509

The connector still discovers both applications successfully through sky.list_windows(). I then tested screenshot-backed state capture separately against one uniquely returned window for each application:

• Krita: sky.get_window_state({ window, include_screenshot: true, include_text: false }) failed with SetIsBorderRequired failed: No such interface supported (0x80004002).
• Refreshed the complete window list, rehydrated the newly returned Krita window, and retried once as directed by the bundled recovery guidance. The retry failed identically.
• Live2D Cubism Editor 5.3.03 FREE: an independent capture attempt failed with the same SetIsBorderRequired failed: No such interface supported (0x80004002) error.

No clicks, keyboard input, saves, or other UI actions were performed.

One improvement in this connector version is that its documentation is now supplied as bundled Markdown (docs/guidance.md, docs/api.md) instead of requiring the previously unavailable sky.documentation() method. However, screenshot/state capture remains blocked for both Krita and Cubism on this machine.

`` SetIsBorderRequired failed: No such interface supported (0x80004002) ``

This is a known open issue on Windows 10: https://github.com/openai/codex/issues/25178