[Windows][26.730.7989.0] Computer Use fails before app selection with EPERM lstat on Codex runtime

[Ahmedmabdallah484]

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

26.730.7989.0

What subscription do you have?

ChatGPT subscription (exact tier not displayed in Codex App)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

After updating the Codex Windows desktop app, Computer Use / Any App fails before it can enumerate or control any desktop application. This is not specific to Claude: a harmless Notepad test fails at the same initialization point.

Exact error (username redacted):

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

The failure happens while importing the bundled @oai/sky package, before list_windows() or any app-specific operation can run.

Impact

• Any App cannot control Claude, Notepad, or any other Windows application.
• No target application is opened or touched.
• Browser/in-app-browser functionality can still work, so the failure is specific to the Computer Use runtime initialization path.

Troubleshooting already completed

• Repaired the Codex app from Windows Advanced options.
• Restarted Codex.
• Rebooted Windows.
• Verified the affected directory exists.
• Verified the signed-in Windows user has Full Control on the directory.
• Retested with a fresh Node REPL kernel.
• Observed bundled Computer Use plugin cache refresh from 26.730.61309 to 26.730.61639; the same EPERM remains.

The problem started immediately after the Codex desktop update.

Relevant related reports

• Windows Computer Use reuses a stale node_repl exec context across JS calls #37013: same Codex AppX version and the earlier 26.730.61309 Computer Use plugin, but a different Computer Use transport/context failure.
• Native Windows Codex app: workspace dependency repair fails; npx/tsx and esbuild hit EPERM in sandbox #18861: closely matching Windows sandbox behavior where basic Node runs but lstat/realpath returns EPERM.
• Chrome plugin fails after reinstall: browser-client is not trusted / native pipe bridge unavailable #23884: plugin/browser diagnostics fail with EPERM: operation not permitted, lstat 'C:\Users\...' after reinstall.

This looks like a Windows AppContainer/sandbox runtime path regression rather than a target-app permission problem.

What steps can reproduce the bug?

1. Install or update Codex Desktop for Windows to 26.730.7989.0.
2. Enable the bundled Computer Use / Any App feature.
3. Start a fresh Codex task and request control of a harmless application such as Notepad.
4. The documented initialization runs:

if (!globalThis.sky) {
  const { sky } = await import("@oai/sky");
  globalThis.sky = sky;
}

5. The import fails immediately with:

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

The failure occurs before sky.list_windows() and before any desktop app is selected. Repairing the app, restarting Codex, and rebooting Windows do not resolve it.

What is the expected behavior?

@oai/sky should load successfully, sky.list_windows() should enumerate available windows, and Computer Use should then request/obey normal per-app authorization before interacting with Notepad or another selected application.

A user-level Full Control ACL on the extracted Codex runtime should not still produce EPERM inside the app's own sandboxed Computer Use loader.

Additional information

• Codex AppX: 26.730.7989.0 x64
• Windows: Microsoft Windows NT 10.0.26200.0 x64
• Computer Use plugin observed: 26.730.61309, later 26.730.61639 after cache refresh
• The path and account name above are deliberately redacted.
• Subscription tier is not displayed in the Codex app used for this report.
• Session ID omitted from this public report for privacy; it can be supplied privately if maintainers request it.

Recent issue search shows multiple new Windows/Computer Use reports between Aug 2-5, 2026, including #37013 on the exact same AppX version. This report is separate because the failure occurs even earlier, during the first @oai/sky import.

[annalundh7004-spec]

I have the same issue.

ChatGPT Desktop version: 26.730.61539
Windows 11 Home

Computer Use fails with EPERM before opening any application.

I tested with simple tasks such as:

• Open Notepad and create test.txt
• Open Chrome
• Record audio/video

Nothing opens. No files are created.

I also enabled the Computer Use plugin, granted all requested permissions, and disabled Controlled Folder Access in Windows Security, but the problem persists.

Feedback ID:
no-active-thread-e19fc198-2b09-7013-bfe8-42ca458eb61c

