Windows Computer Use fails during initialization with EPERM lstat despite valid ACLs
Summary
Computer Use in the Codex/ChatGPT Windows desktop app fails during initialization before it can discover or control any Windows application.
The failure is isolated to Computer Use:
- Codex starts and otherwise operates normally.
- Shell commands work.
- The in-app Browser works.
- External Chrome control through the ChatGPT extension works.
- Only the Windows Computer Use runtime fails.
The problem remains after Windows Repair, Reset, and a complete application reinstall.
Environment
- OS: Microsoft Windows NT
10.0.26200.0, x64 - Computer:
SENTINEL-ATLAS - Windows account: ASCII-only username,
medoe - Account membership: local Administrators group
- Installed package:
OpenAI.Codex - Package version last verified:
26.730.8199.0 - Package status:
Ok - Computer Use plugin:
openai-bundled/computer-use/26.730.61639 - Computer Use runtime:
@oai/sky - Installation source: Microsoft Store/MSIX
- Computer Use setting: Any App enabled
- Target test application: Windows Start menu or Autodesk Revit 2026
Exact error
Every Computer Use initialization attempt returns:
EPERM: operation not permitted, lstat 'C:\Users\medoe\AppData\Local\OpenAI\Codex'
The failure occurs before:
- Windows application discovery;
- an app-approval prompt;
- pointer or keyboard control;
- application launch; or
- interaction with the target application.
Steps to reproduce
-
Install or update the Codex/ChatGPT Windows desktop application.
-
Open Settings → Computer use.
-
Enable Any App.
-
Start a Codex task.
-
Ask Codex:
Use Computer Use to open the Windows Start menu. -
Codex loads the installed Computer Use skill.
-
The Computer Use runtime attempts to initialize
@oai/sky. -
Initialization immediately fails with:
EPERM: operation not permitted, lstat 'C:\Users\medoe\AppData\Local\OpenAI\Codex'
The Start menu does not open.
The same failure occurs when asking Computer Use to launch Revit 2026.
Expected behavior
Computer Use should:
- initialize successfully;
- discover available Windows applications;
- request permission before controlling an application that has not previously been approved;
- allow the user to select Allow or Always allow; and
- control the approved application on the active Windows desktop.
Actual behavior
Computer Use fails during runtime initialization.
No application is discovered or controlled, and no application-approval prompt appears.
Troubleshooting completed
The following actions were attempted:
- Confirmed Settings → Computer use → Any App is enabled.
- Fully exited and restarted the desktop application.
- Started a fresh Codex task.
- Retried with a fresh Computer Use runtime.
- Used Windows Settings → Apps → Installed apps → ChatGPT/Codex → Advanced options → Repair.
- Retried after Repair.
- Used Windows Reset for the application.
- Signed back in and retried after Reset.
- Uninstalled and reinstalled the desktop application.
- Retried after reinstall.
- Confirmed the failing directory exists.
- Inspected its Windows ACL.
- Confirmed the current user, Administrators, and SYSTEM have inherited full control.
- Confirmed no target application was already running during the test.
The error remained identical after every attempt.
Filesystem and ACL evidence
The failing path exists:
C:\Users\medoe\AppData\Local\OpenAI\Codex
It is a normal directory, not a junction or symbolic link.
Observed ACL:
C:\Users\medoe\AppData\Local\OpenAI\Codex
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
SENTINEL-ATLAS\medoe:(I)(OI)(CI)(F)
The ACL inspection completed successfully with zero failed files.
This suggests the error is not explained by an ordinary missing NTFS permission on that directory.
Control comparison
In-app Browser
The in-app Browser initialized successfully and navigated to:
https://example.com/
It returned:
Title: Example Domain
URL: https://example.com/
The visible page content was successfully inspected.
External Chrome
The ChatGPT Chrome extension connected successfully.
External Chrome navigation also succeeded:
Title: Example Domain
URL: https://example.com/
Shell access
PowerShell and approved shell operations can inspect the failing directory and its ACL successfully.
Computer Use
Computer Use alone fails before application discovery with the EPERM/lstat error.
This comparison suggests that:
- the general plugin system is operational;
- the browser-control runtime is operational;
- the Chrome native extension connection is operational;
- filesystem access through approved shell execution is operational; and
- the failure is specific to Windows Computer Use initialization or its sandbox/trusted-path configuration.
Impact
Computer Use cannot control any Windows application.
This blocks workflows requiring visual inspection or control of native Windows applications, including:
- Autodesk Revit;
- Windows Settings;
- the Start menu;
- native application testing; and
- GUI-only validation workflows.
Browser automation is not an adequate substitute for native Windows application control.
Related reports
Non-ASCII Windows usernames
Related issue:
That issue reports:
EPERM: operation not permitted, mkdir 'C:\Users\�rer\.codex\sqlite'
It concerns corruption of a non-ASCII Windows username during application startup.
This report is not an exact duplicate:
- the username
medoecontains only ASCII characters; - the failing path is rendered correctly;
- Codex starts normally;
- the operation is
lstat, notmkdir; - the path is the existing local Codex runtime directory;
- shell and browser control work;
- only Computer Use initialization fails; and
- this occurs on a substantially newer application version.
Computer Use package initialization
Related report:
That report also shows Windows Computer Use failing deterministically inside @oai/sky before application listing, although its exact module-resolution error differs.
Bundled-plugin/runtime reconstruction
Related report:
That report describes Windows bundled-plugin runtime reconstruction and helper-path failures. In this case, however, the in-app Browser and external Chrome integration remain operational.
Windows sandbox and helper launch
Related report:
That report describes Windows sandbox and helper-process launch failures affecting Node-backed Codex tooling. The exact error differs, but it may involve the same sandbox/trusted-path layer.
Suspected failure boundary
The available evidence suggests that the failure occurs while initializing the Node-backed Computer Use runtime.
A possible boundary to investigate is whether the runtime is permitted to inspect:
C:\Users\<user>\AppData\Local\OpenAI\Codex
The directory is accessible to the interactive user and through approved shell operations, but the Computer Use initialization process receives EPERM when performing lstat.
This may involve:
- a missing trusted-path declaration;
- a sandbox read-root omission;
- a stale runtime path after application migration or upgrade;
- an MSIX/runtime boundary mismatch;
- a Node runtime filesystem policy; or
- incorrect path authorization specific to
@oai/sky.
These are hypotheses, not proven root causes.
Requested investigation
Please investigate:
- Which process performs the failing
lstat. - Which Windows identity or sandbox token that process uses.
- Whether the local Codex runtime directory is included in its permitted read roots.
- Whether
@oai/skyreceives the correct normalized Windows path. - Whether the MSIX application version and local runtime/plugin versions are expected to interoperate.
- Whether Computer Use initialization handles an existing but sandbox-inaccessible runtime path correctly.
- Whether the error should expose more diagnostic information, including the rejected path policy or sandbox rule.
Desired resolution
Computer Use should initialize successfully when:
- the installed package is valid;
- the runtime directory exists;
- the interactive user has full control;
- Computer Use is enabled;
- the target application is visible on the active Windows desktop; and
- no administrator action is required.
If additional Windows permission, sandbox, or administrator configuration is required, the application should present a clear setup prompt instead of returning a raw EPERM/lstat error.
Additional evidence available
I can provide sanitized versions of:
- Codex desktop logs;
- Computer Use initialization logs;
- installed package metadata;
- Computer Use plugin inventory;
- process inventory;
- ACL output;
- Windows Event Viewer entries; and
- Windows Defender protection history.
No credentials, authentication tokens, or unrelated private configuration will be included.