›_ Codex Issues
Codex Issues / #27747

Windows Computer Use @oai/sky exports mismatch still reproduces on 26.609.30741 / @oai/sky 0.4.10

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

What issue are you seeing?

Windows Computer Use still fails during bootstrap because the bundled computer-use-client.mjs imports an internal @oai/sky subpath that the bundled @oai/sky package does not export.

This appears to be the same packaging/exports contract issue as openai/codex#27287, but it is still reproducible after the bundled Computer Use plugin/runtime updated to a newer build.

Slightly pointed note: this is exactly the kind of bundled dependency mismatch that should be caught before release. Users should not need to become package.json janitors after every Codex desktop/runtime update just to use a first-party bundled plugin.

Exact error

Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by "exports" in C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b\bin\node_modules\@oai\sky\package.json

Environment observed

  • OS: Windows
  • Codex Desktop package path: C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\app\Codex.exe
  • Computer Use plugin path: C:\Users\<user>\.codex\plugins\cache\openai-bundled\computer-use\26.609.30741
  • @oai/sky version: 0.4.10
  • @oai/sky package path: C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b\bin\node_modules\@oai\sky
  • Current @oai/sky/package.json only exports . before the workaround.

Reproduction steps

  1. In Codex Desktop on Windows, invoke Computer Use / @Computer.
  2. Use the supported bootstrap from the bundled Computer Use skill:
if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import(
    "C:/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.609.30741/scripts/computer-use-client.mjs"
  );
  await setupComputerUseRuntime({ globals: globalThis });
}
globalThis.apps = await sky.list_apps();
  1. The import fails before sky.list_apps() can run, with the package exports error above.

What appears to be happening

computer-use-client.mjs imports this internal module:

import { WindowsComputerUseClientBase } from "@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js";

That file exists on disk in the bundled runtime:

...\node_modules\@oai\sky\dist\project\cua\sky_js\src\targets\windows\internal\computer_use_client_base.js

But @oai/sky/package.json exports only:

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

So Node rejects the internal subpath import before the Computer Use client reaches any Windows helper/native pipe logic.

Workaround that confirms the cause

Adding the missing subpath export to the current runtime's @oai/sky/package.json allows the normal computer-use-client.mjs bootstrap to proceed:

"./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js": "./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js"

After applying that local workaround and resetting the JS kernel:

  • sky.list_apps() succeeded.
  • It returned 40 apps.
  • get_window_state({ include_text: true }) successfully read state from an existing Windows app window.

This is not a durable fix because Codex updates create a fresh cua_node/<hash> runtime, so the local package edit is lost on the next runtime update.

Expected behavior

Computer Use should bootstrap from the first-party bundled plugin without users editing files under AppData\Local\OpenAI\Codex\runtimes\cua_node\...\node_modules.

A first-party bundled plugin should either:

  • import only exported/public @oai/sky entrypoints, or
  • ship an @oai/sky package that exports the internal subpath it imports.

Additional context

This is one of several recent Windows Computer Use incompatibility failures reported in this repository, including native pipe/helper path issues and missing nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY wiring. This one is earlier and more deterministic: package import fails before the native helper is even contacted.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #27287
  • #27600

Powered by Codex Action

gktdgktd · 1 month ago

Adding a broader failure history from the same Windows host because this has not been a one-off break. The @oai/sky exports mismatch is the latest deterministic failure, but this machine has hit multiple distinct Windows Computer Use breakpoints across recent Codex desktop/plugin updates.

Pointed note #1: Windows Computer Use currently feels less like a first-party bundled feature and more like a tour of every fragile seam between the app, marketplace cache, native helper, Node runtime, and plugin package graph.

Pointed note #2: Users should not need to debug stale native hosts, missing helper paths, missing native pipe metadata, and broken package exports just to let a first-party Codex plugin click a Windows app.

Repeated failure classes observed on this host

1. Bundled marketplace / Chrome native-host lock broke Computer Use helper availability

Observed log chain across earlier runs included:

bundled_plugins_marketplace_install_failed ... errorCategory=plugin_cache_windows_file_lock ... errorMessage="failed to uninstall plugin: failed to remove existing plugin cache entry: 拒绝访问。 (os error 5)"

and:

bundled_plugins_marketplace_resolve_failed errorCode=EBUSY errorMessage="EBUSY: resource busy or locked, rmdir '...\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64'"

This was followed by the Computer Use native helper path failure:

computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32

In that state, the temporary bundled marketplace could be incomplete, e.g. containing only chrome and not computer-use, making the later Computer Use native pipe path is unavailable symptom unsurprising.

2. Native pipe metadata was not injected into the Node REPL runtime

Separate from missing helper paths, sessions on this machine also failed at the plugin/runtime boundary with missing runtime metadata:

Computer Use native pipe path is unavailable

Runtime probes showed the relevant Computer Use bridge metadata was absent in the JS execution context:

{
  "hasConfig": false,
  "hasNativePipe": false,
  "hasPipeEnv": false,
  "pipeEnv": null
}

This failure class is different from the helper executable not starting. The app may have a live-looking codex-computer-use-* pipe in logs, but the plugin bootstrap still cannot connect if nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY is not present in the execution context.

3. Desktop/session-state failure: GetCursorPos access denied

Another distinct class observed on this host:

GetCursorPos failed: 拒绝访问 (0x80070005)

This is not the same as missing-helper-path and not the same as the @oai/sky package export mismatch. It points at Windows desktop/session state or access context. It needs to be classified separately; otherwise troubleshooting bounces between unrelated fixes.

4. Package export mismatch now reproduced across runtime/plugin updates

The current issue is the most deterministic one:

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

