Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only

@computer

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.4073.0 (Computer Use plugin: 26.901.31953)

What subscription do you have?

ChatGPT plan (exact tier unavailable)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Computer Use on Windows cannot enumerate native apps. @computer reports apps: [], and a direct @oai/sky call fails with: Trusted RPC service is not configured: sky. Browser Use continues to work.

What steps can reproduce the bug?

Install/enable computer-use and unified-computer-use on Windows.
Start a Codex desktop task using @Computer.
Call await cua.getState() or import @oai/sky and call await sky.list_apps().

Observed:

cua.getState() returns apps: [].
sky.list_apps() returns Trusted RPC service is not configured: sky.

Local inspection shows the unified launcher receives CUA_REPL_ENABLED_SURFACES=browser. Its trusted-service configuration then contains only browser and deliberately excludes sky; the launcher starts sky only when the computer surface is enabled.

Tried: Codex reinstall/update, full restart, verifying bundled Node/node_repl paths, and recreating plugin latest junctions. The issue persists. A local cache edit is regenerated by Codex and does not change the already running direct node_repl session.

What is the expected behavior?

With @Computer, Windows native-app enumeration should start the trusted sky service and return the installed/running apps.

Additional information

No logs, screenshots, local paths, account details, or project data are attached. This looks like an app-level surface-selection or trusted-service configuration bug, rather than a corrupt bundled runtime.

Additional diagnostic details:

First observed on Codex 26.901.2854.0 / Computer Use plugin 26.901.22334; still reproducible after updating to the versions above.
Bundled CUA runtime revision: c2900163265bdaec; bundled node and node_repl paths exist and node reports v24.19.0.
codex-computer-use.exe is present but no corresponding process is started.
The desktop app runs unelevated.
Both computer-use and unified-computer-use are enabled.

Confirmed on a newer Windows Desktop build, with a successful workaround that isolates the failure to surface selection rather than the native helper.

Environment:

ChatGPT Desktop internal release: 26.901.41600
AppX package version observed: 26.901.5280.0
Windows 11 Pro, build 10.0.26200
Computer Use plugin enabled
Any-app computer control enabled
Browser surface works

Before workaround:

Generated CUA_REPL_ENABLED_SURFACES=browser
cua.getState() returned apps: []
sky.list_apps() failed with Trusted RPC service is not configured: sky
Windows native pipe already existed and accepted connections
@oai/sky Windows helper files were present and Authenticode-valid

Workaround tested:

Change the active unified-computer-use cache config field mcpServers.cua_repl.env.CUA_REPL_ENABLED_SURFACES from browser to browser,computer.
Restart the corresponding CUA launch runtime so the Desktop app-server recreates it.

After workaround:

@oai/sky/service is configured
sky.list_apps() returns Windows native apps (40 apps in this test)
cua.getState() returns the native app list
Native smoke tests passed for Windows Notepad and QQ Music
Browser surface remains available

This strongly suggests the Windows native helper/pipe deployment is healthy and the regression is in Desktop surface selection/config generation. Local inspection also found the computer surface addition on a darwin-specific code path in the packaged app, which is consistent with Windows being left browser-only.

One remaining quirk: the higher-level cua.getApp()/cua.listApps() binding can still report Native app bindings are unavailable for windows, while the same runtime's sky native path works and can successfully control native Windows apps.

A useful regression test would be: on win32 with Computer Use enabled, assert the generated surfaces contain computer, verify the sky trusted service is injected, then enumerate apps and launch Notepad.

Additional independent confirmation from a Windows reproduction:

The generated unified Computer Use configuration set CUA_REPL_ENABLED_SURFACES=browser.
The exposed cua object did not define getApp or listApps.
Before trusted bootstrap, importing or calling @oai/sky failed with Trusted RPC service is not configured: sky.
After initializing the trusted node_repl runtime with @oai/sky, sky.list_apps() and sky.list_windows() returned the native Windows application inventory.
Native window inspection and a smoke test against Antigravity then succeeded through the sky path.

This isolates the failure to the exposed capability contract and generated surface configuration rather than to the Windows UI Automation helper itself.

The suggested regression coverage is:

On Windows with native Computer Use enabled, assert that the generated surface set includes computer.
Assert that the trusted sky service is injected when the native surface is enabled.
Enumerate native applications and windows through the supported runtime.
Either implement and test the advertised cua.getApp and cua.listApps bindings, or remove those methods from the exposed API documentation and provide an actionable fallback to the supported sky path.

The local browser to browser,computer configuration change is a useful diagnostic workaround, but it is regenerated by the desktop application and should not be treated as the permanent fix.

I can reproduce this issue on Windows.

Observed behavior:

cua.getState() returns apps: [].
sky.list_apps() fails with:
Trusted RPC service is not configured: sky
Chrome Browser Use continues to work.
Native Windows applications such as Notepad cannot be discovered or controlled.

Computer Use plugin version visible in the local installation:
26.901.51231

I have already restarted the desktop app, signed out and back in, confirmed that the Computer Use plugin and “Any App” access are enabled, and reproduced the problem in a new task.

This appears to be the same browser-only surface / missing trusted sky service problem described in this issue.

macOS: fixed “Trusted RPC service is not configured: sky” by correcting a stale bundled-plugin marketplace path

I encountered this error when trying to use Computer in Codex Desktop:

Trusted RPC service is not configured: sky

The Computer plugin was installed and enabled, and its native helper started successfully. The error occurred in both an existing project task and a fresh projectless task.

Root cause found on my installation

My ~/.codex/config.toml still registered the bundled marketplace at an older application path:

[marketplaces.openai-bundled]
source_type = "local"
source = "/Applications/Codex.app/Contents/Resources/plugins/openai-bundled"

The running application was /Applications/ChatGPT.app. It was trying to register its generated bundled marketplace at a different location, but the existing registration prevented that.

The desktop logs repeatedly contained:

marketplace 'openai-bundled' is already added from a different source;
remove it before adding this source

Related log events included:

plugin_marketplace_add_failed
bundled_plugins_marketplace_add_failed
bundled_plugins_reconcile_failed

The old directory still existed, so simply checking whether the configured path existed would not have detected the problem.

What fixed the missing service connection

Backed up ~/.codex/config.toml.
Changed only the source under [marketplaces.openai-bundled] to the exact marketplace path requested by the current application in its logs. On my installation, that was:
```
source = "/Users/<username>/.codex/.tmp/bundled-marketplaces/openai-bundled"
```
Left the configuration writable.
Fully quit and reopened the desktop application.

Use the path from your own logs rather than assuming the example above applies to every installation.

Verification

Before the change, a fresh read-only plugin/list query did not return the bundled marketplace.

After the change, the same query returned the marketplace and reported Computer as:

installed: true
enabled: true
availability: AVAILABLE

After restarting the desktop application, Computer successfully retrieved an app's live accessibility tree and screenshot. The missing-sky error was gone.

What did not work

Manually adding sky to NODE_REPL_TRUSTED_SERVICES in the global configuration did not solve the underlying problem. Codex regenerated that configuration.

Making the file immutable with chflags uchg preserved the entry on disk, but the task’s runtime still lacked sky. I removed the immutable flag before correcting the marketplace registration:

chflags nouchg "$HOME/.codex/config.toml"

Scope of the result

This fixed the missing service connection on my Mac; it is not a universal fix for every sky error. A subsequent click in Visual Paradigm failed with the separate error noWindowsAvailable, even though reading its window state and screenshot worked.

If you see the missing-sky error, check for a bundled marketplace source conflict in the desktop logs before repeatedly reinstalling plugins or modifying runtime trust settings.

Reproduced on Windows with app package 26.903.8094.0 and unified-computer-use plugin 26.903.61454.

I found a working alternative in the same failing conversation: the callable tool inventory contained mcp__node_repl__js, although the agent had been using cua_repl.

Through cua_repl, sky.list_apps() failed with Trusted RPC service is not configured: sky.
Through trusted node_repl, importing @oai/sky and calling sky.list_apps() succeeded. Native screenshots and a click also worked, with normal user approval.

The prompt that worked was:

Use the computer-use skill for native Windows automation through trusted node_repl and @oai/sky, not cua_repl. If node_repl is not directly visible, inspect the callable tool inventory for mcp__node_repl__js and invoke it. Follow the skill’s initialization, observation, input, and approval rules.

