[Windows] Computer Use surface is incorrectly gated to Darwin, leaving @oai/sky unregistered

Environment

OS: Microsoft Windows NT 10.0.19045.0 x64
Codex Appx: 26.901.6511.0
Bundled/plugin version: 26.901.51231
@oai/sky: 0.6.26
@oai/cua: 0.2.4
@oai/browser-desktop: 0.1.1

Summary

The Windows Computer Use backend appears to be present and functional, but the Codex main-process CUA surface-selection logic excludes the computer surface because of a Darwin-only platform gate.

As a result, normal startup produces:

CUA_REPL_ENABLED_SURFACES="browser"

The unified-computer-use runtime then starts with:

browser=true
computer=false

Consequently, the sky Trusted RPC service is not registered.

Minimal reproduction

Start Codex normally on Windows.
Inspect the active CUA runtime state:

await cua.getState();

Observed:

apps: []
browsers: 3

Import and call the Windows Computer Use API:

const { sky } = await import("@oai/sky");

await sky.list_apps();
await sky.list_windows();

Both calls fail with:

Error: Trusted RPC service is not configured: sky

Expected behavior

When the Computer Use feature is enabled and the Windows native backend is available, the computer surface should be included in the CUA surface list.

The runtime should receive:

CUA_REPL_ENABLED_SURFACES="browser,computer"

and initialize with:

browser=true
computer=true

The Trusted RPC mapping should then include:

browser -> @oai/browser-desktop/service
sky     -> @oai/sky/service

Actual behavior

Read-only inspection of the Codex main-process bundle found selector logic equivalent to:

let computerSurfaceEligible =
  browserEligible &&
  runtimePaths.platform === "darwin" &&
  features.computerUse &&
  computerUsePaths.enabled &&
  computerUsePaths.serviceAppPath != null;

let surfaces = [];

if (browserEligible && browserBackends.length > 0) {
  surfaces.push("browser");
}

if (computerSurfaceEligible) {
  surfaces.push("computer");
}

On this Windows system:

runtimePaths.platform = "win32"

Therefore the platform condition evaluates false and the selected surfaces are:

["browser"]

The .mcp.json writer then stores:

CUA_REPL_ENABLED_SURFACES="browser"

unified-computer-use/scripts/launch.mjs consequently derives:

browser=true
computer=false

and does not register:

sky -> @oai/sky/service

Diagnostic evidence

The following backend components were verified to exist and initialize:

@oai/sky package
@oai/sky/service
Windows codex-computer-use.exe
Windows native helper
Native named pipe
Native pipe startup reported startup ready
Materialized Computer Use plugin files
Bundled unified-computer-use runtime

The third-party browser-use/browser-harness Skill was also checked. It does not register or override sky and does not participate in NODE_REPL_TRUSTED_SERVICES.

Decisive isolated A/B experiment

No app.asar, feature flag, active .mcp.json, system environment variable, registry entry, cache, or third-party plugin was modified.

A separate fresh CUA child was started with the following environment variable set before process creation:

CUA_REPL_ENABLED_SURFACES=browser,computer

The fresh child actually reported:

setupOptions.browser=true
setupOptions.computer=true

Its Trusted RPC mapping included:

browser -> @oai/browser-desktop/service
sky     -> @oai/sky/service

The following calls then succeeded:

await sky.list_apps();
await sky.list_windows();

list_apps() successfully enumerated existing Windows applications, including Microsoft Edge, ChatGPT, Explorer, Chrome, Blender, Task Manager, Photoshop, OBS, and others.

list_windows() successfully enumerated the current Windows windows.

This confirms that, when the computer surface is enabled:

Windows @oai/sky backend: working
Windows native helper: working
Native pipe: working
Trusted RPC sky service: working

The isolated child was subsequently terminated.

The active .mcp.json remained unchanged. Its SHA256 before and after the experiment was identical:

E00CE9939E26DA8C5958F21B94F23575AF8976FF374765AE0B5EA1F3484F963F

No persistent environment variables were changed.

Why this is likely not an installation or environment issue

The same installed Windows backend, native helper, named pipe, and @oai/sky package successfully handled both list_apps() and list_windows() in a fresh child process when browser,computer was supplied before launch.

