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

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

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

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:

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

1. 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.
2. With the default private sandbox desktop, list_windows() then failed with:

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

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

``toml
[windows]
sandbox = "elevated"
sandbox_private_desktop = false
`
allowed list_windows() and list_apps()` to enumerate six open windows. It did not restore Computer Use.

1. 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.

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.

Related independent reproduction from another Windows task: with Codex 26.730.8199.0, Computer Use plugin 26.730.61639, and @oai/sky 0.6.2, a request to open NetEase Cloud Music failed on the first Computer Use attempt with spawn EPERM. Retrying and resetting did not recover app/window enumeration; sky.list_apps() and sky.list_windows() remained unusable. This looks consistent with a Windows helper/runtime initialization failure, although the observed error was spawn EPERM rather than lstat EPERM.

I can reproduce this exact failure on another Windows configuration:

• Windows 10 Enterprise 22H2 (build 19045.6456)
• Codex app 26.730.8199.0
• Computer Use plugin/runtime 26.730.61639

Computer Use worked before the automatic update from Codex 26.727.6591.0. After the update, both sky.list_windows() and sky.launch_app({ app: "winword.exe" }) fail immediately with spawn EPERM, before any desktop window or application can be enumerated or controlled.

Troubleshooting already completed without resolving it:

• Repaired the Codex app.
• Uninstalled and reinstalled the Computer Use plugin.
• Reproduced in a fresh Work task.
• Regenerated the bundled cua_node runtime from scratch.
• Tested Codex normally and elevated.
• Verified the controller executable exists and has Read/Execute permission.
• Verified the native controller pipe is created.
• Checked Defender, AppLocker, and Code Integrity logs; no matching block or quarantine event was found.

This confirms the regression also affects the stable Windows 10 22H2 line, not only Windows 11/Insider builds.

I was able to restore Computer Use on one affected Windows installation, and I wanted to share the result in case it helps narrow this down.

I don't have a programming or software engineering background. I'm an ordinary ChatGPT/Codex user. I investigated this together with my AI assistants, who helped me structure the diagnostics, compare contexts, inspect permissions, and test the repair.

Environment

• Codex Desktop/AppX: 26.803.5235.0 x64
• Bundled Codex: codex-cli 0.147.0-alpha.6.5
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2
• cua_node: 0.0.6/20260723162306-088049353ddc, Windows x64
• Runtime Node: 24.14.0

Initial symptoms

Computer Use was only partially functional:

• application/window discovery worked;
• it could sometimes launch Windows Calculator;
• reading window state/screen failed consistently.

The user-facing error was:

Error: node_repl exec context not found

Restarting the desktop app and using a fresh task did not initially resolve it. This external symptom looked similar to #37180, although I am not claiming every occurrence of that error has the same cause.

Diagnostic breakthrough

In a completely fresh task/execution context, the underlying failure became visible earlier, during Computer Use runtime initialization:

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

We then checked the Windows identity used by the protected Computer Use runtime. The relevant sandbox execution was running as the restricted local account CodexSandboxOffline, separate from the interactive Windows user.

ACL finding

Before changing anything, we saved the owner, inheritance-protection state, and full SDDL for these three paths:

• %LOCALAPPDATA%\OpenAI
• %LOCALAPPDATA%\OpenAI\Codex
• %LOCALAPPDATA%\OpenAI\Codex\runtimes

The saved pre-change ACL showed:

• %LOCALAPPDATA%\OpenAI had protected inheritance and granted inherited-object/container Full Control only to SYSTEM, Administrators, and the interactive user; it had no traversal/read-execute ACE for CodexSandboxOffline or CodexSandboxUsers;
• Codex inherited that state;
• runtimes already had an inheritable Read & Execute ACE for the local CodexSandboxUsers group, but the protected parent path still could not be traversed by the active CodexSandboxOffline identity.

The successful repair added only:

• a non-inheriting, folder-only Read & Execute ACE for CodexSandboxOffline on %LOCALAPPDATA%\OpenAI;
• a non-inheriting, folder-only Read & Execute ACE for the same identity on %LOCALAPPDATA%\OpenAI\Codex;
• an object-and-container inheriting Read & Execute ACE for the same identity on %LOCALAPPDATA%\OpenAI\Codex\runtimes.

