Repository navigation
Windows: Computer Use cannot control native desktop apps — cua_repl launches with a browser-only surface #45948
Description
What version of the Codex App are you using (From "About Codex" dialog)?
App: 26.908.9136.0 (MSIX package OpenAI.Codex_26.908.9136.0_x64__2p2nqsd0c76g0)
Computer Use plugins: computer-use 26.908.70816, unified-computer-use 26.908.70816
Bundled CLI: codex-cli 0.154.0-alpha.6.2
What subscription do you have?
ChatGPT Plus (purchased via a mobile app store).
Computer Use plugin is installed and "Control Windows apps" is enabled.
What platform is your computer?
Microsoft Windows 11 Home, version 10.0.26200, build 26200, x64. System locale zh-CN.
What issue are you seeing?
On Windows, Computer Use can never control native desktop applications in this build. The task
loads the Computer Use plugin successfully, but the first call that needs the native surface
returns the localized error 本地应用接口不可用 ("local app interface unavailable") — the
machine-side equivalent of Trusted RPC service is not configured: sky.
Browser use (@Chrome / @Edge, the in-app browser) works normally. Only the native/computer
surface is missing.
The bundled cua_repl server starts with the browser surface only, so the trusted sky service
is never registered and native app enumeration is unavailable.
What steps can reproduce the bug?
- Install and enable
computer-useandunified-computer-useon a Windows machine. - Start any task with
@Computerthat targets a native app (e.g. "open Notepad and type a short
test message"). - Observe: the native app list is empty; native control reports the local app interface as
unavailable, while browser control still works. - Fully restart the app, start a brand-new task without any project/workspace loaded — the same
result.
What is the expected behavior?
With the Computer Use plugin enabled and "Control Windows apps" allowed, a @Computer task should
enumerate and control native Windows applications (the "Any App" workflow). The native surface
should be enabled for the bundled cua_repl server, not just the browser surface.
Additional information — local evidence
1. The bundled unified-computer-use server is configured browser-only
%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\26.908.70816\.mcp.json
contains a cua_repl server whose environment enables only the browser surface:
"env": {
"CUA_REPL_ENABLED_SURFACES": "browser",
"NODE_REPL_TRUSTED_SERVICES": "{\"browser\":\"@oai/browser-desktop/service\"}",
"SKY_CUA_NATIVE_PIPE": "1",
"SKY_CUA_NATIVE_PIPE_DIRECTORY": "\\\\.\\pipe\\codex-computer-use-e4e0d017-81ef-4ea1-b313-313e9b003ee5"
}Note that the trusted-service map here lists only browser; sky is absent. The native pipe
variables are present, which suggests the native runtime is expected but never wired to a surface.
By contrast, the plain node_repl entry in %USERPROFILE%\.codex\config.toml does trust sky:
[mcp_servers.node_repl.env]
NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.908.70816/scripts/browser-service.mjs","sky":"@oai/sky/service"}'
SKY_CUA_NATIVE_PIPE = "1"
SKY_CUA_NATIVE_PIPE_DIRECTORY = '\\.\pipe\codex-computer-use-<uuid>'2. The Computer Use tool description shown to the model says native APIs are disabled
The js tool description for the bundled cua_repl server (as persisted in
%USERPROFILE%\.codex\.codex-global-state.json) contains the line:
Native computer APIs are disabled.
3. The runtime itself is healthy — this is not a broken install
Desktop log (...\LocalCache\Local\Codex\Logs\<date>\codex-desktop-*.log):
2026-09-16T14:09:00.782Z info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-<uuid> platform=win32
2026-09-16T14:09:03.509Z info [AppServerConnection] mcp_server_startup_status_updated error=null failureReason=null hostId=local server=node_repl status=ready
2026-09-16T14:11:41.756Z info [AppServerConnection] mcp_server_startup_status_updated error=null failureReason=null hostId=local server=cua_repl status=ready
The native pipe reaches startup ready, and both node_repl and cua_repl report status=ready
with error=null. There is no native-app capability exposure or sky trusted-RPC registration
event anywhere in the logs for these threads.
4. Things already tried (all ineffective)
- Repairing / reinstalling the Computer Use plugin
- Fully uninstalling and reinstalling the desktop app
- Toggling "Any App" / "Control Windows apps" permission on and off
- Full app restart; brand-new task with no project loaded
%USERPROFILE%\.codex\config.toml: the workaround reported in Windows Computer Use: sky trusted RPC is omitted when CUA starts with browser surface only #42745
([features] js_repl = true, set while the app was fully closed, then restart) is no longer
applicable in this build —codex features listreportsjs_replasremoved:
js_repl removed false
js_repl_tools_only removed false
Question for the maintainers
- What determines the value of
CUA_REPL_ENABLED_SURFACESfor the bundledcua_replserver, and
is there any user-side setting (or server-side flag) that enables thecomputersurface on
Windows? - Does enabling the native surface require a specific plan tier or region, beyond installing the
plugin and allowing "Control Windows apps"? - Is there a supported way to force the model onto the trusted
node_repl+@oai/skypath now
thatjs_replhas been removed?
Related existing reports
#42745, #44078, #45221, #42214, #45328 — same symptom class (Windows native Computer Use
unreachable while browser use keeps working), all still open at the time of writing.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
longxingyingyue-maker commentedon Sep 17, 2026
Windows native CUA is gated by two layered config bugs — fixing
CUA_REPL_ENABLED_SURFACESalone is not enoughWindows 11, Codex Desktop
26.908.9136.0, bundledunified-computer-useplugin26.908.70816.Layer 1 (already reported). On every start and on every focus the app re-materializes
%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<ver>\.mcp.jsonwith:(
bundled_plugins_reconcile_started ... reason=startup/reason=focusin%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<yyyy>\<mm>\<dd>\*.log— 2 startup + 9 focus runs on 2026-09-17 alone.) With surfaces pinned to
browser, the nativesurface never loads.
Layer 2 — not reported anywhere I could find, and the reason a surfaces-only edit is not enough.
The launcher ships as readable (minified) JS at
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_modules\@oai\cua-repl\dist\lib\js\oai_js_cua_repl\src\launch.jsDe-minified, it accepts
browserandcomputerinCUA_REPL_ENABLED_SURFACES, builds its owndefault trusted map (
browser -> @oai/browser-desktop/service,computer -> @oai/sky/service), andthen does:
Because the generated
.mcp.jsonalways pinsNODE_REPL_TRUSTED_SERVICES, the launcher's defaultmap is discarded and
@oai/skyis never registered — no matter whatCUA_REPL_ENABLED_SURFACESsays. That is why the popular "just set it to
browser,computer" edit appears to do nothing.Verified offline with an MCP stdio JSON-RPC probe against the real
cua-repl.mjs(env copied fromthe running app; only those two variables varied; 2026-09-17):
typeof cua.getAppbrowser_only(stock)browser, trusted pinned to browserundefinedgetState()→{"apps":[],"browsers":[],"errors":[...]}both_pinned_browser(surfaces-only edit)browser,computer, trusted still pinned to browserTrusted RPC service is not configured: sky; kernel reset.both_defaultbrowser,computer, trusted map removedfunctionboth_sky_explicitbrowser,computer, trusted incl."sky":"@oai/sky/service"functionboth_pinned_browseris the smoking gun: the surface list is correct and native access is stillunavailable. The 40 apps in the last two rows are genuine — real display names plus
windows[].id(e.g. ChatGPT window id
198426) — read over the app's live computer-use pipe.(Detail:
getState()needs that pipe; when the app has not opened it the probe reportsComputer Use native pipe is unavailable: failed to connect native pipe: ... (os error 2). The pipename is regenerated per app session, so
SKY_CUA_NATIVE_PIPE_DIRECTORYrecorded inconfig.tomlcan point at a stale UUID.)
Two more observations that may help other reporters:
.mcp.json.tmp-<uuid>+ rename).Setting the file read-only makes that rename fail with a non-fatal warning —
bundled_plugins_reconcile_failed errorCode=EPERM ... rename '...\.mcp.json.tmp-…' -> '...\.mcp.json'(8 occurrences between 14:50 and 15:07 UTC here) — the edit survives, the plugin still loads and
the browser surface keeps working. Leftover
.tmp-*files pile up beside it.~/.codex/config.tomlregisters
[mcp_servers.node_repl.env] NODE_REPL_TRUSTED_SERVICESwithsky -> @oai/sky/serviceplus
SKY_CUA_NATIVE_PIPE = "1", so any turn that getsnode_replcan drive native apps viaawait sky.launch_app(...). Reporters hit the bug because the model is handed the browser-onlycua_repltool and concludes "local application interface unavailable".Question for the team: is the native surface supposed to be reachable through
cua_replon Windows?If yes, layer 2 needs fixing — either stop pinning
NODE_REPL_TRUSTED_SERVICESin the generated.mcp.json, or includecomputer/skyin it whenever the surface list includescomputer.zoltarius77 commentedon Sep 21, 2026
I encountered similar behavior and found a workaround using the installed Windows Computer Use skill.
Observed behavior
A fresh Work chat reported “Native computer APIs are disabled” and offered only browser control when asked to open Notepad and type a short test message.
Working workaround
Explicitly instructing the assistant to read the installed Windows Computer Use skill and its required documentation, then follow its documented
node_repl+@oai/skyworkflow, allowed it to complete the Notepad task.The test succeeded again after restarting. Running the app as administrator was unnecessary for these successful tests.
Making the workaround persist
Adding the following guidance to personal
AGENTS.mdinstructions allowed a subsequent fresh Work chat to complete a simple Notepad request without the technical preprompt:Possible area to investigate
These observations suggest a skill-discovery, instruction-loading, or tool-selection issue. The root cause remains unconfirmed, and this workaround is not guaranteed to resolve every case.
No plugin launch parameters were modified or access restrictions bypassed to achieve the successful result.
Update: the instructions can also be managed through the app’s settings.
In the Windows desktop app, open Settings → Personalization → Codex instructions. The computer-control guidance I added appears in that field.
According to the [official settings documentation](https://learn.chatgpt.com/docs/reference/settings), editing this field updates the personal
AGENTS.mdinstructions. You can therefore add the guidance through this editor and save it without manually opening the file.Then start a fresh Work chat and test a simple desktop-control request. This remains a workaround; the underlying cause is unconfirmed.
ciallo0815 commentedon Sep 21, 2026
I can reproduce this on Windows with Computer Use enabled.
In a local Codex task, I asked
@Computerto open Notepad and report its window title. Native app discovery returned no accessible applications, and initializing the native backend failed with:cua.getState()also returned an empty app inventory. The Windows desktop was unlocked, and Computer Use had been enabled before testing.This blocks native Windows application control entirely; the issue is reproducible before any app-specific interaction begins.
ldknappe commentedon Sep 24, 2026
I am seeing the same problem on Windows 11 Home.
Current Codex desktop package:
OpenAI.Codex 26.917.9434.0
Windows:
Windows 11 Home, build 26200, x64
ChatGPT Plus.
Computer Use browser access works, but native Windows applications such as Notepad and LibreCAD are not available.
codex doctornow reports:The bundled unified Computer Use configuration contains:
CUA_REPL_ENABLED_SURFACES = "browser"
I then started a new Codex task and explicitly asked it to use the Windows native Computer Use route through
node_repland@oai/sky, callsky.list_apps(), and only report the result.Codex responded:
"I can’t run the diagnostic: the native
node_repl/@oai/skyComputer Use capability isn’t available in this session’s tool list. I did not click or type anything, so I can’t determine whether Notepad appears."So in my case this appears to fail before native application enumeration: the Windows-native
node_repl/@oai/skycapability is not exposed to the session at all.This same PC previously used Codex Computer Use successfully with LibreCAD and Notepad, so native Computer Use has worked on this machine before.
Latest Feedback ID:
01a0ca2a-e377-71e3-a087-191d82ddec03
ldknappe commentedon Sep 25, 2026
Additional diagnostic result:
I also tested the same native-app access through ChatGPT Work, not just Codex.
With LibreCAD and Notepad open and visible on the active Windows desktop, I asked Work to list the native Windows applications it could currently see without clicking or changing anything.
Work reported:
"The native Windows application list is currently empty.
So this is not limited to a particular Codex task or Codex tool-routing instruction. Both Codex Computer Use and ChatGPT Work are unable to enumerate native Windows applications on this PC, while browser-related Computer Use remains available.
Codex Doctor currently reports:
This suggests the failure may be in the shared Windows native-app exposure/bridge layer.
ShreyBhatt-108 commentedon Sep 30, 2026
Reproduced on Codex Desktop for Windows 26.924.2738.0.
The native Windows Computer Use backend itself is healthy: initializing the bundled
@oai/skyruntime directly successfully enumerated Microsoft Word and its open window. However, this chat'scua_replservice is browser-only: its active environment hasCUA_REPL_ENABLED_SURFACES=browser, andcua.getState()returns no native apps (only the in-app browser).The bundled Computer Use and Unified Computer Use plugins are enabled, Windows sandbox mode is elevated, Word has no deny rule, and Word was visible on the active desktop. The failure has persisted across prior restarts for months.
Expected: a Windows native-app task with Computer Use enabled should expose the computer surface and enumerate Word.
Actual: the chat is routed to a browser-only CUA service despite the native backend being able to enumerate Word. This makes native Windows app control unavailable while browser control remains available.
ToxicF4TE commentedon Sep 30, 2026
Additional Windows/Dots diagnostic evidence from September 30, 2026, on a newer build:
node_repl+@oai/skyroute was not callable in the tested local session's tool inventory. An explicitly approved dot diagnostic also reported no callable Windows route; its cloud-environment CUA tool did not demonstrate access to the connected Windows desktop.cua_repltool says “Native computer APIs are disabled.”cua.getState()returnedapps: []with browser surfaces; a read-onlycua.listApps()attempt returnedcua.listApps is not a function.CUA_REPL_ENABLED_SURFACES=browser. A separate configurednode_replserver trustssky. Desktop logs show native pipe startup ready andnode_replstatus ready for the local diagnostic chat, but the model still had no callablenode_repltool. Startup alone does not establish working native control.cua_replstartup failure. A previous delegated diagnostic had a Windows shell execution context despite its cloud task coordination, so browser/Linux cloud CUA should not be mistaken for Windows desktop control.This appears to fail at supported tool exposure before a native Windows action can be attempted. Native mouse/keyboard/screenshot operations were not tested, and no plugin parameters, permissions, security settings, or packaged files were changed. The current updater reports
up_to_date.Please investigate why a ready native server does not expose its Windows tool route to these sessions. This is additional version/tool-availability evidence, not a claim that the internal cause is identical to every report above.
Private feedback update: The reporter has submitted in-app feedback and supplied feedback/session ID
01a0f42d-f19d-7681-8e93-4cd0e4b1421e. Please use it to correlate the Windows native-tool diagnostics above with the private feedback.ToxicF4TE commentedon Oct 1, 2026
Post-update retest — September 30, 2026 (America/New_York, before midnight)
The reporter installed the newer desktop update and reran a native Windows Computer Use check. The required tools were still unavailable in the tested session.
Installed versions verified locally after the update:
The test reported that
node_repland native Windows capture/click tools were absent. Calculator was not opened. No PowerShell or shell substitutes were used for the computer-use check.This establishes the reported tool-availability failure; it does not establish that a native capture/click operation was attempted and failed. No fresh claim about the internal cause or current server-startup state is made.
The earlier September 30 diagnostic and its feedback/session reference remain intact. This is a later retest on the newer app build, performed before midnight local time. The related existing-chat read failure and sidebar project-assignment problem are tracked in #49746 and #49646.
publica10 commentedon Oct 1, 2026
I’m seeing the same behavior in the Computer Use.
"Any App" is enabled, and I removed and reinstalled the Computer Use MCP server and skill; the issue persists.
Environment
Runtime observations
Relevant local log entries
I made no changes to the generated config or settings.
Sharing this as another reproduction of the same behavior, on desktop version 26.928.31416.