[Windows 26.901.51231] unified-computer-use materialization sets CUA_REPL_ENABLED_SURFACES=browser, stripping sky trusted RPC #43498

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   computer-use

   skillsIssues related to skillsIssues related to skills

   on Sep 7, 2026
2. github-actions commented on Sep 7, 2026

   

   github-actionsbot

   on Sep 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • 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
3. debojyoti-dev commented on Sep 7, 2026

   

   debojyoti-dev

   on Sep 7, 2026

   More actions

   After investigating this against the actual openai/codex repository, I found that the reported behavior cannot be fixed within this repository.

   CUA_REPL_ENABLED_SURFACES has no occurrences in the repo, launch.mjs is not present, and the unified-computer-use implementation itself is not included here. I also confirmed there is no code responsible for materializing or rewriting the cached .mcp.json; the existing loader only reads the file.

   The component responsible for rewriting the materialized configuration appears to be part of the closed-source Codex Desktop Electron application, along with the bundled unified-computer-use plugin and its launch.mjs.

   I’m therefore unable to implement a meaningful fix in openai/codex without changes from the Desktop application side. I wanted to document these findings so the issue can be routed to the appropriate component/owner.
4. SivanTechDev commented on Sep 9, 2026

   

   SivanTechDev

   on Sep 9, 2026

   Last edited by SivanTechDev

   More actions

   Reproduced on a newer version:

   • Windows 11 Pro, three monitors
   • App package: 26.903.8094.0
   • unified-computer-use plugin: 26.903.61454
   • Both computer-use plugins enabled

   The generated .mcp.json contains CUA_REPL_ENABLED_SURFACES="browser". Importing @oai/sky succeeds, but sky.list_apps() fails with:

   Trusted RPC service is not configured: sky
   

   Logs report both computer-use native pipe startup ready and cua_repl status=ready.

   I manually changed the flag to "browser,computer" and verified it was saved. Calls in the existing conversation still failed. A complete app restart reset the flag to "browser", confirming the overwrite described here. Changing it again and resetting the JavaScript session still produced the same error.

   The failure occurs before window enumeration.

   Update: I found a working path on the same machine.

   Found: #42214 (comment)

   • The failing task uses cua_repl: native app methods are absent, and sky.list_apps() returns the RPC error.
   • A new GPT‑5.5/low task explicitly requesting computer-use → trusted node_repl → @oai/sky successfully enumerated Notepad, requested user approval, typed text, and verified it.
   • Switching that working task to GPT‑6 Astra/low preserved native control.
   • A second GPT‑5.5/low task listed open apps, a subsequent GPT‑5.6 turn successfully read Notepad text after approval.
   • The original task continued failing during the same app session. Successful tests ran without administrator elevation.

   This points toward task-specific tool provisioning or runtime selection. It does not establish whether GPT‑5.5 is necessary, because the starting model and initial prompt both changed.

   The minimal successful initial prompt was:

   “Use the computer-use skill via trusted node_repl and @oai/sky, not cua_repl. List the open Windows apps.”
5. motidu118 commented on Sep 10, 2026

   

   motidu118

   on Sep 10, 2026

   More actions

   Confirmed on Windows 11 with Codex Desktop 26.903.9818.0 and unified-computer-use 26.903.71938.

   After the update, the materialized bundled-plugin configuration again set:

   CUA_REPL_ENABLED_SURFACES=browser

   while SKY_CUA_NATIVE_PIPE=1 and the native-pipe directory were present. This excluded the computer surface and native app enumeration failed.

   A version-local launch.mjs workaround that adds computer when the native pipe is present restores native Computer Use after restarting Codex: sky.list_apps() returned 40 Windows apps and get_window_state() successfully read a File Explorer window. However, the workaround is overwritten by each Codex update because the bundled plugin cache is regenerated.

   Please fix the Windows materialization path so it emits CUA_REPL_ENABLED_SURFACES=browser,computer (or omits the variable and allows the launcher default). This is a repeatable update regression, not an app-permission issue.
6. bavariadk-ux commented on Sep 17, 2026

   

   bavariadk-ux

   on Sep 17, 2026

   More actions

   I can reproduce this exact issue on Windows with Codex Desktop 26.911.7940.0.

   Native Windows Computer Use is enabled in Settings (“Any App”), and the local Computer Use helper is running. Browser control works, but native app discovery returns no apps and calls to Sky fail with: Trusted RPC service is not configured: sky.

   The active materialized file is %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\26.911.61220\.mcp.json. Its cua_repl environment contains CUA_REPL_ENABLED_SURFACES = browser and NODE_REPL_TRUSTED_SERVICES = {"browser":"@oai/browser-desktop/service"}.

   There is no computer surface and no sky trusted service in the active CUA configuration. The root Codex configuration does contain a Sky entry, but it is not propagated into the active cua_repl process.

   Observed result: browser tabs are available, while the native app inventory is empty. This affects Windows programs such as Disk Management and AOMEI Partition Assistant. Restarting Windows and fully restarting Codex did not change the generated browser-only configuration.
7. alan113523 commented on Sep 21, 2026

   

   alan113523

   on Sep 21, 2026 – with ChatGPT Codex Connector

   More actions

   Still reproducible on a newer Windows build.

   Environment

   • Codex Desktop: 26.915.4065.0
   • CLI: codex-cli 0.155.0-alpha.9.2
   • Computer Use plugin: 26.915.31945
   • @oai/sky: 0.7.1
   • CUA Node runtime revision: df473e5367fa2b42

   Current behavior

   The materialized unified-computer-use/.mcp.json still contains:

   CUA_REPL_ENABLED_SURFACES="browser"
   

   and NODE_REPL_TRUSTED_SERVICES contains only the browser service. There is no computer surface or sky trusted service in the active configuration.

   Consequently, both native enumeration calls fail:

   sky.list_apps()
   sky.list_windows()
   Trusted RPC service is not configured: sky
   

   Browser control remains available, but native Windows apps such as Notepad, Calculator, and File Explorer cannot be enumerated.

   Checks performed

   The native side appears present and ready:

   • the native pipe exists and reports ready (pipe identifier omitted)
   • codex-computer-use-swift.exe is running
   • node_repl.exe is running
   • the @oai/cua-repl runtime is running
   • CodexSandboxService is running
   • the expected helper files are present

   This indicates that the failure is still at the generated surface/trusted-service configuration layer, rather than missing helper binaries or an unavailable native pipe.

   Please ensure the Windows materialization path includes computer and registers sky when native Computer Use is enabled, or omit the override so the launcher default can apply.
8. cassandradunne commented on Sep 29, 2026

   

   cassandradunne

   on Sep 29, 2026

   More actions

   Reproduced on September 29, 2026 with the Windows bundled computer-use plugins/runtime configuration reporting version 26.917.71314. Please investigate the native tool provisioning and recovery experience; this prevented an explicitly authorized screenshot of an existing Remote Desktop window.

   Observed evidence:

   • Both computer-use@openai-bundled and unified-computer-use@openai-bundled are enabled in the user configuration.
   • The saved legacy Computer Use allow list includes mstsc.exe.
   • The materialized unified-computer-use .mcp.json sets CUA_REPL_ENABLED_SURFACES="browser".
   • That server's NODE_REPL_TRUSTED_SERVICES contains only the browser service. The separate root node_repl configuration contains a sky entry; this does not establish that the separate route works.
   • cua.getState() returned apps: [] while listing connected browser tabs.
   • cua.listWindows() failed with "cua.listWindows is not a function".
   • cua.listApps() failed with "cua.listApps is not a function".
   • The documentation returned by getState() nevertheless described both native methods and Windows app access.
   • Resetting the CUA JavaScript kernel and repeating initialization did not restore native app methods.

   Reproduction in the affected task:

   1. Ask Codex to capture/read an already-open native Windows Remote Desktop window.
   2. Initialize the provided cua_repl and run await cua.getState().
   3. Attempt native enumeration using the methods described by its returned documentation.
   4. Observe the absent methods, despite enabled plugins and the existing app allow entry.
   5. Reset the kernel and repeat; the failure persists.

   Impact and agent behavior:
   The requested screenshot/status check was never delivered. The agent spent multiple turns on tangential retrieval and repeated explanations, consuming time/usage without completing the simple request. It initially did not distinguish the observed missing capability from its unverified root cause. The user reports recurring unpredictable access failures across tasks. Please address both capability provisioning and clear, accurate failure/recovery guidance so agents do not send users through repeated ineffective troubleshooting.

   Expected:
   Native Windows tasks should receive a working supported native tool route when Computer Use is enabled and authorized. If a route is unavailable, tool documentation should match the methods actually exposed, and the app should provide a concrete diagnostic and supported recovery action.

   Limits of this report:
   The root cause has not been independently proved. Alternate native routes were not tested in this session, and a full app restart was not performed. No managed plugin files or security controls were modified. No private screenshots, credentials, customer details, or full session logs are included.