No Full Control, write, modify, or delete permission was granted. No executable or runtime content was edited, and no broad permission was added to the user profile.

I am intentionally not posting a generic ACL command in this comment. The successful change and its pre-change SDDL backup are recorded, but account/SID and inheritance state are machine-specific. I can provide sanitized before/after SDDL and a backup-based rollback procedure if maintainers want them.

Result

After the ACL repair and a fresh Computer Use execution context:

• application discovery: PASS
• Calculator launch: PASS
• Calculator window-state/screen read: PASS

I repeated the Calculator launch and state/screen-read checks immediately before posting this comment; both passed again, without clicking inside Calculator.

This also explains why launching Codex as Administrator was not sufficient on this installation: the failing filesystem operation was performed by a separate restricted sandbox identity, not by the interactive process.

This fixed the issue on our affected Windows installation and may provide a diagnostic lead/workaround for other affected systems.

I am not claiming this is a universal fix or the confirmed product root cause. It is a machine-specific workaround/diagnostic finding until OpenAI maintainers confirm the sandbox/runtime initialization behavior. It may also explain only one path to the external node_repl exec context not found symptom discussed in #37180.

Following up on my earlier report in this thread.

The spawn EPERM failure I observed no longer reproduces on the current build:

• Codex Desktop AppX: 26.803.10989.0 x64 (was 26.730.8199.0 when I reported)
• Computer Use plugin: 26.803.81509
• @oai/sky: 0.6.6 (was 0.6.2)
• Windows 10.0.26200 x64, stock install

A cold start of the same desktop application that previously failed now returns {"launched":true}. A separate, independent node_repl/js call afterwards returns {"appCount":40,"windowCount":6} — list_apps() and list_windows() both work, which they did not after the failure I originally described.

To be clear about scope: I never reproduced the lstat-specific variant in the original report, so I can only speak to the spawn EPERM plus enumeration-unusable symptom I described. Anyone hitting the original failure mode should retest before this is closed.

Related: the stale exec-context defect tracked in #37013 is also resolved on this build.

Retested on 2026-08-11 with the current Windows build. The original pre-selection import failure still reproduces on this machine.

Current environment

• Codex Desktop AppX: 26.803.10989.0 x64
• Computer Use plugin: 26.803.81509
• Bundled @oai/sky: 0.6.6
• Windows 11 build 26100
• Target application: mstsc.exe (running in the same interactive Windows session)

Fresh reproduction

1. Reset the persistent JavaScript session.
2. Run the currently documented initialization:

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

1. The import fails immediately with:

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

The failure occurs before sky.list_windows(), before any RDP window can be selected, and before any per-app approval prompt can appear. Resetting the JavaScript session and retrying once produced the same result.

The newer plugin has removed the previous sky.documentation() mismatch by shipping its guidance as bundled Markdown, so that part has improved. However, the sandbox/runtime path-access failure remains on this installation. This suggests the fix in the current build is not effective on every affected Windows setup.

No raw logs, usernames, RDP addresses, full configuration files, or private project details are included.

Retested on our affected Windows installation after updating Codex. The original pre-selection spawn EPERM failure no longer reproduces for us.

Current environment:

• Codex Desktop AppX: 26.803.10989.0 x64
• Computer Use plugin: 26.803.81509

Verification performed in a fresh Computer Use context:

• list_apps(): PASS (40 apps)
• list_windows(): PASS
• Notepad launch: PASS
• Window/accessibility-state read: PASS
• Text input in Notepad: PASS

For additional context, before the update we tested a narrowly scoped Read & Execute ACL workaround for the sandbox identity. It did not resolve the failure and was fully rolled back. Computer Use began working only after the app/plugin update, with the original ACL state restored.

Our original user-facing failure was the spawn EPERM / unusable-enumeration variant, so this result should not be taken as confirmation that the separate lstat %LOCALAPPDATA%\OpenAI\Codex variant is fixed on every machine.

Retested with a controlled Workspace Access vs Full Access A/B comparison on the same Windows installation.

Environment

• Codex Desktop: 26.803.8161.0
• Bundled Computer Use plugin: 26.803.61601
• Windows: 10.0.26200.8875 x64