The problem persists after:

• Granting access to C:\Users\ander\AppData\Local\OpenAI\Codex
• Reinstalling the ChatGPT Desktop app
• Restarting Windows
• Disabling Controlled Folder Access

Feedback ID:
no-active-thread-e19fc198-2b09-7013-bfe8-42ca458eb61c

[indiangayfriend]

I have the same issue on another Windows system.

Codex Desktop version: 26.730.8199.0
Windows build: 10.0.26200.8875 x64
Computer Use plugin: 26.730.61639

Before resetting the Workspace, Computer Use failed with:

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

I then went to Settings > Configuration and ran Reset and install Workspace.

After the reset, @oai/sky loads successfully, but Computer Use still does not work. Both of these calls now fail:

sky.list_apps()     -> Error: spawn EPERM
sky.list_windows()  -> Error: spawn EPERM

So the Workspace reset changes the failure point, but does not restore Computer Use. The package can now load, while the Windows helper process still cannot start. No applications or windows can be enumerated or controlled.

Feedback ID:
019fd264-415a-7741-919f-e63c3615e235

[Ahmedmabdallah484]

Additional diagnostic update from the original reporter

I completed a controlled local investigation after the initial report. The original lstat EPERM can be moved past with a narrow read-only ACL, but Computer Use still cannot capture or control any window because the bundled Windows helper produces inconsistent internal app ownership.

Current environment

• Codex Desktop/AppX: 26.730.8199.0 x64
• Windows NT: 10.0.26200.8875 x64
• Bundled Computer Use plugin: 26.730.61639
• cua_node: 0.0.6
• @oai/sky: 0.6.2
• @oai/cua: 0.1.1
• codex doctor: installation reported healthy

Failure progression

1. Original failure:

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

2. A narrow ReadAndExecute ACL for the existing CodexSandboxUsers group on the Codex runtime root allowed @oai/sky to import. No Everyone permission was added and no write permission was granted.
3. With the default private sandbox desktop, list_windows() then failed with:

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

4. As a temporary A/B diagnostic only, setting:

   [windows]
   sandbox = "elevated"
   sandbox_private_desktop = false

   allowed list_windows() and list_apps() to enumerate six open windows. It did not restore Computer Use.
5. get_window_state() fails for both a classic Win32 application and a packaged Windows application with a contradictory owner error.

Notepad++:

window id <redacted> no longer belongs to process:C:\Program Files\Notepad++\notepad++.exe; current owner is process:C:\Program Files\Notepad++\notepad++.exe

Windows Notepad:

window id <redacted> no longer belongs to process:C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2606.15.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe; current owner is process:C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2606.15.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe

Fresh list_windows() results and list_apps() window objects were both tested. Rehydrating with get_window({ id, app }) also did not help. The owner printed before and after current owner is is byte-for-byte identical, yet the compiled helper rejects it.

Duplicate app identity evidence

The helper returns two records for the same application identity:

• one record derived from the executable, e.g. display name claude, with windows: []
• another record derived from the window, e.g. display name Claude, with the real window

The two returned app-id strings were checked by character count, UTF-8 byte count, and raw bytes. They are 100% identical ASCII strings. There is no hidden Unicode, path-prefix, slash, case, or normalization difference. The mismatch therefore appears to be in an internal identity variant/tag that is not shown in the formatted error.

Process, account, and desktop evidence

Observed process chain:

node_repl.exe                         -> interactive user
  codex.exe / codex-command-runner   -> CodexSandboxOffline
codex-computer-use.exe               -> CodexSandboxOffline

Direct Win32 checks produced:

• EnumWindows as the interactive user: succeeds and enumerates approximately 170 windows.
• EnumWindows inside the sandbox account: returns false, zero windows, GetLastError() = 5 (Access denied).
• From the sandbox, OpenInputDesktop("Default") plus EnumDesktopWindows succeeds and enumerates approximately 129 windows.
• With the temporary sandbox_private_desktop = false, the helper can list windows but app identity degrades to process:<path>, duplicate app records appear, and state capture still fails.

