Windows Computer Use fails with spawn EPERM; elevated sandbox setup fails on WindowsApps ACL

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

• #37284
• #37293
• #37272

Powered by Codex Action

# Bug report: Sandboxed Computer Use unusable — sandbox accounts provisioned without user profiles; runtime directory ACL missing

Product: Codex desktop app for Windows (Computer Use)
Severity: Computer Use completely non-functional in sandboxed mode; works only with the sandbox bypassed (full access)
Date observed: 2026-08-06
Reporter environment is available for follow-up questions.

---

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Home, build 26200 (10.0.26200) |
| Codex app | 26.730.8199.0, MSIX/Store install (C:\Program Files\WindowsApps\OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0) |
| command-runner | codex-command-runner-0.147.0-alpha.1.2.exe |
| Computer Use runtime | cua_node 0.0.6 (payload dir fb8898c05a62885e), codex-computer-use.exe v0.1.0 (@oai/sky) |
| Sandbox accounts | CodexSandboxOffline, CodexSandboxOnline in group CodexSandboxUsers, created 2026-08-03 22:17 |
| Machine state | Fresh machine, single interactive user, local admin, no domain/GPO |

Summary

On this machine the Codex installer created the sandbox accounts but left sandbox
provisioning incomplete in two independent ways:

1. No ACL for CodexSandboxUsers on Codex's own runtime directory

(%LOCALAPPDATA%\OpenAI\Codex). The sandboxed tool process cannot even
lstat the Computer Use runtime, so the plugin fails to initialize.

1. No Windows user profiles were ever created for the sandbox accounts

(no C:\Users\CodexSandboxOffline, no ProfileList registry entries).
Sandbox processes therefore resolve their profile directory to
C:\Users\Default, where every profile-relative operation fails with
access-denied or path-not-found.

Result: sandboxed Computer Use fails at every stage; switching the workspace to
full access (tools run as the interactive user) makes Computer Use work
perfectly and immediately — a clean A/B isolating the sandbox identity as the
sole variable.

A repair/reinstall of the app did not create the profiles, did not fix the
ACL (our manual grant survived), and re-laid the identical runtime payload.

Symptoms, in the order encountered

Stage 1 — runtime init fails (before the ACL workaround):

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

The directory's DACL contained only SYSTEM, Administrators, and the interactive
user — no entry for CodexSandboxUsers. From inside the sandbox even icacls
on that path returned "Access is denied."

Workaround applied: icacls "%LOCALAPPDATA%\OpenAI\Codex" /grant "CodexSandboxUsers:(OI)(CI)(RX)"
— after this, the runtime initializes and the failure moves deeper.

Stage 2 — native layer fails (after the ACL workaround):

sky.documentation is not a function
EnumWindows failed: The system cannot find the path specified. (0x80070003)
window.app must be a non-empty string and window.id must be an integer >= 0

• sky.documentation is advertised to the model by the harness but is not

exported by the installed @oai/sky in cua_node 0.0.6 — an app/runtime
version mismatch, independent of the sandbox issue.

• 0x80070003 is ERROR_PATH_NOT_FOUND surfacing from

codex-computer-use.exe (which drives the interactive desktop via
OpenInputDesktop / SetThreadDesktop / EnumWindows / UI Automation) when
run under the profileless sandbox identity.

• The third error is downstream fallout: no enumeration → no window target.

Corroborating evidence from Codex's own sandbox log
(%USERPROFILE%\.codex\.sandbox\sandbox.<date>.log), present on every
launch:

[codex-command-runner-0.147.0-alpha.1.2.exe] hide users: failed to hide current user
    profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default:
    5 (Access is denied.)
[codex-command-runner-0.147.0-alpha.1.2.exe] junction: failed to create
    C:\Users\Default\.codex\.sandbox\cwd: Access is denied. (os error 5)

Both lines show the runner treating C:\Users\Default as the sandbox
account's "current user profile dir" — i.e., GetUserProfileDirectory for
the sandbox token falls back to the Default profile because no real profile
exists.

The A/B that isolates the cause

