Windows Computer Use cannot attach to any window; reports identical process as wrong owner

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

• #36335
• #37005
• #37092

Powered by Codex Action

Same issue here

Windows Codex Desktop: Computer Use transport fails with spawn EPERM despite helper launching successfully outside Desktop bridge

Summary

Computer Use in Codex Desktop on Windows fails before attaching to any application.

Initially, the Computer Use/UI-control bridge failed with:

EPERM: operation not permitted, lstat 'C:\Users\Iron Throne\AppData\Local\OpenAI\Codex'

Changing the Windows sandbox configuration from:

[windows]
sandbox = "elevated"

to:

[windows]
sandbox = "unelevated"

resolved the lstat failure.

After that change, the Computer Use package successfully loads, but initialization now fails at the window-control transport with:

spawn EPERM

Extensive testing shows that Windows can access the Codex directory, execute the Computer Use helper, and even spawn that exact helper from Codex's bundled Node runtime successfully.

This appears specific to the process-launch context used by the Codex Desktop Computer Use bridge.

Codex versions

Microsoft Store/AppX package:

OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0

Codex Desktop configuration reports:

BROWSER_USE_CODEX_APP_VERSION = "26.803.41515"

Codex CLI:

codex-cli 0.147.0-alpha.6.5

Platform:

Windows x64

Configuration

Computer Use is enabled:

[plugins."computer-use@openai-bundled"]
enabled = true

Current Windows sandbox configuration:

[windows]
sandbox = "unelevated"

The problem originally occurred with sandbox = "elevated" as an lstat EPERM.

Switching to unelevated fixed that first failure but exposed the current spawn EPERM.

Reproduction

1. Launch Codex Desktop on Windows.
2. Enable/use the bundled Computer Use plugin.
3. Start a task requiring control of a Windows application.
4. Computer Use initializes.
5. The package loads.
6. Window-control transport initialization fails with:

spawn EPERM

1. No connection to the target Windows application is established.

The target application is not relevant to the failure because the transport fails before attachment.

Original failure

With:

[windows]
sandbox = "elevated"

the bridge failed earlier with:

EPERM: operation not permitted, lstat 'C:\Users\Iron Throne\AppData\Local\OpenAI\Codex'

The directory exists and is accessible.

ACL:

NT AUTHORITY\SYSTEM              FullControl
BUILTIN\Administrators           FullControl
IRON-THRONE\Iron Throne         FullControl

Owner:

IRON-THRONE\Iron Throne

PowerShell can enumerate the directory normally.

Contents include:

bin
runtimes
chrome-native-hosts-v2.json

Bundled Node lstat test

Using Codex's own bundled CUA Node executable:

C:\Users\Iron Throne\AppData\Local\OpenAI\Codex\runtimes\cua_node\f1bf3cd3a5929acd\bin\node.exe

I executed:

const fs = require("fs");

fs.lstat(process.argv[1], (e, s) => {
    if (e) {
        console.error(e);
        process.exit(1);
    }
    console.log(s);
});

against:

C:\Users\Iron Throne\AppData\Local\OpenAI\Codex

Result:

Stats {
  ...
}

The lstat succeeds from the bundled Node runtime.

Computer Use helper verification

Exact helper:

C:\Users\Iron Throne\AppData\Local\OpenAI\Codex\runtimes\cua_node\f1bf3cd3a5929acd\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

Test-Path:

True

Direct execution:

& $cua --help

Result:

Error: unknown argument: --help

This confirms the executable launches.

Authenticode

Get-AuthenticodeSignature reports:

Status: Valid
StatusMessage: Signature verified.
Signer: OpenAI OpCo, LLC

The certificate is issued through Microsoft's verified code-signing infrastructure.

Zone.Identifier

No Zone.Identifier alternate stream is present.

Only the normal :$DATA stream exists.

Therefore the executable does not appear to be Mark-of-the-Web blocked.

Start-Process test

Executing:

Start-Process -FilePath $cua -ArgumentList "--help" -Wait -PassThru

successfully creates:

codex-computer-use

So Windows can directly create the helper process.

Critical reproduction: bundled Node child_process.spawn()

I then used the exact Node executable bundled with the CUA runtime:

C:\Users\Iron Throne\AppData\Local\OpenAI\Codex\runtimes\cua_node\f1bf3cd3a5929acd\bin\node.exe

to execute:

const { spawn } = require("child_process");

const exe = process.argv[1];

const p = spawn(exe, [], {
    stdio: ["ignore", "pipe", "pipe"]
});

p.on("spawn", () => {
    console.log("SPAWN SUCCESS");
    console.log("PID:", p.pid);
    setTimeout(() => p.kill(), 1000);
});

p.on("error", err => {
    console.error("SPAWN ERROR");
    console.error(err);
    process.exitCode = 1;
});

using the exact Computer Use helper path.

Result:

SPAWN SUCCESS
PID: 6804

Therefore this process chain succeeds:

PowerShell
→ Codex bundled CUA node.exe
→ Node child_process.spawn()
→ codex-computer-use.exe
→ SUCCESS

while the Codex Desktop Computer Use bridge reports:

spawn EPERM

when initializing the window-control transport.

Other helper verification

These binaries also execute successfully:

codex-windows-sandbox-setup.exe
codex-command-runner.exe
codex.exe

Results included:

codex-windows-sandbox-setup.exe
→ executed and attempted to parse its expected payload

codex-command-runner.exe
→ executed and reported missing pipe input

codex.exe --version
→ codex-cli 0.147.0-alpha.6.5

Troubleshooting already performed

I have already tried:

• Restarting Codex Desktop
• Fully terminating Codex processes
• Recreating %LOCALAPPDATA%\OpenAI\Codex
• Codex Repair
• Codex Reset
• Reinstall/recovery attempts
• Checking folder ACLs
• Checking folder ownership
• Checking helper existence
• Checking helper Authenticode signature
• Checking Zone.Identifier
• Direct helper execution
• Start-Process
• Bundled Node fs.lstat()
• Bundled Node child_process.spawn()
• Changing Windows sandbox from elevated to unelevated

The issue persists.

Observed distinction

With elevated sandbox:

Computer Use bridge
→ lstat C:\Users\Iron Throne\AppData\Local\OpenAI\Codex
→ EPERM

With unelevated sandbox:

directory access/package loading
→ succeeds

window-control transport startup
→ spawn EPERM

Outside the Desktop bridge:

bundled Node
→ fs.lstat()
→ SUCCESS

bundled Node
→ child_process.spawn(codex-computer-use.exe)
→ SUCCESS

Expected behavior

Computer Use should successfully start its native window-control transport and attach to Windows applications.

Actual behavior

Codex Desktop fails while starting the window-control transport with:

spawn EPERM

despite the same helper being spawnable from the same bundled Node runtime outside the Desktop bridge.

Suspected area

This appears to be related to the process token, environment, native-pipe initialization, or other launch context specifically established by Codex Desktop for the Computer Use transport.

The underlying executable and ordinary Node spawn() mechanism both work.

Additional note

The target application itself is unaffected and works normally.

The failure occurs before Computer Use establishes control of the target application.