The failure occurs only in the normal Codex startup path, where the main process selects:

CUA_REPL_ENABLED_SURFACES="browser"

before unified-computer-use is launched.

The evidence suggests that the main-process CUA surface-selection logic is gating the computer surface to Darwin, even though the Windows Computer Use backend is present and functional.

Request for investigation

Please inspect the main-process CUA surface-selection path, especially:

cuaReplSurfaces
Windows computerUseNodeRepl path
platform gating around the computer surface
CUA_REPL_ENABLED_SURFACES generation

The intended fix is not asserted here; the request is to verify whether the Windows surface-selection logic is incorrectly constrained by the Darwin platform check.

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

[Windows 26.901.51231] unified-computer-use materialization sets CUA_REPL_ENABLED_SURFACES=browser, stripping sky trusted RPC #43498
Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only #42745
Computer Use shows no native Windows apps #43465

Powered by Codex Action

Additional confirmation from the affected Windows installation: after a full Codex restart with CUA_REPL_ENABLED_SURFACES=browser,computer present in the parent process environment, fresh Codex tasks still reported apps: [] with Chrome/in-app-browser surfaces available but no native apps. The internally managed CUA child was still launched browser-only.

This reproduced in two fresh tasks after the restart. It also clarifies that the isolated-child A/B described above is a useful root-cause diagnostic, but is not a working full-Codex workaround: the normal main-process/managed-child startup path still selects or rewrites the surface set to browser-only.

I found a working workaround on the affected Windows installation for this issue.

Verified workaround

Rename the bundled Computer Use skill file so Codex does not load it:

Rename-Item "$env:USERPROFILE\.codex\skills\computer-use\skill.md" skill.md.bak

After doing this and starting a fresh Codex task, Computer Use began working normally again on Windows. This is different from the earlier CUA_REPL_ENABLED_SURFACES=browser,computer experiment: setting that environment variable in the parent process did not fix normal Codex startup, while renaming skill.md did.

So, at least on this affected installation, the failure appears to involve the loaded computer-use skill path/configuration in addition to (or interacting with) the Windows CUA startup behavior described in the issue.

This is only a workaround, not a proposed upstream fix. When an official Codex/Computer Use fix ships, the workaround should be removed/restored so it does not mask or conflict with the updated bundled skill. The rollback is simply the reverse rename, e.g.:

Rename-Item "$env:USERPROFILE\.codex\skills\computer-use\skill.md.bak" skill.md

For anyone still blocked by native Windows Computer Use, this workaround has been verified to restore functionality on one affected system.

Additional Windows reproduction on Codex AppX 26.908.4834.0, with computer-use and unified-computer-use plugin version 26.908.40834.

Observed during troubleshooting:

Codex is installed under C:\Program Files\WindowsApps. The default AppX volume is also the system C: volume. The user configuration and local runtime directories are on C: and are not directory symlinks/junctions.
Desktop startup logs report Windows helper components resolved, then computer-use native pipe startup ready with platform=win32.
Removing and reinstalling the official Computer Use plugin completed with plugin_install_succeeded ... pluginName=computer-use.
Nevertheless, repeated cua.getState() checks in the affected conversation return apps: [] and only the Codex In-app Browser.
The generated unified-computer-use .mcp.json still contains CUA_REPL_ENABLED_SURFACES=browser and NODE_REPL_TRUSTED_SERVICES={"browser":"@oai/browser-desktop/service"} (no sky mapping).

The successful native-pipe startup occurred before the plugin reinstall; the same Desktop process remained running afterward. Earlier Desktop restarts/new-conversation attempts had also been reported unsuccessful, but this is not a controlled clean-profile reproduction. Native-pipe readiness alone does not prove end-to-end desktop automation works.

Environment caveat: this installation uses a scoped proxy launcher and has undergone local troubleshooting (including proxy-environment changes in the CUA launcher and disabling third-party account-switcher takeover/UI injection). Therefore these observations should not be treated as proof of a single upstream cause. No forced native-surface registration or platform-gate workaround is being proposed here.