Workspace Access result

Fresh projectless task:

• approval_policy: on-request
• sandbox_policy: workspace-write
• managed/restricted filesystem profile

Computer Use initialization failed immediately with:

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

The failure occurred before app discovery/control. No filesystem escalation/approval prompt was surfaced. Calculator was opened only through a non-Computer fallback in that task.

Task ID: 019ffb4e-e628-7d21-b717-51e930bff1e1

Full Access result

A second fresh projectless task on the same machine used:

• approval_policy: never
• sandbox_policy: danger-full-access
• disabled/unrestricted filesystem profile

In this task, @oai/sky imported and exposed the expected control operations. These calls succeeded:

• sky.launch_app({ app: "Calculator" })
• sky.list_windows() verified the Calculator window

No EPERM occurred.

Task ID: 019ffb50-84d3-74a2-8ba2-0a3fca4848c2

This A/B result isolates the original lstat failure to the managed Workspace Access sandbox. The same Windows ACLs, plugin installation, helper, user session, and machine successfully perform Computer Use under Full Access. In Workspace Access, the internal lstat denial appears to terminate initialization without being converted into an on-request approval event.

Separate nonfatal observation: the Full Access bootstrap initially returned sky.documentation is not a function; however, the imported sky object remained usable and Calculator launch/window verification succeeded. No raw logs or unredacted usernames are included here.

Confirmed minimal ACL repair on a later Windows build

We reproduced the same pre-enumeration failure on another Windows system:

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

Environment

• Windows NT 10.0.26200.0 x64
• Computer Use component: 26.803.81509
• User, machine, application, network, and project details intentionally redacted

Diagnosis

The interactive user could access the installed runtime, and the sandbox group could access runtime descendants, but the existing local CodexSandboxUsers group lacked Read & Execute / directory traversal on the Codex runtime root itself.

Minimal repair that worked

Run from an appropriately authorized Windows shell, replacing <computer> with the local machine name:

icacls "%LOCALAPPDATA%\OpenAI\Codex" /grant "<computer>\CodexSandboxUsers:(RX)"

Important scope details:

• no /T (not recursive)
• no write or Full Control
• no Everyone ACE
• only (RX) on the existing Codex runtime root

After fully restarting the desktop app, a fresh read-only sky.list_apps() call succeeded and returned the installed applications again. Before the ACL change, the same initialization path failed consistently with EPERM.

This is narrower than granting the interactive user access: the missing principal was the Codex sandbox group, and the missing permission was parent-directory traversal/read-execute.

Product implication

This evidence suggests that the Windows installer/updater should verify or migrate the required non-recursive traversal/read-execute ACE on the extracted Codex runtime root. That installer/updater explanation is an evidence-based hypothesis; installer internals were not independently verified.

Reported by Leon & Jack from TACHYON.

Additional two-machine reproduction (August 20, 2026):

This failure now reproduces independently on two different Windows computers running separate ChatGPT/Codex desktop app installations.

Observed on both machines when initializing the bundled Browser controller through mcp__node_repl__js:

node_repl kernel exited unexpectedly
Error: EPERM: operation not permitted, lstat 'C:\Users\<redacted>\AppData'

The failure occurs before the Browser runtime can connect to or enumerate the visible in-app browser tab. The app can display the browser and surface its URL as ambient UI state, but the agent cannot inspect or control it.

Environment confirmed on one affected machine:

• Codex desktop app: 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Windows desktop
• Runtime loader: bundled browser-client.mjs through node_repl

Troubleshooting already completed across the two installations:

• App Repair
• Clean reinstall
• App update
• Full Windows restart
• Fresh task and fresh Node REPL initialization
• Read permission request for C:\Users\<redacted>\AppData reported as granted, but the isolated Node helper still failed on the same lstat
• No manual broadening of AppData ACLs was performed because of the security exposure

This appears to be the same ancestor-path traversal/sandbox-permission regression, now affecting the bundled Browser controller as well as Computer Use. Reproducing with separate Windows installations makes machine-specific ACL corruption unlikely.

Expected behavior: the sandboxed Node runtime should be able to resolve its own trusted bundled runtime path and attach to the in-app Browser without requiring broad read access to the user's AppData contents.