Earlier manual configuration edits did not fix the running cua_repl instance and were overwritten on app restart. Their effect on the separate trusted tool’s availability was not isolated.

Related: #43498 and this workaround comment on #42214

Could diagnostics or tool discovery make this available native route visible to the agent instead of concluding that Computer Use is unavailable?

Additional isolation from Windows 10 build 19045, Codex app 26.908.4834.0, Computer Use 26.908.40834, and CLI 0.154.0-alpha.6.2:

The unified cua_repl path still reproduces this issue: cua.getState() returns apps: [] and only the browser surface.
A separate trusted node_repl path successfully imports @oai/sky; sky.list_apps() then enumerates native Windows applications.
That working path became available only after changing [features] js_repl = true while Codex was fully closed and restarting the app. Repairing/reinstalling the Computer Use plugin and toggling Any App had left the flag set to false.
codex features list still reports js_repl removed false, even though the raw config contains true and the trusted runtime works.

This supports the browser-only surface diagnosis here, while also showing a second gating problem: the usable trusted node_repl fallback can be hidden by the desktop-managed js_repl = false setting. Full reproduction details and the initial workaround report are in #43596, particularly this comment.

Additional reproduction on Windows with Codex app 26.908.4834.0:

Standard uninstall/reinstall of the desktop app did not restore native Computer Use.
The issue reproduces in a completely new local task after reinstall.
Browser control remains available, but the Windows native app list is empty.
Local diagnostics show the Computer Use helper and Windows native pipe reach startup ready.
In the fresh task initialization logs, there is no recorded sky trusted-RPC registration or native-app capability exposure.
A direct @oai/sky call then fails immediately with:

Trusted RPC service is not configured: sky

This further reduces the likelihood of a broken helper/pipe installation and is consistent with the failure occurring between task capability/surface setup and trusted-RPC registration.

The available logs do not contain the capability response body, so they cannot distinguish whether the native capability was never provisioned to the task or was lost before sky registration.

One additional timeline detail from the same Windows reproduction, sanitized to include only the behavior change:

On 2026-09-11, native Windows Computer Use was still partially available: native applications could still be enumerated/launched, although screenshot/coordinate-driven interaction was unstable and browser initialization could also fail.
On 2026-09-12, after the desktop/runtime update, native app exposure disappeared entirely in fresh tasks: the native app list is empty and @oai/sky immediately fails with Trusted RPC service is not configured: sky, while browser control remains available.

This does not prove both days share the same root cause, but it shows a clear degradation from partially working native Computer Use to complete loss of the native surface across consecutive days. The failure also persists after a standard reinstall and in a brand-new local task.

I found a working workaround on Windows.

The root cause appears to be that @Computer was being routed through the browser-only unified-computer-use / cua_repl surface. That surface did not register the native sky RPC service, which caused:

Trusted RPC service is not configured: sky
cua.getApp is not a function

The persistent fix was made in:

%USERPROFILE%\.codex\config.toml

On my system, this is:

C:\Users\rick\.codex\config.toml

The following sections were changed in that file:

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

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

[features]
js_repl = true

[mcp_servers.cua_repl]
enabled = false

The native node_repl configuration was also added/updated in the same file:

[mcp_servers.node_repl]
command = "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\<runtime>\\bin\\node_repl.exe"

[mcp_servers.node_repl.env]
NODE_REPL_TRUSTED_SERVICES = '{"browser":"...","sky":"@oai/sky/service"}'
SKY_CUA_NATIVE_PIPE = "1"

After restarting Codex, @Computer list the opened apps worked and returned the running Windows applications. The native backend was also verified directly through @oai/sky.list_apps().

I also tested modifying these generated files:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\26.911.61220\.mcp.json

and:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\unified-computer-use\.mcp.json

However, Codex regenerated those files with the browser-only configuration. Therefore, those cache/template edits were not the durable fix. The important change was disabling the incorrect unified-computer-use routing in %USERPROFILE%\.codex\config.toml and allowing Computer Use to use node_repl + @oai/sky.

Independent current verification on Windows (Codex desktop/runtime 26.915.31029):