Could maintainers clarify whether Windows native Computer Use is expected through the unified CUA path or a separate node_repl path in this build, and why a ready Windows native pipe plus successfully installed plugin can still leave the conversation browser-only? Sanitized diagnostic summary only; no credentials, account identifiers, full logs, or private conversation content are attached.

Still reproducible on Codex 26.908.40834 / Windows 10 22H2.

I can confirm that this issue still occurs on a newer Codex build.

Environment

Windows 10 Pro 22H2
OS version: 10.0.19045.7725
Codex / Computer Use plugin: 26.908.40834
@oai/cua: 0.2.4
@oai/sky: 0.6.32
@oai/cua-repl: 0.1.0
Node runtime: 24.20.0

UI configuration

Computer Use enabled
"Any App" enabled
Browser Use works normally

Observed behavior

cua.initialize() / cua.getState() returns:

apps: []
browsers: 2

The two browsers are Chrome and the Codex in-app browser.

Both native Sky calls fail with:

Trusted RPC service is not configured: sky

for:

sky.list_apps()
sky.list_windows()

Runtime configuration

The normal installed/runtime environment contains:

NODE_REPL_TRUSTED_SERVICES={"browser":"@oai/browser-desktop/service"}

There is no:

sky -> @oai/sky/service

mapping.

I verified that:

@oai/sky/service is installed
its resolved service.js exists
it is physically contained inside NODE_REPL_TRUSTED_CODE_PATHS
the Windows Computer Use binaries are installed
codex-computer-use-swift.exe is running
the native Computer Use named pipe exists
Browser Use continues to work

The resolved Sky service is under:

...\node_modules\@oai\sky\dist\project\cua\sky_js\src\service.js

and is inside the configured trusted module path.

Additional isolated diagnostic

I also tested a temporary child process with:

CUA_REPL_ENABLED_SURFACES=browser,computer

and it reported:

browser=true
computer=true

However, my isolated child experiments were not able to complete sky.list_apps() because reproducing the full trusted RPC / node_repl bootstrap outside the normal Codex startup path was unsuccessful.

Therefore I am not claiming that the isolated test independently proves that the native Sky backend works on my installation.

The relevant reproduction is that the normal Codex startup on 26.908.40834 still omits Sky from NODE_REPL_TRUSTED_SERVICES, returns apps=[], and exposes only browser surfaces despite Computer Use + Any App being enabled.

This appears consistent with the surface-selection / Sky registration issue described here.

I can provide additional read-only diagnostics if useful.

Additional Windows reproduction on Codex Desktop 26.908.9136.0 / unified-computer-use 26.908.70816 (2026-09-15). Computer Use is enabled, but await cua.getState() returns apps: [] while browser surfaces work. The installed bundled .mcp.json initially contains CUA_REPL_ENABLED_SURFACES: "browser" and NODE_REPL_TRUSTED_SERVICES contains only the browser service. I changed that value to browser,computer, restarted Codex, and it was automatically rewritten back to browser; the native app inventory remained empty. The plugin/runtime files and Windows helper are present. Please investigate why the Windows startup path selects or rewrites the surface list to browser-only, and why the runtime documentation advertises getApp/listApps while the actual cua object in this session has neither function. No credentials or private files are included.

Additional Windows reproduction from Codex Desktop build/plugin 26.908.70816 (2026-09-16). This closely matches the issue and adds session/approval evidence.

Observed normal Codex session:

browser Computer Use works
apps: []
cua.getApp / cua.listApps are not exposed
active unified-computer-use .mcp.json materializes CUA_REPL_ENABLED_SURFACES="browser"
full Codex restart, CUA helper restart, and changing selected models (including GPT-6 Astra) did not restore native app access

Backend isolation:

Windows @oai/sky bridge is functional
native named pipe exists and responds
isolated sky.list_apps() returns real Windows applications
isolated sky.list_windows() sees a running native application window (FORGE PERSONAL, version 1.2.95)
therefore the Windows native backend/helper/pipe and native-window enumeration are working

Controlled reversible cache test:

backed up active .mcp.json
changed only CUA_REPL_ENABLED_SURFACES from browser to browser,computer
restarted one CUA/cua-repl worker
active chat remained apps: []; getApp/listApps remained unavailable
restored original file; SHA-256 matched the backup afterward

Approval/elicitation finding:

the isolated @oai/sky process can enumerate the native app/window but screenshot correctly stops with Computer Use requires app approval but elicitations are unavailable
read-only runtime inspection indicates standard Codex node_repl host supplies nodeRepl.createElicitation(...); the isolated create_client({target:"windows"}) process lacks that host RPC/request metadata
no attempt was made to bypass or auto-approve Computer Use approval

This suggests two distinct pieces are healthy (Windows native Sky backend and native pipe) while the active Codex CUA session/facade is not registering/exposing the Windows computer surface and its legitimate elicitation binding. A post-materialization .mcp.json edit is not sufficient for an already-created session.

No FORGE files, Codex binaries, runtime binaries, or persistent environment variables were modified. This regression was noticed immediately after a Codex Desktop update; native Windows Computer Use had been working on the same machine before that update.

Please consider checking the Windows CUA session/facade registration path in addition to .mcp.json generation, including when the computer surface and trusted sky service are bound to the Codex node_repl elicitation channel.

One additional timeline detail that may help distinguish a pure CUA regression from an updater/materialization race:

On the affected machine, native Windows Computer Use was working normally immediately before an in-app Codex Desktop update. The user clicked the update; Codex shut itself down, but there was no visible update-progress UI and the client did not automatically relaunch. Because there was no indication whether background update work had completed, the user manually launched Codex again. The browser-only native-CUA failure was observed after that update/relaunch cycle.

We cannot establish that the manual relaunch occurred before the updater had fully completed, so this should not be treated as the proven cause. However, it may be worth checking whether plugin/runtime materialization or CUA capability registration can race with an in-progress update/relaunch, and whether an interrupted/incomplete post-update initialization can leave the unified-computer-use session materialized as browser-only.

Separately, the updater UX gave no progress/completion/relaunch indication after shutting down the client. Even if unrelated to this CUA regression, an explicit update progress/completion state or automatic relaunch could prevent ambiguous partial-update states and make similar regressions easier to diagnose.

Product/update UX suggestion based on this regression: please consider providing a supported user-facing rollback option for Codex Desktop updates.

For example, Settings > Updates could retain the immediately previous known-good Desktop/runtime/plugin bundle and offer Revert to previous version when a new update causes a regression. Ideally this would be an atomic rollback of the compatible app + runtime/plugin set, with the option to pause re-installation of the problematic update until a newer build is available.

This would be especially useful for Computer Use regressions, where a new build can block workflows that were working immediately before the update. It would also be safer than users manually downgrading AppX/MSIX packages or mixing app/runtime/plugin versions.

Related updater UX improvements that would help:

visible update progress after the client shuts down;
explicit Update complete state;
automatic relaunch, or a clear Safe to relaunch indication;
current and previous build numbers visible to the user;
a supported one-click rollback to the last known-good version.

In this case the previous version had working Windows native Computer Use, while the post-update session became browser-only. A supported rollback mechanism would have allowed immediate recovery while preserving a clean diagnostic path for the regression.

We now have the exact Windows Desktop update boundary from read-only AppX deployment history:

Last known-good Codex Desktop build: 26.908.4834.0 — Windows native Computer Use was working before the update.
Current/problematic build: 26.908.9136.0.
AppX update recorded: 2026-09-16 02:57:37 local time.
After the update, the active CUA session is browser-only (apps: []; native app access unavailable), while the isolated Windows @oai/sky bridge can still enumerate native Windows apps/windows.

The previous AppX path was recorded as:
C:\Program Files\WindowsApps\OpenAI.Codex_26.908.4834.0_x64__2p2nqsd0c76g0

Windows package history indicates that previous package was moved under WindowsApps\Deleted\... and deletion was attempted. No complete previous installer/MSIX or matching old runtime/plugin bundle remains locally, so we are not attempting an unsupported manual rollback.

This gives a relatively narrow regression window: 26.908.4834.0 -> 26.908.9136.0. If possible, please diff Windows CUA surface/session registration, unified-computer-use plugin materialization, and trusted Sky/node_repl elicitation binding across these builds.