| Configuration | Result |
|---|---|
| Sandboxed (default) | EnumWindows failed: The system cannot find the path specified. (0x80070003) — every attempt, including after app repair |
| Full access (sandbox bypassed, same machine, same session, minutes later) | Computer Use works perfectly — native layer enumerated all 5 open windows (Revit, Codex, Claude, Settings, GitHub Desktop) and drove them normally |

Nothing else changed between the two runs. The sandbox identity is the variable.

Reproduction

1. Windows 11 Home (10.0.26200), fresh machine, single user.
2. Install the Codex desktop app from the Store (MSIX), version 26.730.8199.0.
3. Confirm sandbox accounts exist (net localgroup CodexSandboxUsers) and that

no C:\Users\CodexSandboxOffline directory or
HKLM\...\ProfileList entry exists for them.

1. In any project, ask Codex to use Computer Use (e.g., "take a screenshot").
2. Observe the EPERM lstat on %LOCALAPPDATA%\OpenAI\Codex; verify with

icacls that CodexSandboxUsers has no entry there.

1. Grant (OI)(CI)(RX) on that directory to CodexSandboxUsers; retry.
2. Observe EnumWindows failed ... 0x80070003 and the

C:\Users\Default access-denied lines in the sandbox log.

1. Switch the workspace to full access; retry — Computer Use works.

Expected behavior

Either the installer/first-run provisioning creates real profiles for the
sandbox accounts (and grants them read access to the Codex runtime directory),
or the Computer Use architecture brokers desktop interaction through a process
with interactive-desktop rights instead of running the desktop driver directly
under a profileless sandbox identity.

Suggested fixes / questions for the team

1. Provision user profiles for CodexSandboxOffline/CodexSandboxOnline at

install or first sandbox logon (the MSIX install context may be why this
silently fails today — nothing in the UI reports it).

1. Have the installer grant CodexSandboxUsers read/execute on

%LOCALAPPDATA%\OpenAI\Codex (our manual narrow grant was sufficient for
runtime init and survived a repair).

1. Detect the profileless state at runtime and surface an actionable error

instead of EPERM lstat / 0x80070003 deep in the stack.

1. Ship @oai/sky and the harness prompt in lockstep so advertised functions

(sky.documentation) exist in the installed runtime.

1. Clarify intended design: is codex-computer-use.exe supposed to run under

the sandbox identity at all, given it must open the interactive input
desktop? (UIPI/window-station ACLs make that fragile even with profiles.)

Workaround currently in use

Full-access mode for sessions that need Computer Use — acceptable on this
single-user machine, but it discards the sandbox entirely, which is presumably
not the intended trade-off.

Artifacts available on request

• Full sandbox.2026-08-06.log
• icacls output before/after the ACL grant
• net user CodexSandboxOffline / group membership listings
• Exact error transcripts from the failing and succeeding sessions

I can provide an independent reproduction on the current Windows build, plus a controlled A/B that isolates the failure to the Codex-managed sandbox/desktop bridge rather than the signed Computer Use binary itself.

Environment

• Windows 11 Pro 23H2, build 22631.6199, x64
• Store/MSIX package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
• Computer Use plugin: 26.803.41515
• Bundled Codex CLI: 0.147.0-alpha.6.5
• @oai/sky: 0.6.2
• @oai/cua: 0.1.1

All user-specific paths and identifiers are redacted below.

Reproduction after clean reinstall

A complete uninstall/reinstall from the official Store-signed x64 package was performed, followed by a fresh plugin/runtime generation. The supported in-app Computer Use path still cannot complete the first usable desktop operation.

The failure chain has two stages:

1. In the elevated/managed sandbox, importing @oai/sky initially failed with:

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

The app automatically grants CodexSandboxUsers read/execute on the bin and runtimes children, but the parent OpenAI\Codex traversal boundary was not readable by the sandbox identity.

1. Granting only minimal read/execute access on that parent makes the import succeed, but the supported managed path then fails during desktop discovery with:

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

This is the same public symptom reported in #37383 and several recent Windows reports. Reinstalling the same current package, refreshing the plugin/runtime, resetting the Node kernel, restarting Codex, and restarting Windows do not resolve it.

