Codex Computer Use spawn EPERM on Windows: Diagnose the Regression

If Codex Computer Use on Windows returns spawn EPERM from sky.list_apps() or sky.list_windows(), stop reinstalling components and first compare the app and plugin versions. Reports opened on August 6, 2026 consistently pair Codex app 26.730.8199.0 with Computer Use runtime 26.730.61639. The failure happens before Codex can enumerate a window or move the pointer, and current reports do not establish a safe client-side fix.

Treat this as a version-specific launch regression until a newer app or Computer Use runtime proves otherwise. Preserve the exact versions and one minimal reproduction, avoid broad permission changes, and use a non-Computer-Use path for urgent work.

Confirm You Have the Same Failure

The useful signal is not just the word EPERM. Confirm all four conditions:

1. You are running the Codex desktop app on Windows.

2. Computer Use is installed and enabled.

3. The package loads, but the first desktop operation fails.

4. The error appears before any window is listed or controlled.

In a disposable diagnostic task, run the smallest documented probe:

const { sky } = await import('@oai/sky');
await sky.list_apps();

Repeat with sky.list_windows() only if the first result is ambiguous. If both immediately return spawn EPERM, you match the launch boundary described in openai/codex issue 37272 and its duplicate issue 37284.

Do not test by asking Codex to click, type, or change a real application. The minimal list operation already proves whether the helper can start, and it avoids side effects while the control path is unhealthy.

Check the App and Plugin Pair

Open the app's About dialog and record the full Codex version. Then open the Computer Use plugin details and record its runtime version. Do not shorten either value.

The independently reported failing pair is:

One reporter said Computer Use worked on app 26.727.6591.0 and failed immediately after the Microsoft Store updated the app to 26.730.8199.0. Another reproduced the same pair on a different Windows build and found that even a child-process probe returned EPERM. That is stronger evidence for a shared launch regression than for a damaged local project.

Version evidence matters because the same surface also has a separate failure signature.

Separate spawn EPERM From EnumWindows 0x80070003

Several reports opened within hours of each other, but they do not all fail at the same boundary.

Do not apply an EnumWindows workaround to a spawn EPERM failure just because both prevent window control. If the import itself fails, isolate the Node REPL setup instead of changing desktop permissions. If Computer Use is absent only inside project tasks, use the missing Chrome and Computer Use guide.

This boundary-first diagnosis keeps one symptom from turning into an unrelated configuration change.

Stop Repeating the Reported Non-Fixes

Across the linked reports, users already tried most routine recovery steps without restoring Computer Use:

• restarting Codex and Windows;

• repairing, resetting, or reinstalling the app;

• uninstalling and reinstalling the plugin;

• rebuilding the bundled cua_node runtime;

• starting Codex normally and elevated;

• disabling the private desktop; and

• checking Defender, AppLocker, and Code Integrity logs without finding a matching block.

These are observations, not proof that every repair will always fail. They do show that another reinstall is a weak next step when your version pair and minimal probe match the cluster.

Do not grant broad ACLs under %LOCALAPPDATA%, copy bundled executables into an untrusted location, disable endpoint protection, or keep Codex elevated. Issue 37293 reports that manually redirected runtime paths were rewritten on restart anyway. Permission broadening can create a security problem without resolving the version mismatch.

Preserve a Small Diagnostic Record

Capture only what an upstream maintainer needs:

1. Codex app version from About.

2. Computer Use runtime version and @oai/sky version when visible.

3. Windows edition, version, build, and architecture.

4. The exact sky.list_apps() result.

5. Whether the failure occurs in a fresh disposable task.

6. Whether any pointer movement or window enumeration occurred.

7. A sanitized task or feedback ID if you choose to share it.

Mention the nearest existing issue instead of opening another duplicate. For spawn EPERM on the failing version pair, consolidate evidence in issue 37272. For EnumWindows 0x80070003, follow issue 37306 and the related issue 37255.

Never upload screenshots of private applications, raw environment dumps, tokens, personal paths, or the contents of your Codex configuration. A version table and sanitized minimal error are enough to establish this regression.

Use a Safe Temporary Path for Urgent Work

Until a corrected app and plugin pair is available, separate the goal from the broken desktop-control mechanism:

• Use ordinary Codex shell and file tools for repository work that does not require clicking a GUI.

• Perform the blocked UI step manually and return the resulting file or status to Codex.

• Prefer a provider's authenticated API over browser or desktop clicking when the operation has a supported API.

• Pause any unattended workflow whose verification depends on Computer Use.

Do not substitute unrestricted external execution merely to make desktop control start. The reported failure is inside the Computer Use launch path, and weakening an unrelated sandbox does not produce a trustworthy recovery.

If normal Windows sandbox commands also fail outside Computer Use, diagnose that separately. The CreateProcessAsUserW guide covers a different command-execution boundary.

Retest Only After the Version Pair Changes

When the app or Computer Use plugin updates, retest in this order:

1. Record the new app and plugin versions.

2. Start a fresh disposable task.

3. Run only sky.list_apps().

4. Confirm it returns a structured list without spawn EPERM.

5. Run sky.list_windows() and confirm the expected windows appear.

6. Ask for one read-only inspection of a disposable application.

7. Restore an automated workflow only after all three boundaries pass.

A successful import is not enough. A started helper is not enough. The recovery is verified only when listing works and a harmless read-only inspection reaches the intended window.

Monitor the Upstream Issue Without Repeated Manual Checks

Aident Loadout can query the connected GitHub issue surface without putting a provider token in your prompt. Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then use this bounded prompt:

Check my Aident Loadout account and Vault status. Find a connected read-only GitHub issue search Action, inspect its current schema, and preflight it. Return the status, updated time, comment count, and any maintainer-authored workaround or release reference for openai/codex issues 37272, 37293, 37306, and 37255. Do not create or edit issues, post comments, change files, or ask for a provider key.

Success is measurable: you receive four current issue records, the Action performs zero GitHub writes, and no credential appears in the prompt or result. Ready to monitor the release safely? Set up Aident Loadout and run the read-only check.

Sources

• OpenAI Codex issue 37272: Computer Use fails with spawn EPERM after update

• OpenAI Codex issue 37284: child processes return spawn EPERM

• OpenAI Codex issue 37293: AppData runtime paths and spawn EPERM

• OpenAI Codex issue 37255: EnumWindows cannot find the path

• OpenAI Codex issue 37306: Computer Use fails before window enumeration

• OpenAI: ChatGPT Work and Codex

• OpenAI: Using Codex with your ChatGPT plan

Refresh this guide when any cited issue changes state, a maintainer publishes a supported workaround, the Codex app or Computer Use runtime changes the failing version pair, or a release passes the three-boundary retest.