Windows Store Codex v26.623: Computer Use plugin/cache/runtime valid after EFS workaround, but session tools are not injected and node_repl is never started

Resolved 💬 2 comments Opened Jul 3, 2026 by ASER-ho Closed Jul 3, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • OS: Windows 11 Home China
  • Codex Store app: v26.623.13972.0
  • Install method: Microsoft Store
  • Account: ChatGPT Plus
  • Model: gpt-5.5 medium
  • Clean .codex was tested after a full reset. The old .codex was backed up and not restored.

Summary

Computer Use is visible in Settings, but tools are never injected into a new thread.

This started as a bundled plugin/EFS issue similar to #25220. I manually worked around the EFS copy failure and rebuilt the bundled plugin cache/latest junctions. After that, DiagnoseOnly reports the plugin cache and Computer Use client as valid.

The CUA runtime also validates successfully: node.exe, node_repl.exe, node_modules, and codex-computer-use.exe exist, and CodexSandboxUsers has RX permissions on the runtime binaries.

However, invoking @Computer still returns no computer use tools injected, and no node_repl.exe or codex-computer-use.exe process is ever started.

What initially failed

In a clean .codex state:

  • Settings → Computer Use page is present.
  • Clicking Install fails with:
Failed to load plugin connection

The Store app bundled plugin source under C:\Program Files\WindowsApps\... appears to be EFS-protected. Copying from that source fails with:

ERROR 6000 (0x00001770): The specified file could not be encrypted.

This looks related to #25220.

Manual EFS workaround performed

I created an unencrypted user-space mirror of the bundled openai-bundled marketplace and configured Codex to use it:

[marketplaces.openai-bundled]
source = '%USERPROFILE%\.codex\plugins\sources\openai-bundled'

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

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

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

Then I manually rebuilt the plugin cache/latest junctions.

Plugin/cache diagnostic result

Before the workaround, these were false. After the workaround, they became true:

  • browserLatest=true
  • browserClient=true
  • chromeLatest=true
  • chromeBrowserClient=true
  • chromeExtensionHost=true
  • computerUseLatest=true
  • computerUseLatestTargetExists=true
  • computerUseClient=true
  • marketplaceMirrorManifest=true

No more ERROR 6000 appears during DiagnoseOnly after the manual mirror/cache rebuild.

CUA runtime validation

The CUA runtime exists under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\.

These files exist: node.exe, node_repl.exe, setup.ps1, node_modules\@oai\sky\bin\windows\codex-computer-use.exe.

setup.ps1 validates successfully.

CodexSandboxUsers has RX permission on node.exe and node_repl.exe.

This seems related to #28943, but the runtime ACL part appears to be valid on my machine.

Actual behavior

In a new thread:

@Computer Open Calculator using Computer Use. Do not use PowerShell, SendKeys,
Start-Process, shell, command line, scripts, or fallback automation. If Computer
Use tools are not injected in this thread, say exactly: "no computer use tools
injected".

Response: no computer use tools injected

  • No blue border
  • No app approval prompt
  • No screenshot/click/type tools
  • No Browser/Chrome tools
  • No node_repl / JS tool
  • No node_repl.exe process (checked before and after @Computer)
  • No codex-computer-use.exe process (checked before and after @Computer)

Expected behavior

After the plugin cache, Computer Use client, CUA runtime, and runtime ACLs are validated, invoking @Computer should start the native helper / node_repl connection and inject Computer Use tools into the current session.

At minimum, Codex should expose a clear product-level reason if Computer Use cannot be injected into the current thread.

Related

  • #25220 — Bundled plugins fail because copyfile fails on EFS-encrypted WindowsApps files
  • #25391 — Computer Use client exists but native pipe path/helper context is unavailable
  • #28943 — Runtime ACL fix for runtimes directory
  • #25488 / #25012 — node_repl / Windows sandbox startup failures

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29921
  • #30562
  • #30486
  • #30026
  • #30685

Powered by Codex Action

ASER-ho · 1 month ago

Thank you for flagging these duplicates. I can confirm this is the same category of failure:

  • #29921 — plugin visible, runtime tools not injected
  • #30562 — runtime present, node_repl js not exposed
  • #30486 — mcp__node_repl__js not exposed, js_repl removed by config normalization
  • #30026 — plugins enabled but node_repl js unusable
  • #30685 — nativePipe never injected despite helper running correctly

My report adds two specific pieces of evidence not covered in the others:

  1. WindowsApps EFS root cause: The bundled plugin source under C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\plugins\openai-bundled is EFS-encrypted (cipher /c shows E openai-bundled). Any attempt to copy files from there — including Codex Settings Install and the community repair script — fails with ERROR 6000 (0x00001770): The specified file could not be encrypted. This is likely why Settings Install shows "Failed to load plugin connection" on some Windows 11 Home China machines.
  1. Full workaround verification: I manually created an unencrypted mirror, rebuilt all cache/latest junctions, and ran setup.ps1 (which validates). DiagnoseOnly confirms every plugin/runtime check passes. Yet @Computer still returns no computer use tools injected and neither node_repl.exe nor codex-computer-use.exe is ever started.

The remaining gap appears to be the session-level injection of the native helper/node_repl connection, not a file/permission issue.

I will leave this issue open in case the EFS/WindowsApps evidence helps narrow the root cause, but I am fine with it being closed as a duplicate of any of the above if the maintainers prefer to consolidate.