Additional intermittent/session-dependent behavior observed on the same Windows setup:

A newly created Codex chat/session last night was able to see native Windows Computer Use / FORGE PERSONAL, but a newly created chat/session today fails again with:

cua.getState() -> apps: []
cua.listApps -> cua.listApps is not a function
FORGE PERSONAL cannot be visually confirmed through the active CUA surface.

No system, FORGE, runtime, cache, plugin, or configuration changes were made during this latest check.

This is important because it suggests the post-update build may not be permanently incapable of native Windows CUA. Native capability appears to have been successfully registered in at least one fresh session and then unavailable again in another fresh session. That may point to intermittent/session-dependent capability registration, initialization, feature materialization, or trusted Sky/node_repl binding rather than a consistently broken Windows backend.

Please consider checking differences in session bootstrap/capability registration when a fresh chat is created, including why one session can receive the native computer surface while another receives browser-only CUA on the same installation.

More precise timeline from the intermittent reproduction: this occurred in a NEW Codex chat/session created that morning, not an old chat carried across the update.

At ~06:30 the new chat explicitly reported: Computer Use is ready. There are currently no open desktop applications. This indicates that Computer Use was surfaced/available to that fresh chat at session start.

Later in the SAME fresh chat/session, while the user could visibly see FORGE PERSONAL open on the Windows desktop, Codex could no longer discover/control it and reported apps: []. The user therefore had a native FORGE window visibly open, while the CUA channel claimed there were no discoverable native apps/windows.

No FORGE/runtime/cache/plugin/config changes were made to intentionally cause that transition.

This strengthens the possibility of a session-lifetime/bootstrap/registration problem: a fresh chat can initially expose Computer Use, yet native Windows app discovery can subsequently be unavailable in that same session. Please check whether the native computer surface / Sky service / approval binding can be lost or fail to complete after initial session bootstrap, rather than assuming this only affects chats created before an update.

Still reproducible on Codex Desktop 26.915.4065.0

I can confirm that this issue is still present in the current Windows Codex Desktop package.

Codex Desktop: 26.915.4065.0
Platform: Windows

The failure is still in the main-process Computer Use surface-generation path rather than in the Windows native runtime itself.

Current observed behavior

A live probe of the current Computer Use session exposes only the browser surface.

The following Windows Computer Use API objects are not registered:

computer   -> missing
listApps   -> missing
getApp     -> missing

There are also no injected Windows cua.computer.* usage instructions in the active session.

As a result, the session cannot enumerate, launch, or control native Windows applications such as Calculator or IntelliJ IDEA.

Root cause in 26.915.4065.0

Read-only inspection of the currently installed package identifies the relevant main-process bundle as:

app.asar/.vite/build/main-LM8MUIFp.js

The current build still contains two Darwin-specific checks.

The Windows feature path is capable of starting the native pipe and helper runtime, but the So() surface-generation path still computes computerSurfaceEnabled using a condition equivalent to:

runtimePaths.platform === "darwin"

On Windows:

runtimePaths.platform === "win32"

so the condition is always false.

The resulting path is:

server-side computerUse = true
        |
Windows native pipe/helper runtime starts successfully
        |
So()
        |
computerSurfaceEnabled = false
because platform !== "darwin"
        |
CUA_REPL_ENABLED_SURFACES = "browser"
        |
@oai/cua-repl does not register @oai/sky/service
        |
create_tinysky_alt({ computer: false })
        |
computer / listApps / Windows getApp are never registered

This explains why forcing:

computerUse=true
computerUseNodeRepl=true

does not fix the issue.

Those flags can enable the REPL/runtime path, but they cannot make the original Windows surface-selection expression produce the "computer" surface.

Native runtime is not the blocker

The important distinction is that this does not appear to be a Windows native runtime startup failure.

The Windows feature path can successfully initialize the native pipe and helper runtime.

The failure occurs later when the main process generates the enabled CUA surfaces.

Therefore the current behavior is effectively:

Native Windows Computer Use runtime: available
Computer Use feature: enabled
CUA REPL: available
Browser surface: registered
Computer surface: incorrectly excluded

