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

1. Install or update the Codex/ChatGPT Windows desktop application.

2. Open Settings → Computer use.

3. Enable Any App.

4. Start a Codex task.

5. Ask Codex:

   Use Computer Use to open the Windows Start menu.
   

6. Codex loads the installed Computer Use skill.

7. The Computer Use runtime attempts to initialize @oai/sky.

8. 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:

1. initialize successfully;
2. discover available Windows applications;
3. request permission before controlling an application that has not previously been approved;
4. allow the user to select Allow or Always allow; and
5. 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:

1. Confirmed Settings → Computer use → Any App is enabled.
2. Fully exited and restarted the desktop application.
3. Started a fresh Codex task.
4. Retried with a fresh Computer Use runtime.
5. Used Windows Settings → Apps → Installed apps → ChatGPT/Codex → Advanced options → Repair.
6. Retried after Repair.
7. Used Windows Reset for the application.
8. Signed back in and retried after Reset.
9. Uninstalled and reinstalled the desktop application.
10. Retried after reinstall.
11. Confirmed the failing directory exists.
12. Inspected its Windows ACL.
13. Confirmed the current user, Administrators, and SYSTEM have inherited full control.
14. 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:

opened 08:03AM - 05 Mar 26 UTC

closed 03:06AM - 05 Aug 26 UTC

bug windows-os app

### What version of the Codex App are you using (From “About Codex” dialog)? 26….304.1528.0 ### What subscription do you have? Business ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? First start of Codex fails with error dialog (full copy below) From what I can figure, it's getting confused by the non ascii first letter of my username: `ø` being garbled into `�`. You can thank Windows default user folder naming scheme for this (it takes your first name from the MS account) [Window Title] Error [Main Instruction] A JavaScript error occurred in the main process [Content] Uncaught Exception: Error: EPERM: operation not permitted, mkdir 'C:\Users\�rer\.codex\sqlite' at mkdirSync (node:fs:1349:26) at t.mkdirSync (node:electron/js2c/node_init:2:17243) at gb (C:\Program Files\WindowsApps\OpenAI.Codex_26.304.1528.0_x64__2p2nqsd0c76g0\app\resources\app.asar\.vite\build\main.js:49:1090) at Object.<anonymous> (C:\Program Files\WindowsApps\OpenAI.Codex_26.304.1528.0_x64__2p2nqsd0c76g0\app\resources\app.asar\.vite\build\main.js:326:23989) at Module._compile (node:internal/modules/cjs/loader:1769:14) at Module._extensions..js (node:internal/modules/cjs/loader:1902:10) at Module.load (node:internal/modules/cjs/loader:1488:32) at Module._load (node:internal/modules/cjs/loader:1307:12) at c._load (node:electron/js2c/node_init:2:17999) at node:electron/js2c/browser_init:2:139583 [OK] ### What steps can reproduce the bug? As far as I am able to gather: 1. Have a windows account with a username that causes the user folder to have or start with a non ascii letter like 'æøå` 2. Install Codex from Microsoft Store 3. Attempt to start application ### What is the expected behavior? Normal first startup of the Codex app ### Additional information Musings, please do not take seriously: This takes me back to 2001, when even attempting to use non ascii characters inside comments of your scripts was dangerous. A time when most build tools would famously fail on my computer because my ignorant self made a username with non-ascii characters. `/home/?rer/` Never heard of the place!

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 medoe contains only ASCII characters;
• the failing path is rendered correctly;
• Codex starts normally;
• the operation is lstat, not mkdir;
• 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:

Environment OS: Windows Codex plugin: openai-bundled/computer-use/26.616.30709 @oai/sky: 0.4.13 Runtime path: C:\Users\username\AppData\Local\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117 Repro Steps Load bundled Computer Use client: C:\Users\username\.codex\plugins\cache\openai-bundled\computer-use\26.616.30709\scripts\computer-use-client.mjs Initialize Computer Use runtime. Attempt a read-only app listing health check. Actual Behavior Initialization fails determinist…

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:

Codex bundled plugins became unavailable after reinstalling Chrome extension on Windows Environment Platform: Windows App: Codex Desktop Affected bundled plugins: Browser / in-app browser Chrome extension integration Computer Use Summary After using the “reinstall Chrome extension” action in Codex, several bundled tools became unavailable. Computer Use stopped working, and the Browser tool also became unstable or disconnected. The issue later recovered after restarting and waiting for the …

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:

Currently trying to deploy the ChatGPT app to multiple devices, it is listed as 9PLM9XGG6VKS in the Microsoft Store. Currently, the latest package returns: OpenAI.Codex OpenAI.Codex_26.715.9079.0_x64__2p2nqsd0c76g0 when installed using get-appxpackage openai | select name, packagefullname in PowerShell. I am able to deploy the application without issue, however users are not administrators and I am unable to complete the setup as it is prompting a UAC. Normally, these applications could be …

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:

1. Which process performs the failing lstat.
2. Which Windows identity or sandbox token that process uses.
3. Whether the local Codex runtime directory is included in its permitted read roots.
4. Whether @oai/sky receives the correct normalized Windows path.
5. Whether the MSIX application version and local runtime/plugin versions are expected to interoperate.
6. Whether Computer Use initialization handles an existing but sandbox-inaccessible runtime path correctly.
7. 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.