Controlled A/B: the exact official runtime works as the interactive user

For diagnosis only, I launched the exact same bundled, signed node_repl.exe and codex-computer-use.exe as the signed-in interactive Windows user with the Node sandbox disabled.

That temporary probe successfully completed the full chain:

• list_windows()
• list_apps()
• binding the exact Notepad window
• get_window_state() with real text and a screenshot
• sending a key input to Notepad

The probe process was then terminated. It was not retained as a configuration workaround.

This demonstrates that the shipped Computer Use helper, Windows window enumeration, screenshot capture, and input injection all work on the same machine. The variable that changes the result is the execution identity/bridge: the supported in-app managed path versus the interactive user context.

Shipped transport evidence

In the shipped @oai/sky 0.6.2 Windows target:

• targets/windows/internal/helper_transport.js imports spawn from node:child_process and starts codex-computer-use.exe directly over stdio.
• The desktop host provides SKY_CUA_NATIVE_PIPE=1 and a SKY_CUA_NATIVE_PIPE_DIRECTORY value.
• The shipped Windows target does not consume those values.
• The bundled native-pipe implementation is under the macOS target and uses nodeRepl.nativePipe.

The desktop app also regenerates mcp_servers.node_repl.args = [] on restart, so a temporary --disable-sandbox diagnostic cannot become a durable supported repair.

Security controls checked

No matching block was found in:

• AppLocker EXE/DLL, MSI/Script, or packaged-app logs
• Code Integrity operational logs
• Microsoft Defender ASR / Controlled Folder Access events
• Application/System crash or access-denied events for the Computer Use helper

The relevant OpenAI binaries have valid signatures. A separate unrelated Defender detection was excluded from the causal chain.

Requested fix

Please route Windows Computer Use through the desktop host's native bridge, or otherwise launch/broker the helper in a supported context that can access and own the signed-in user's active desktop windows. The runtime installer should also provision traversal/read access on every required parent directory, not only deeper children.

A release-gate test should require all of the following under the supported Windows sandbox configuration:

1. import @oai/sky
2. list_windows()
3. list_apps()
4. get_window_state({ include_text: true, include_screenshot: true })
5. one harmless input action to an approved interactive-user app

Passing import or enumeration alone is not sufficient. I can provide sanitized logs and exact shipped-file hashes privately if a maintainer requests them.

Independent confirmation on the current Windows build, with a reversible permissions A/B in the same Codex task.

Environment

• Windows 11 Pro 25H2, build 26200.8973, x64
• Codex app: 26.803.5235.0
• Computer Use plugin: 26.803.41515
• @oai/sky: 0.6.2

Before testing, I granted CodexSandboxUsers read/execute traversal on %LOCALAPPDATA%\OpenAI and %LOCALAPPDATA%\OpenAI\Codex, plus inherited (OI)(CI)(RX) on the Codex runtimes directory. I then restarted Codex and Windows.

Using a freshly reset node_repl kernel each time:

1. Normal task permissions: importing @oai/sky succeeds, but the first await sky.list_windows() fails immediately with spawn EPERM.
2. Full Access, same task and machine session: sky.list_windows() succeeds and returns all 5 open windows. A subsequent get_window_state({ include_screenshot: false, include_text: true }) on the visible Codex window also succeeds and returns accessibility state.
3. Back to normal permissions: after another clean kernel reset, sky.list_windows() immediately returns spawn EPERM again.

No runtime, plugin, ACL, application, or machine state changed between steps 1–3; only the task permission mode changed. This confirms that the ACL grant alone is insufficient and isolates the remaining failure to the normal Codex-managed sandbox/helper-spawn path. Full Access is a reliable per-task workaround, but normal permissions remain unusable for Computer Use.

Independent reproduction: Windows Computer Use spawn EPERM

Same environment as this issue, reproduced on Windows 11 x64.

Current environment