This was first observed here with:

  • Computer Use plugin 26.608.12217
  • @oai/sky 0.4.8-202606020558-pr-981870-f570e0604110
  • runtime cua_node\2f053e67fec2d258

After a Codex/plugin/runtime update, the same class still reproduced with:

  • Computer Use plugin 26.609.30741
  • @oai/sky 0.4.10
  • runtime cua_node\789504f803e82e2b

In both cases, the internal file existed on disk, but @oai/sky/package.json exported only .. Adding the missing subpath export locally allowed the normal first-party computer-use-client.mjs bootstrap to proceed and sky.list_apps() to succeed.

5. Verification after workaround

After applying the local @oai/sky export workaround to the active runtime and resetting the JS kernel:

sky.list_apps() succeeded
appCount: 40
get_window_state({ include_text: true }) succeeded against an existing WeChat window

That makes the package export mismatch a confirmed blocker, not a speculative diagnosis.

Why this matters

These failures are distinct but clustered in the same first-party path: bundled marketplace reconciliation, native helper startup, native pipe metadata injection, Windows desktop access, and package import compatibility. When any one layer fails, Computer Use becomes unusable, often before it can even list apps.

Please treat Windows Computer Use as a versioned compatibility contract across the Codex app, bundled plugin cache, cua_node runtime, and @oai/sky, not as a best-effort collection of moving parts that users have to patch after each update.

The durable fix should be upstream: ship a computer-use-client.mjs that imports public/exported @oai/sky entrypoints, or ship an @oai/sky package that exports the internal subpath it requires, and harden the native pipe/runtime injection path so helper readiness actually translates into a usable Computer Use JS context.

ChrisEvans2 · 1 month ago

I also reproduced this on another Windows host and opened #27826 before seeing this issue.

Additional data point:

  • Codex Desktop build/config: 26.609.30741
  • Codex CLI: 0.130.0
  • Computer Use plugin: 26.609.30741
  • @oai/sky: 0.4.10
  • Windows 11 Pro 10.0.26200, build 26200, 64-bit

I cleared and reinstalled both:

  • ~\.codex\plugins\cache\openai-bundled\computer-use
  • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

After Codex re-downloaded the runtime, the same versions came back and the same ERR_PACKAGE_PATH_NOT_EXPORTED failure reproduced. Adding the missing exports entry locally to @oai/sky/package.json allowed the normal Computer Use bootstrap to succeed; sky.list_apps() returned 40 apps and Computer Use was able to find/activate Google Chrome.

Closing #27826 as a duplicate of this issue.

Nuclear2 · 1 month ago

Still reproducible on my end. It seems like this might be relatively straightforward to diagnose, but I haven't seen a fix yet. Ideally, users shouldn't need to manually patch package.json themselves as a workaround.

ax-openai · 1 month ago

Closing as a duplicate of #27287.

Heps-akint · 1 month ago

Fresh repro on a newer Windows Store build.

Environment

  • Product: Codex Desktop, Windows Store app
  • Codex app package: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0
  • Codex CLI/runtime reported by codex doctor: 0.140.0-alpha.19, windows-x86_64
  • OS: Windows 11 Core, Windows 10.0.26200 reported by doctor
  • Computer Use plugin: computer-use@openai-bundled, version 26.611.62324
  • Runtime archive: cua-node-0.0.1-20260609232601-73ffe8b8261e-win32-x64.zip
  • Runtime hash/path shape: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\...
  • @oai/sky version: 0.4.13
  • @oai/sky/package.json exports only:
{
  ".": "./dist/project/cua/sky_js/src/index.js"
}

Repro

Using the bundled Computer Use skill's documented bootstrap:

if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import("<CODEX_HOME>/plugins/cache/openai-bundled/computer-use/26.611.62324/scripts/computer-use-client.mjs");
  await setupComputerUseRuntime({ globals: globalThis });
}
globalThis.apps = await sky.list_apps();

Actual result

Still fails before reaching any Windows helper action:

Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by "exports" in <LOCALAPPDATA>\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_modules\@oai\sky\package.json

The target file exists physically at:

@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js

but the package export map blocks the first-party plugin import.

Supported repair attempts tried

  • Restarted Codex Desktop and retried in a fresh turn/thread.
  • codex doctor: no install/config failure for plugins or MCP; only unrelated warnings.
  • codex update: cannot update this Store install, reports manual/unknown install method.
  • winget upgrade --id 9PLM9XGG6VKS --source msstore: no available upgrade.
  • Reinstalled the bundled plugin through the supported CLI path:
  • codex plugin remove computer-use@openai-bundled --json
  • codex plugin add computer-use@openai-bundled --json
  • Retried the documented bootstrap after reinstall.

Same exports error remains.

Additional related observation

After bypassing only the package-export problem locally in-memory by importing the existing runtime file via absolute file:///... URL, the next blocker is the native bridge object:

{
  "hasConfig": false,
  "hasNativePipe": false,
  "envKeys": [],
  "skyPipe": null
}

At the same time, config.toml contains the expected MCP env values, including SKY_CUA_NATIVE_PIPE=1 and SKY_CUA_NATIVE_PIPE_DIRECTORY=\\.\pipe\codex-computer-use-<uuid>, and the named pipe exists under \\.\pipe\.

So there appear to be two failures on this newer build:

  1. deterministic packaging/export mismatch between computer-use-client.mjs and bundled @oai/sky@0.4.13;
  2. the live node_repl tool session is not receiving/exposing the privileged Computer Use native pipe fields even though Codex config has them and the pipe exists.

No manual runtime/package patch was applied; only the supported plugin remove/add path was used.