The browser-only CUA route still fails with: Trusted RPC service is not configured: sky
In the same environment, the trusted node_repl path can import @oai/sky and sky.list_apps() succeeds. It enumerated native apps and detected the running Spotify.exe desktop app.
Desktop logs show the bundled node-repl runtime, CUA helper, native pipe, node_repl, and cua_repl starting successfully with error=null. The exact older browser trusted-path string from Community topic 1391055 was not present in the current desktop logs.
This confirms issue Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only #42745 is still present for the native Windows surface, even though browser control works. The related Community topic was closed by support on Sep 8, but the current native routing/configuration failure remains reproducible.

Working workaround: route native app inspection/control through trusted mcp__node_repl__js with @oai/sky, rather than browser-only cua_repl. This workaround is currently working here, but it is not a permanent fix because the generated browser-only surface still omits sky.

Related tracking: #43594, #44986, and #45948. A redacted evidence report is available locally; raw session logs were not uploaded because they may contain private prompt/history data. No secrets or private paths are included in this comment.

Still reproducible on the latest Windows build 26.924.22138.

Environment

Codex Desktop (Windows): 26.924.22138
unified-computer-use@openai-bundled: 26.924.22138
Agent environment: Windows native
Windows 11 Home, build 10.0.26200, x64
Session ID: no-active-thread-01a0dce1-a57e-7e72-b9bc-e8d9e927a07c

Symptoms

Codex cannot control the Windows desktop or browser through Computer Use; it reports that it cannot connect to the Windows screen-control feature.
Settings → Plugins → Computer Use is ON.
Settings → Plugins → MCP lists only node_repl.
/mcp in chat shows codex_app, codex_apps, cua_repl, node_repl as enabled; no computer-use entry appears.

Configuration

%USERPROFILE%\.codex\config.toml has both
[plugins."unified-computer-use@openai-bundled"] enabled = true and
[plugins."computer-use@openai-bundled"] enabled = true,
plus the codex-computer-use.exe / SKY_CUA_NATIVE_PIPE entries. Nothing in it disables Computer Use.
No requirements.toml exists on the machine.
The generated %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\26.924.22138\.mcp.json still contains:

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

There is no computer surface and no sky trusted service, which matches this issue. OpenAI Support asked me to report this on GitHub with the session ID.

Windows remote-control probe (2026-10-16)

I tested the Windows desktop path from an authorized Mac hub.

Observed:

SSH reached the expected Windows host and user; Windows 11 build 26200 was confirmed.
TCP 22 and 3389, the RDP services, and the RDP listener were healthy.
The existing GUI bridge responded to a direct send.ps1 ping (session=2, 1728x1080) and returned a native window list.
Windows App rendered a full Windows desktop frame, so the remote screen was readable.
The actual CUA coordinate click returned Computer Use server error -10005: noWindowsAvailable.
The bridge screenshot path returned CopyFromScreen / invalid-handle, and qwinsta showed the bridge session disconnected while the console session was active with no active rdp-tcp# session.

This adds a remote-session/input-layer reproduction to the existing browser-only / missing-sky reports: transport and native helper reachability can succeed while the live Computer Use input target is still unavailable. A separate local wrapper issue also exists: ~/bin/wgui currently mangles the Windows C:\Users\... path, so the probe used the existing bridge's send.ps1 directly; no persistent configuration or Windows settings were changed.

The issue remains actionable. We can continue the fix from either Codex or Claude by first verifying the generated Windows surface/trusted sky registration, then validating a harmless native-app screenshot and input action in an active interactive session. This probe does not claim the permanent fix is complete.

Navigation Menu

Repository navigation

Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only #42745

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Symptoms

Configuration

Windows remote-control probe (2026-10-16)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only #42745

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

ArdenZC commented on Sep 5, 2026

WhitePepperLambSoup commented on Sep 5, 2026

RnVidaisy commented on Sep 7, 2026

bbouldin commented on Sep 8, 2026

SivanTechDev commented on Sep 9, 2026

al-osokin commented on Sep 11, 2026

XYnZhiZhi commented on Sep 12, 2026

XYnZhiZhi commented on Sep 12, 2026

babalubas090 commented on Sep 18, 2026

Zburgers commented on Sep 18, 2026

furusatocompany-prog commented on Sep 26, 2026

Environment

Symptoms

Configuration

EasonAI-5589 commented on Oct 15, 2026

Windows remote-control probe (2026-10-16)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions