Computer Use bootstrap fails on Windows because @oai/sky does not export internal client base
What issue are you seeing?
Computer Use fails during bootstrap on Windows before it can reach the native helper. The failure is an ESM package export error from the bundled @oai/sky runtime:
Error [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" in
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-hash>\bin\node_modules\@oai\sky\package.json
This prevents the computer-use@openai-bundled plugin from initializing, so calls such as sky.list_apps() never reach the Windows Computer Use helper.
Environment observed:
- OS: Windows 10 Pro x64, build 19045
- Codex CLI:
0.125.0 - Codex app/plugin build:
26.609.41114 - Plugin:
computer-use@openai-bundled, version26.609.41114 - Runtime archive:
cua-node-0.0.1-20260609000952-8714bea94049-win32-x64.zip - Runtime Node:
24.14.0 - Bundled
@oai/sky:0.4.10
What steps can reproduce the bug?
- Use a Windows Codex environment with
computer-use@openai-bundledenabled. - Start a fresh JS runtime session.
- Bootstrap Computer Use through the documented plugin entrypoint:
const { setupComputerUseRuntime } = await import(
"file:///%USERPROFILE%/.codex/plugins/cache/openai-bundled/computer-use/26.609.41114/scripts/computer-use-client.mjs"
);
await setupComputerUseRuntime({ globals: globalThis });
await sky.list_apps();
Observed result:
Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js'
is not defined by "exports" in ...\node_modules\@oai\sky\package.json
Root-cause evidence:
computer-use-client.mjsimports:
import { WindowsComputerUseClientBase } from
"@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js";
- The file exists in the runtime package:
node_modules/@oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js
- But
@oai/sky/package.jsononly exports the package root:
{
"exports": {
".": "./dist/project/cua/sky_js/src/index.js"
}
}
Because Node 24 enforces package exports, the plugin's deep import is blocked even though the target file is present.
I also tested reinstalling the Computer Use plugin cache from the bundled marketplace source. Reinstalling the plugin did not resolve the issue; the same error reproduced until the runtime package export map was corrected.
What is the expected behavior?
Computer Use should bootstrap successfully and lightweight helper calls should work, for example:
await setupComputerUseRuntime({ globals: globalThis });
const apps = await sky.list_apps();
const windows = await sky.list_windows();
Expected result: non-error arrays of apps and windows.
Additional information
Local workaround that restored functionality:
diff --git a/bin/node_modules/@oai/sky/package.json b/bin/node_modules/@oai/sky/package.json
@@
"main": "dist/project/cua/sky_js/src/index.js",
"exports": {
- ".": "./dist/project/cua/sky_js/src/index.js"
+ ".": "./dist/project/cua/sky_js/src/index.js",
+ "./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 restarting the JS runtime, validation passed:
{
"deepImportExports": ["WindowsComputerUseClientBase"],
"appCount": 40,
"runningAppCount": 6,
"windowCount": 6
}
Suggested upstream fix:
Either export the required internal module from @oai/sky/package.json, or change computer-use-client.mjs to import a public @oai/sky API that exposes WindowsComputerUseClientBase/equivalent functionality without relying on a package-internal deep import.
I did not open a code PR because the public openai/codex repository does not appear to contain the bundled Computer Use plugin source, the @oai/sky package source, or the cua_node runtime archive build configuration. The plugin metadata points at an internal source path (project/cua/sky_js/plugin), so this report includes the exact failing import, root cause, local workaround, and validation output for maintainers to apply in the appropriate source repository/package build.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