Patch dry-run result

I also performed a non-destructive dry-run against the installed app.asar.

The OnlyComputerUseSurface patch logic:

located exactly one Windows surface-gating target in the current bundle;
generated the expected patched JavaScript;
passed JavaScript syntax validation;
did not modify the installed package.

The installed MSIX / app.asar remains unchanged.

This provides additional evidence that the remaining Darwin-only surface condition is the direct blocker in 26.915.4065.0.

Expected behavior

When Windows Computer Use is enabled and its native runtime is available, the surface-selection path should allow:

CUA_REPL_ENABLED_SURFACES="browser,computer"

so that @oai/cua-repl registers the Windows Computer Use service and exposes:

computer
listApps
getApp

Conclusion

The issue originally reported here remains reproducible in Codex Desktop 26.915.4065.0.

The current evidence points specifically to a client-side surface-generation/platform-gating omission rather than:

account entitlement;
server-side computerUse feature state;
computerUseNodeRepl;
native pipe startup;
Windows helper runtime availability;
application discovery;
application-specific permissions.

The remaining blocker is that the normal Windows startup path still cannot generate the "computer" surface while the surface eligibility condition remains Darwin-only.

Additional upgrade-regression confirmation on Windows:

On 2026-09-21, native Computer Use worked on the same machine with bundled computer-use package 26.915.31945. Codex successfully used @oai/sky / sky.list_apps(), discovered QQ Music, and interacted with its native UI.
After updating to bundled package 26.917.62051 on 2026-09-24, native applications stopped being exposed.
In fresh tasks after a full restart, with Computer Use and Any App enabled and Telegram Desktop visible:
- await cua.getState() returns apps: [], while the browser surface is present.
- cua.listWindows, cua.listApps, cua.getApp, and cua.launchApp are all undefined.
- Browser control continues to work normally.
The issue reproduces regardless of which client creates the conversation.
There is no requirements.toml override and no computer_use disable entry in config.toml.

This is a before/after reproduction on the same Windows machine. It appears consistent with the normal Windows startup path selecting a browser-only surface and failing to register the native sky service.

The regression window appears to be between 26.915.31945 and 26.917.62051.

Navigation Menu

Repository navigation

[Windows] Computer Use surface is incorrectly gated to Darwin, leaving @oai/sky unregistered #43594

Environment

Summary

Minimal reproduction

Expected behavior

Actual behavior

Diagnostic evidence

Decisive isolated A/B experiment

Why this is likely not an installation or environment issue

Request for investigation

Verified workaround

Environment

UI configuration

Observed behavior

Runtime configuration

Additional isolated diagnostic

Still reproducible on Codex Desktop 26.915.4065.0

Current observed behavior

Root cause in 26.915.4065.0

Native runtime is not the blocker

Patch dry-run result

Expected behavior

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows] Computer Use surface is incorrectly gated to Darwin, leaving @oai/sky unregistered #43594

Description

Environment

Summary

Minimal reproduction

Expected behavior

Actual behavior

Diagnostic evidence

Decisive isolated A/B experiment

Why this is likely not an installation or environment issue

Request for investigation

Activity

github-actions commented on Sep 7, 2026

cezaronx commented on Sep 8, 2026

AIR55745 commented on Sep 10, 2026

Verified workaround

qiuiu727 commented on Sep 13, 2026

gonzalo-izquierdo commented on Sep 14, 2026

Environment

UI configuration

Observed behavior

Runtime configuration

Additional isolated diagnostic

park12347789 commented on Sep 15, 2026

cybermikan commented on Sep 16, 2026

cybermikan commented on Sep 16, 2026

cybermikan commented on Sep 16, 2026

cybermikan commented on Sep 16, 2026

cybermikan commented on Sep 16, 2026

cybermikan commented on Sep 16, 2026

somethingaw commented on Sep 22, 2026

Still reproducible on Codex Desktop 26.915.4065.0

Current observed behavior

Root cause in 26.915.4065.0

Native runtime is not the blocker

Patch dry-run result

Expected behavior

Conclusion

awkwardss commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions