›_ Codex Issues
Codex Issues / #28084

Windows desktop upgrade can leave Browser, Chrome, and Computer Use globally unavailable due to mixed plugin/runtime state

Open 💬 6 comments Opened Jun 13, 2026 by Vagex
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

After a Codex Windows desktop app update, Browser, Chrome, and Computer Use could all become globally unavailable in Settings. Restarting the app did not repair the state. The failure was caused by several pieces of old and new state being mixed across the bundled marketplace snapshot, version cache, Chrome native host, and cua_node runtime.

This should be handled atomically by the desktop app updater. A periodic self-heal process is not an appropriate solution because it adds more mutable state and can conceal upgrade defects.

Environment

  • Windows desktop app package: OpenAI.Codex_26.609.4994.0_x64
  • Bundled Browser/Chrome/Computer Use plugin version: 26.609.41114
  • cua_node runtime archive: cua-node-0.0.1-20260609000952-8714bea94049-win32-x64.zip
  • @oai/sky: 0.4.10
  • Codex Doctor: 0.140.0-alpha.2

User-specific names and paths have been removed from this report.

Observed failures

  1. The reconstructed bundled marketplace snapshot under .codex/.tmp/bundled-marketplaces/openai-bundled was incomplete/stale and at one point contained only the Chrome plugin without a valid marketplace index.
  2. plugins/cache/openai-bundled/chrome/latest pointed to the temporary marketplace source instead of the immutable versioned cache directory.
  3. A stale extension-host.exe from the previous version retained a lock on plugins/chrome/extension-host/windows/x64, causing repeated marketplace reconciliation failures (EBUSY).
  4. The Windows sandbox failed to start the runtime with CreateProcessAsUserW failed: 5 until the runtime path had read/execute traversal permissions for CodexSandboxUsers.
  5. The bundled Computer Use plugin imports:
@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js

The file exists in the bundled @oai/sky package, but @oai/sky@0.4.10 only exports:

{
  ".": "./dist/project/cua/sky_js/src/index.js"
}

This produces:

ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by "exports"

The app package copy and the extracted local runtime copy of @oai/sky/package.json had identical SHA-256 hashes, so this was a bundled plugin/runtime compatibility mismatch rather than stale local runtime content.

Expected upgrade behavior

The updater should treat the bundled marketplace, plugin cache, runtime, native host configuration, and active version pointers as one versioned transaction:

  1. Stop or retire previous-version native host processes before replacing/reconciling their files.
  2. Stage the complete bundled marketplace and verify its index/manifests before switching the active pointer.
  3. Keep latest links pointed only at immutable versioned cache directories, never at a temporary reconciliation source.
  4. Validate plugin imports against the exact bundled runtime package exports before release.
  5. Apply required sandbox read/execute/traversal ACLs when extracting a new runtime.
  6. Switch active state only after all checks pass; retain the previous complete version for rollback.
  7. Remove or ignore incompatible old cache entries rather than merging them into the new version.

Validation after manual repair

After rebuilding the marketplace from the installed AppX resources, repointing Chrome latest to the versioned cache, reinstalling the native host manifest, applying minimal runtime traversal permissions, and adding the missing exact package export:

  • browser, chrome, and computer-use all reported installed, enabled.
  • Computer Use successfully performed a real list_apps call and returned 40 applications, including Google Chrome.
  • codex doctor --summary reported 16 ok, 0 fail.

Please fix this in the desktop update/install migration path rather than adding a periodic repair task.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27234
  • #26785
  • #26792
  • #26692
  • #26501

Powered by Codex Action

carlylaunikkie · 2 months ago

I’m seeing the same failure on Windows after a clean reinstall.

Environment:

  • Codex app: 26.609.4994.0
  • Computer Use plugin: 26.609.41114
  • @oai/sky: 0.4.10

Exact error:

Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by "exports" in @oai/sky/package.json

What I tried:

  • Clean reinstall of Codex from Microsoft Store via winget
  • Renamed the old C:\Users\admin\.codex directory before reinstalling
  • Reinstalled / re-enabled Computer Use
  • Tested elevated and unelevated sandbox configurations
  • Tested different approval settings

Result:
Computer Use fails during initialization before connecting to the Windows desktop. No applications were opened, clicked, typed into, or modified during the failed attempts.

This appears to be the same bundled Computer Use plugin / cua_node / @oai/sky compatibility issue rather than a Windows permission, sandbox, approval mode, Chrome, Qianniu, or CapCut issue.

TMSystems-Rights · 21 days ago

Possibly related to this issue.