This makes the issue reproducible independently of Claude and independently of packaged apps: Notepad++ fails in the same way.

Sandbox mode matrix

Config	Helper identity/result	Filesystem sandbox
sandbox = "elevated"	helper runs as CodexSandboxOffline; enumeration can be made to work, but app ownership is inconsistent	enforced
sandbox = "unelevated"	helper spawn fails with EPERM before Computer Use starts	enforced

So unelevated provides the desired interactive-user identity but cannot launch the helper. elevated launches it under the separate sandbox identity, where app resolution/ownership breaks.

Native-pipe investigation

The runtime configuration contains SKY_CUA_NATIVE_PIPE=1 and a live named pipe is created by ChatGPT. However:

• no installed @oai/* Windows runtime file references or reads SKY_CUA_NATIVE_PIPE
• no reference was found in node_repl.exe or codex-computer-use.exe
• the installed @oai/sky Windows target contains only the direct helper transport
• the Windows create_client.js constructs that direct transport and ignores transport configuration
• a native-pipe client exists under the macOS target, not the Windows target
• importing @oai/cua does not select another transport; cua.computer resolves to the same sky client
• no supported environment or configuration switch was found that bypasses the codex-command-runner sandbox transition

In this installed build, ChatGPT creates and advertises a privileged native pipe, but the bundled Windows JS client does not appear to consume it.

Safety and rollback state

No executable was patched, the compiled owner check was not disabled, ChatGPT was not run as Administrator, no Everyone ACL was granted, and filesystem sandbox enforcement was verified. The temporary sandbox_private_desktop = false setting does not restore control and will be rolled back to restore private-desktop isolation.

Likely product-level fix

A safe fix appears to require one or both of the following inside the bundled runtime:

1. Wire the Windows @oai/sky client to the existing privileged native-pipe bridge so app/window discovery occurs in the correct interactive context while input remains policy-controlled.
2. Correct the Windows helper's app-record merge and owner comparison so a window is not rejected when its canonical app identifier is the same. Packaged AppUserModelID and classic Win32 canonical-path identities both need coverage.

Regression tests should include state capture and one authorized input against both Windows Notepad and Notepad++ while the helper is launched through the real Codex sandbox path.

At present, list_apps() / list_windows() can be made to work partially, but get_window_state() and all practical app control remain unusable.

[irukahairuka]

I can reproduce the same issue on Windows.

Computer Use plugin observed:

• computer-use/26.730.61639
• @oai/sky

Primary error:

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

The failure occurs before Computer Use can enumerate applications or windows.

Additional observations and troubleshooting:

• sky.list_apps() previously failed with spawn EPERM.
• PowerShell and WMIC child processes also initially failed with
  CreateProcessAsUserW failed: 5.
• The original shell path was the Microsoft Store alias:
  C:\Users\<redacted>\AppData\Local\Microsoft\WindowsApps\pwsh.exe.
• I installed the MSI/WiX build of PowerShell 7 and confirmed that pwsh
  now resolves to:
  C:\Program Files\PowerShell\7\pwsh.exe.
• Codex subsequently used:
  C:\Windows\System32\cmd.exe.
• The original lstat EPERM on the Codex runtime directory still remains,
  so replacing the Store PowerShell did not resolve the Computer Use failure.
• The error persists with Full Access enabled.
• Repairing/reinstalling the app and rebooting Windows did not resolve it.
• External Windows PowerShell can successfully access the directory.
• Test-Path, Get-Item, and icacls all succeed externally.
• The signed-in Windows user, Administrators, and SYSTEM have Full Control.
• Reinstalling the Computer Use plugin did not resolve the failure.
• The Computer Use plugin details display Skills 1, but do not display
  the documented MCP servers 1 / Computer-use section.

This appears consistent with a Windows Codex sandbox/runtime regression rather
than a normal NTFS permission problem or a target-application permission issue.

I can provide additional sanitized logs if needed.