| Item | Value |
|---|---|
| OS | Windows 11 x64 |
| Codex Desktop | 26.803.5235.0 (Store/MSIX) |
| Computer Use plugin | 26.803.41515 |
| Bundled command runner | 0.147.0-alpha.6.5 |
| Bundled @oai/sky | 0.6.2 |
| Bundled @oai/cua | 0.1.1 |
| Bundled Node.js | 24.14.0 |
| Windows sandbox | unelevated (fallback) |

Failure position

The error happens before any window enumeration or app interaction:

Codex Desktop
  → bundled cua_node (Node.js)
    → @oai/sky
      → child_process.spawn("codex-computer-use.exe")   ← fails here
        → list_windows / helper communication (never reached)

const { sky } = await import("@oai/sky");
await sky.list_windows();   // Error: spawn EPERM

Reproduces in fresh tasks, after Codex restart, after Windows restart, and after reinstall. It is independent of the approval mode:

• Read-only: spawn EPERM
• Full access: spawn EPERM
• Request approval: spawn EPERM

Root cause hypothesis (evidence-based)

1. Windows sandbox child-process launch policy (primary). The shipped @oai/sky Windows transport (windows/internal/helper_transport.js) imports spawn from node:child_process and launches codex-computer-use.exe directly over stdio. Inside the managed sandbox this spawn is denied with EPERM. The helper exists, is signed by OpenAI, and works from an unsandboxed context, so the failing boundary is the sandbox launch policy / desktop bridge, not the helper binary.
2. Incomplete sandbox provisioning (secondary, machine-specific). CodexSandboxUsers has read/execute on the runtimes directory but not on parent paths (AppData\Local\OpenAI and OpenAI\Codex); CodexSandboxOnline exists without a user profile. Sandbox logs repeatedly show access-denied while handling C:\Users\Default. These explain EPERM lstat failures, but not the full behavior, because all three approval modes still fail with spawn EPERM.

What was checked (no changes made)

• codex-windows-sandbox-setup.exe exists under the MSIX package and has a valid OpenAI signature; sandbox log shows setup completed and read-ACL pass completed.
• codex-computer-use.exe exists in both the package resources and the user-local cua_node runtime.
• Package and user-local copies of Node and the helper have identical SHA-256 hashes; all relevant executables have valid OpenAI signatures.
• No matching AppLocker, Code Integrity, or Microsoft Defender block event found.
• SKY_CUA_NATIVE_PIPE is present in config, but the Windows @oai/sky transport still spawns the helper directly; I did not find a Windows native-pipe path being used by that transport.
• Control test: the same bundled runtime/helper can spawn cmd.exe and enumerate windows from an unsandboxed diagnostic context.

Suggested directions for the fix

1. Broker the Computer Use helper through the Desktop/native bridge, or explicitly allow the signed helper child process from the managed sandbox.
2. Provision real profiles for both Codex sandbox users.
3. Grant traversal/read access on every required parent directory, not only the deeper runtime directory.
4. Add a release test: import("@oai/sky") → list_windows() → get_window_state() → one harmless input, under both Windows sandbox modes.
5. Keep the skill documentation and @oai/sky API in sync; in this runtime sky.documentation is not exported even though the skill tells callers to use it.

Related reports: #37678, #37629, #37427, #37293, #37272 (older version), #21470.

I hope someone will be assigned to this soon. Losing Computer Use is a big problem! I don't want to have to run under Full Access to use it. That's too dangerous.

I hope someone will be assigned to this soon. Losing Computer Use is a big problem! I don't want to have to run under Full Access to use it. That's too dangerous.

Agree completely. Full Access is too risky to use as a workaround. Hope the team can fix this soon

Adding a sanitized confirmation from another Windows system and consolidating #37845 here.

The failure reproduces with:

• Codex Desktop MSIX 26.803.5235.0
• Computer Use plugin 26.803.41515
• @oai/sky 0.6.2
• Windows sandbox setting unelevated

Both lowest-risk discovery calls fail before returning any UI metadata:

sky.list_apps()    -> Error: spawn EPERM
sky.list_windows() -> Error: spawn EPERM
code=EPERM
errno=-4048
syscall=spawn

Additional evidence:

• The failure occurs in @oai/sky's Windows helper_transport.js at Node child_process.spawn(), before helper communication or window enumeration.
• The expected bundled codex-computer-use.exe exists, has a valid OpenAI Authenticode signature, and has executable ACLs for the relevant sandbox identity.
• The active runtime files are byte-identical to the copies embedded in the installed MSIX.
• No matching Code Integrity, AppLocker, or Defender block event was found.
• The Desktop-generated environment advertises SKY_CUA_NATIVE_PIPE and SKY_CUA_NATIVE_PIPE_DIRECTORY, but the bundled @oai/sky 0.6.2 JavaScript package does not reference those variables; its Windows transport unconditionally attempts to spawn the helper.
• sky.documentation is also absent from @oai/sky 0.6.2. Reading the complete static plugin guidance works around that documentation mismatch, but does not change spawn EPERM.
• Reinstalling the supported plugins, restarting Codex, testing fresh tasks, adding --disable-sandbox to the bundled Node REPL, and a controlled environment A/B did not change the error.
• Browser/Chrome discovery works in the same installation, isolating this symptom to Computer Use helper startup.

No helper was launched directly and no registry, manifest, ACL, plugin-cache, or Windows security setting was modified. Full Access is not being used as a workaround.

Update: the original Computer Use spawn EPERM failure is now resolved for me after the Codex Desktop app updated from 26.803.5235.0 to 26.803.10989.0.

Current versions:

• Codex Desktop: 26.803.10989.0
• Computer Use plugin: 26.803.81509
• bundled @oai/sky: 0.6.6

I compared the old and new bundled Computer Use runtimes. In @oai/sky 0.6.2, the Windows client attempted to spawn codex-computer-use.exe directly from the sandboxed Node runtime, which failed with spawn EPERM.

In @oai/sky 0.6.6, when SKY_CUA_NATIVE_PIPE=1, the client instead connects through nodeRepl.nativePipe.createConnection using SKY_CUA_NATIVE_PIPE_DIRECTORY. The Codex Desktop host owns the helper connection and approval flow, so Computer Use now works and the normal application approval UI can appear.

I had previously tested a temporary localhost bridge workaround, but that process is no longer running and the patched old runtime is no longer installed. The current successful behavior is therefore coming from the updated official bundle, not the workaround.

I have verified that the original Computer Use failure is fixed. I have not retested the separate elevated-sandbox WindowsApps ACL setup failure described in this issue.

This is an observation from comparing the locally installed old and new bundled runtimes, not an official confirmation of the implementation change from OpenAI.

I can confirm that computer use is now operational. Thank you!

I have a question regarding its use.

During the early part of my session I was able to use computer use to open
the Run Dialog. By the end of my session, I was unable to, and I received
the following response:

"I can’t automate the Windows Run dialog. Press Windows key + R to open
it."

Is this intentional?

Thanks again for the fix!

On Tue, Aug 11, 2026 at 2:08 AM noname @.***> wrote:

noname-176103741 left a comment (openai/codex#37415) <https://github.com/openai/codex/issues/37415#issuecomment-5251174976> Update: the original Computer Use spawn EPERM failure is now resolved for me after the Codex Desktop app updated from 26.803.5235.0 to 26.803.10989.0. Current versions: - Codex Desktop: 26.803.10989.0 - Computer Use plugin: 26.803.81509 - bundled @oai/sky: 0.6.6 I compared the old and new bundled Computer Use runtimes. In @oai/sky 0.6.2, the Windows client attempted to spawn codex-computer-use.exe directly from the sandboxed Node runtime, which failed with spawn EPERM. In @oai/sky 0.6.6, when SKY_CUA_NATIVE_PIPE=1, the client instead connects through nodeRepl.nativePipe.createConnection using SKY_CUA_NATIVE_PIPE_DIRECTORY. The Codex Desktop host owns the helper connection and approval flow, so Computer Use now works and the normal application approval UI can appear. I had previously tested a temporary localhost bridge workaround, but that process is no longer running and the patched old runtime is no longer installed. The current successful behavior is therefore coming from the updated official bundle, not the workaround. I have verified that the original Computer Use failure is fixed. I have not retested the separate elevated-sandbox WindowsApps ACL setup failure described in this issue. This is an observation from comparing the locally installed old and new bundled runtimes, not an official confirmation of the implementation change from OpenAI. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/37415?email_source=notifications&email_token=CC7YCFFGAA7KG5UVNDEUZDD5JLPALA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGEYTONBZG43KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5251174976>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CC7YCFBRJLX7M2ZSR72JUGL5JLPALAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMBYHA3DKOBVG442C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CC7YCFESPFMUIXAX4ORQCI35JLPALA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGEYTONBZG43KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CC7YCFFFGFQLTKMGKNJTRQ35JLPALA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGEYTONBZG43KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

Independent reproduction on a newer Codex build.

Environment:

• Codex App: OpenAI.Codex 26.803.10989.0 x64
• Windows: 25H2, build 26200.8973, x64
• Bundled Node: 24.14.0
• Sandbox: workspace-write / Windows unelevated

Observed:

From the Codex sandboxed Node REPL:

const { spawn } = require("child_process");
const p = spawn("C:\\Windows\\System32\\whoami.exe");

p.stdout.pipe(process.stdout);
p.stderr.pipe(process.stderr);

p.on("close", code => console.log("EXIT", code));
p.on("error", error => console.error("ERROR", error.code, error.message));

Result:

ERROR EPERM spawn EPERM

No stdout, stderr, or exit code is produced.

The same sandboxed context also fails to launch the bundled signed codex-computer-use.exe helper with spawn EPERM, before any application interaction occurs.

Control test outside Codex:

From ordinary non-administrator PowerShell, using installed Node:

& "C:\Program Files\nodejs\node.exe" -e "const {spawn}=require('child_process'); const p=spawn('C:\\Windows\\System32\\whoami.exe'); p.stdout.pipe(process.stdout); p.stderr.pipe(process.stderr); p.on('close',c=>console.log('EXIT',c)); p.on('error',e=>console.error('ERROR',e.code,e.message));"

Result:

<DOMAIN>\<USER>
EXIT 0

This strongly isolates the failure to the Codex sandboxed execution context rather than Windows or Node child-process creation generally.

Additional observations:

• The issue persists after updating Codex to 26.803.10989.0.
• Sandboxed REPL observed with a restricted token and Job Object membership.
• No matching Defender, AppLocker, Code Integrity, Application, or available Security log denial was found.
• Target application and Windows remained stable; no input reached the target application.

I can provide sanitized sandbox logs if a maintainer wants them.

Follow-up from my earlier reproduction: I consider the original issue resolved on the current build.

Working versions

• Codex Desktop: 26.803.10989.0
• Computer Use plugin: 26.803.81509
• Windows 11 Pro 25H2, build 26200.8973, x64

Under managed “approve for me” permissions, I reset the node_repl kernel and repeated the original smoke test:

• await sky.list_windows() succeeded and returned all 6 open windows.
• A separate await sky.list_apps() call also succeeded, returning 40 apps and 6 windows.
• The previous spawn EPERM did not recur.
• The separate-call execution-context failure seen with the older bundle did not recur either.

A subsequent get_window_state() attempt reached the Computer Use helper normally and declined only because the selected File Explorer window was minimized, not because of sandbox permissions.

So, on this machine, the normal managed-permissions Computer Use launch path is fixed as of Codex Desktop build 26.803.10989.0 / plugin 26.803.81509. Full Access is no longer required for the original failure.

Confirmed regression on the same Windows installation:

• Fails: Codex Desktop 26.803.5235.0 — the first read-only sky.list_apps() call fails before app/window selection with spawn EPERM (errno -4048).
• Works after downgrade: 26.727.6591.0 — sky.list_apps() succeeds and returns the available apps/windows.

The affected runtime was replaced during the clean downgrade; the working runtime is different. This strongly indicates an app/runtime regression rather than a project or target-application issue.

In-app feedback ID: 019febfa-08c6-76d1-baca-deea04f9be92

No project data, chats, paths, credentials, or screenshots are included.