After a recent Codex Desktop update on Windows, Computer Use stopped working in the “Ask for approval” / workspace-write permission profile.

The initialization now fails with:
EPERM: operation not permitted, lstat '%LOCALAPPDATA%\OpenAI\Codex'

The same task succeeds in Full access: Computer Use initializes and sky.list_windows() returns windows successfully.

Before the update, Computer Use worked with “Ask for approval”.
My config uses:
[windows]
sandbox = "elevated"

The current Computer Use skill imports @oai/sky directly from the local Codex runtime. Also, /sandbox-add-read-dir is not available in the Desktop app’s slash-command list.

Feedback ID: 019facbf-d0e1-7db1-8aea-17ff5139d5ad

zemeng5208 · 16 days ago

Disclosure: I maintain WinBridge Recovery, an independent, non-commercial Windows recovery utility for Codex Desktop.

This report is very close to the failure class the tool was built around: the installed AppX version moves forward while the user-side bundled marketplace snapshot, versioned plugin cache, latest pointers, Chrome native-host state, and cua_node runtime can end up representing different generations.

WinBridge Recovery resolves the currently installed official Codex package, compares the relevant user-side state, creates a backup/rollback point, and repairs only the inconsistent local state it can verify. In particular, the marketplace/cache/active-pointer/native-host portions described here are within its intended scope.

I do want to separate that from the upstream package-compatibility and sandbox portions in this issue: the utility is not a replacement for an OpenAI fix and it does not bypass sandbox policy or modify/take ownership of WindowsApps. But for users whose machine is stuck specifically in the mixed old/new local state described above, it may save them from reproducing the manual recovery steps one by one.

trikkur · 14 days ago

Additional confirmed case: intermediate ACL traversal break

I reproduced a narrower ACL variant of this issue on Windows 11:

  • Codex desktop package: 26.803.10989.0
  • bundled command runner: 0.147.0-alpha.6.6
  • Computer Use plugin: 26.803.81509
  • configured sandbox: elevated

The elevated sandbox could start ordinary commands, but Computer Use failed while starting its runtime with:

EPERM: operation not permitted, lstat 'C:\Users\<user>\AppData\Local\OpenAI\Codex'

Temporarily switching only [windows].sandbox to unelevated made the same Computer Use runtime initialize and control a harmless desktop app, which isolated the failure to the elevated sandbox path.

The ACL chain was inconsistent:

  • %LOCALAPPDATA% granted ReadAndExecute to CodexSandboxUsers.
  • %LOCALAPPDATA%\OpenAI had inheritance disabled and no CodexSandboxUsers entry.
  • %LOCALAPPDATA%\OpenAI\Codex also had no such entry.
  • A deeper %LOCALAPPDATA%\OpenAI\Codex\runtimes directory did have explicit ReadAndExecute for the group.

That left the dedicated sandbox user unable to traverse the two intermediate directories even though the runtime subtree itself had the expected access.

A bounded repair resolved it:

  1. Added an explicit, non-inheriting, folder-only ReadAndExecute allow entry for CodexSandboxUsers to exactly:
  • %LOCALAPPDATA%\OpenAI
  • %LOCALAPPDATA%\OpenAI\Codex
  1. Did not add inheritance flags and did not alter the sibling %LOCALAPPDATA%\OpenAI\extension tree.
  2. Returned [windows].sandbox to elevated.

Post-repair verification:

  • commands run as the dedicated CodexSandboxOffline account;
  • that account can traverse the Codex runtime path;
  • an apply_patch create/update/delete probe succeeds in the writable workspace;
  • @oai/sky initializes and list_apps() succeeds;
  • Computer Use successfully launches and closes a pre-existing harmless desktop app.

This suggests the desktop updater/setup path should validate traversal on every intermediate directory between %LOCALAPPDATA% and the selected runtime, and add only the minimum folder-level ACEs when inheritance is blocked. A recursive broad ACL grant is not necessary.

No logs, account identifiers, machine names, project names, session IDs, SIDs, private paths, or application/document titles are included in this report.

TMSystems-Rights · 14 days ago

Update: the issue appears resolved for my case after updating Codex Desktop / Computer Use to 26.810.41047.

With “Ask for approval” (workspace-write), Computer Use now imports @oai/sky successfully and sky.list_windows() returns 18 windows. The previous error no longer reproduces:

EPERM: operation not permitted, lstat '%LOCALAPPDATA%\OpenAI\Codex'

No settings were changed and no UI input actions were performed during this check. Full access was not retested because the more restrictive profile now succeeds.

Feedback ID: 019facbf-d0e1-7db1-8aea-17ff5139d5ad