Computer Use 1.0.1000451 cannot load @oai/sky because nodeRepl.env is empty on macOS 26

Open 💬 7 comments Opened Jul 21, 2026 by antonreshetov

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.715.52143 (5591)

Computer Use plugin: 1.0.1000451

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5.1 (25F80), Apple Silicon

What issue are you seeing?

The bundled Computer Use plugin cannot initialize. Every Computer Use operation fails before accessing the target application because the plugin wrapper cannot locate the bundled @oai/sky runtime.

The runtime is installed inside the ChatGPT application bundle, but nodeRepl.env is an empty immutable object. Consequently, computer-use-client.mjs receives no NODE_REPL_NODE_MODULE_DIRS, creates an empty search-root list, and throws:

Computer Use could not load @oai/sky from the cua_node runtime

This reproduces with sky.list_apps() and when targeting Safari or Google Chrome. The failure occurs before application permissions or UI access are evaluated.

Diagnostic output from the running Node REPL:

{
  "env": {},
  "envExtensible": false,
  "nodeReplEnvDescriptor": {
    "value": {},
    "writable": false,
    "enumerable": true,
    "configurable": false
  }
}

The required runtime does exist at:

/Applications/ChatGPT.app/Contents/Resources/cua_node/lib/node_modules/@oai/sky/dist/project/cua/sky_js/src/targets/mac/create_client.js

The plugin-owned wrapper is installed at:

$HOME/.codex/plugins/cache/openai-bundled/computer-use/1.0.1000451/scripts/computer-use-client.mjs

No PII, credentials, or access tokens are included in this report.

What steps can reproduce the bug?

  1. On an Apple Silicon Mac, install and enable the bundled Computer Use plugin.
  2. Enable its MCP server and skill.
  3. Grant the Codex/ChatGPT desktop app Screen Recording and Accessibility permissions.
  4. Restart the desktop app and open a fresh Codex task.
  5. Invoke @Computer and ask it to list the available applications, or run the documented plugin bootstrap:
if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import(
    "$HOME/.codex/plugins/cache/openai-bundled/computer-use/1.0.1000451/scripts/computer-use-client.mjs"
  );
  await setupComputerUseRuntime({ globals: globalThis });
}

await sky.list_apps();
  1. Observe the initialization error:
Computer Use could not load @oai/sky from the cua_node runtime

Troubleshooting already performed:

  • Restarted the desktop app multiple times.
  • Verified that Computer Use, its MCP server, and its skill are enabled.
  • Tested both Safari and Google Chrome.
  • Verified that the @oai/sky runtime exists in the application bundle.
  • Verified that the runtime's node_modules directory is already registered with js_add_node_module_dir.
  • Added another registered node_modules path; nodeRepl.env remained empty.
  • Confirmed that nodeRepl.env cannot be modified because it is frozen and non-writable.

Session ID: not applicable / not available.

Token-limit and context-window usage: not relevant; the failure occurs during tool runtime initialization.

What is the expected behavior?

setupComputerUseRuntime() should locate the bundled @oai/sky runtime, initialize globalThis.sky, and allow list_apps() and get_app_state() to execute.

The Node REPL should expose its registered module roots through NODE_REPL_NODE_MODULE_DIRS, or the Computer Use wrapper should obtain them through another supported Node REPL API.

Additional information

This appears related to #26190, which reports missing NODE_REPL_NODE_MODULE_DIRS and failed @oai/sky resolution on Windows. This report covers the same failure class on macOS with a newer desktop and Computer Use plugin build.

The Node REPL internally knows the module directory: calling js_add_node_module_dir with the ChatGPT-bundled cua_node/lib/node_modules directory reports that it is already registered. However, that registration is not reflected in the immutable nodeRepl.env object consumed by computer-use-client.mjs.

There is no documented workaround because the Computer Use skill requires loading @oai/sky through the plugin-owned wrapper rather than importing the package directly.

View original on GitHub ↗

7 Comments

hidakat · 1 month ago

I can independently reproduce this issue on a newer ChatGPT desktop build for macOS.

Environment

  • ChatGPT app: 26.715.70719
  • Also reproduced previously on: 26.715.61943 (build 5628)
  • Computer Use plugin: 1.0.1000451
  • @oai/sky: 0.4.20
  • Bundled Node.js: v24.14.0
  • Platform: Apple Silicon macOS
  • Subscription: Plus

Runtime result

Although ~/.codex/config.toml contains the expected Node REPL environment configuration:

[mcp_servers.node_repl.env]
NODE_REPL_NODE_MODULE_DIRS = "/Applications/ChatGPT.app/Contents/Resources/cua_node/lib/node_modules"
NODE_REPL_NODE_PATH = "/Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node"
CODEX_HOME = "$HOME/.codex"

the running Node REPL exposes an empty immutable environment:

{
  "moduleDirs": null,
  "nodePath": null,
  "codexHome": null,
  "envKeys": [],
  "frozen": true
}

(undefined values are represented as null above for readability.)

Attempting to add the missing properties at runtime fails with:

Cannot add property NODE_REPL_NODE_MODULE_DIRS, object is not extensible

The bundled runtime itself is valid

The expected macOS entrypoint exists:

/Applications/ChatGPT.app/Contents/Resources/cua_node/lib/node_modules/@oai/sky/dist/project/cua/sky_js/src/targets/mac/create_client.js

Importing it directly with the bundled Node.js succeeds:

EXPORTS: [ 'create_client' ]
create_client: function

The cached and app-bundled copies of computer-use-client.mjs also have identical SHA-256 checksums.

Troubleshooting performed

  • Fully quit and restarted the ChatGPT app
  • Rebooted macOS
  • Uninstalled and reinstalled the bundled Computer Use plugin
  • Verified that the Computer Use plugin is enabled
  • Verified the @oai/sky package and macOS entrypoint exist
  • Verified direct import with the bundled Node.js succeeds
  • Verified that config.toml contains the expected Node REPL environment values
  • Retested in a fresh Codex conversation
  • Retested after updating from 26.715.61943 to 26.715.70719

The failure remains:

Computer Use could not load @oai/sky from the cua_node runtime

This confirms that the issue persists in 26.715.70719 and appears to be caused by the Node REPL startup environment not being propagated into the immutable globalThis.nodeRepl.env object.

hidakat · 1 month ago

Additional impact: the same empty nodeRepl.env also breaks both the bundled Browser plugin and the Chrome plugin.

Browser / Chrome behavior

  • Bundled in-app Browser: fails during initial connection
  • Chrome plugin: fails at the same initialization stage
  • Shared error:
privileged native pipe bridge is not available; browser-client is not trusted

The failure occurs before any browser UI, Chrome extension, or Accessibility interaction.

Runtime inspection shows that the environment object is empty, so the trust information normally supplied through the Node REPL environment is also missing, including the trusted browser-client SHA-256 values and trusted code paths.

This suggests the regression is not specific to Computer Use itself. It appears to affect the shared Node REPL startup / trust-information propagation path used by Computer Use, Browser, and Chrome integrations.

pioneerAlone · 1 month ago

Confirmed on the exact same build: ChatGPT 26.715.70719 + plugin 1.0.1000451 + @oai/sky 0.4.20 + Apple Silicon. codex doctor reports js_repl = false and [mcp_servers.computer-use] ends up enabled = false after every restart.

A few additional observations from digging on my end that might help narrow this down — they look like three separate but interlocking bugs on this build:

  1. Codex rewrites [mcp_servers.computer-use] on every restart, even if I run codex mcp add with an absolute path + enabled = true. After the next restart the block is back to command = "./Codex Computer Use.app/...", cwd = ".", enabled = false. Looks related to #33635.
  1. The bundled .mcp.json uses relative paths (./Codex Computer Use.app/... with cwd = ".") that Codex resolves against the user's CWD (~/Documents/ppt in my case) instead of the plugin directory. So even after (1) the command stays unresolvable and the server is re-disabled.
  1. The bundled Codex Computer Use.app has an invalid code signature:

``
codesign --verify --deep --strict → invalid signature (code or signature have been modified)
Info.plist=not bound
Authority=(unavailable)
Runtime Version=26.1.0
`
Ad-hoc re-signing gets LaunchServices to register the bundle, but the empty
nodeRepl.env from this issue still blocks @oai/sky from loading, so SkyComputerUseService` IPC connect times out anyway.

In combination, this makes Codex Computer Use non-functional on 26.715.70719 without manual intervention after every restart. uninstall + reinstall of the bundled Computer Use plugin does not help (matches what @hidakat already tried above).

Environment for cross-reference:

  • ChatGPT.app CFBundleVersion: 5650
  • macOS 14.4.1 (23E224), Apple Silicon
  • Doctor: js_repl = false
hidakat · 1 month ago

Follow-up to my earlier report: https://github.com/openai/codex/issues/34471#issuecomment-5039016783

I retested on a newer desktop/runtime combination and was able to get past the original @oai/sky loading failure, but a second failure now appears at get_app_state().

Current environment

  • ChatGPT app: 26.721.31836 (build 5828)
  • Computer Use plugin: 1.0.1000502
  • @oai/sky: 0.5.2
  • macOS: 26.5.2 (build 25F84), Apple Silicon (arm64)

Partial recovery of nodeRepl.env

The bundled Node REPL kernel constructs the model-visible environment using:

pickEnv(process.env, process.env.NODE_REPL_UNTRUSTED_ENV_ALLOWLIST)

The required Computer Use variables were present in the node_repl, codex sandbox, and final JavaScript kernel process environments, but NODE_REPL_UNTRUSTED_ENV_ALLOWLIST was absent, so globalThis.nodeRepl.env remained an empty frozen object.

For diagnostic purposes, I made only these config-level changes:

  • allowed the existing Computer Use / Node REPL variable names through shell_environment_policy.include_only
  • set a narrow NODE_REPL_UNTRUSTED_ENV_ALLOWLIST containing only those existing variables

The desktop app removes an unknown NODE_REPL_UNTRUSTED_ENV_ALLOWLIST entry from [mcp_servers.node_repl.env] during startup reconciliation, so the diagnostic value only persisted when placed under the user-managed [shell_environment_policy.set] section.

After resetting the JavaScript kernel:

  • globalThis.nodeRepl.env contained the expected 14 variables and remained frozen
  • the official computer-use-client.mjs successfully loaded @oai/sky
  • the Computer Use runtime initialized successfully
  • sky.list_apps() succeeded and returned 45 applications

I did not modify plugin code, trusted hash values, trusted path values, the app bundle, native-pipe checks, or code signing.

Remaining failure at get_app_state()

The next read-only smoke tests did not complete:

  • Finder: Sky Computer Use request timed out
  • System Settings: JavaScript execution timed out after 30 seconds and the kernel reset

Both macOS permissions are already enabled for the Computer Use app:

  • Accessibility
  • Screen & System Audio Recording

Relevant SkyComputerUseService logs show:

  • repeated TCC access requests
  • a hidden/off-screen Permissions window
  • repeated ScreenCaptureKit: Invalid frame status
  • one startup error: Could not look up the Guardian Mach bootstrap rendezvous port.

Code-signing observation on the current build

For both the installed service at ~/.codex/computer-use/Codex Computer Use.app and the copy bundled inside ChatGPT.app:

codesign --verify --deep --strict
→ invalid signature (code or signature have been modified)

Additional details:

  • Bundle ID: com.openai.sky.CUAService
  • Team ID: 2DC432GLL2
  • Computer Use app version: 26.721.1000502
  • the main executable SHA-256 matches between the bundled and installed copies
  • _CodeSignature/CodeResources also matches between both copies

So the installed copy does not appear to have been locally modified relative to the bundled source.

This suggests the original empty-nodeRepl.env problem and the later Accessibility/ScreenCapture failure are separate layers: populating the untrusted env allowlist restores @oai/sky and list_apps(), but get_app_state() still stalls in the signed Computer Use service / TCC / ScreenCapture path.

hidakat · 1 month ago

Follow-up: functional recovery on ChatGPT 26.721.41059 (build 5848)

Environment

  • ChatGPT app: 26.721.41059 (build 5848)
  • Computer Use service/plugin: 1.0.1000502
  • @oai/sky: 0.5.2
  • macOS: 26.5.2 (build 25F84), Apple Silicon (arm64)

Configuration retained from the previous test

The narrow config-level workaround described in my previous comment is still present:

  • the existing Computer Use / Node REPL variable names are included in shell_environment_policy.include_only
  • NODE_REPL_UNTRUSTED_ENV_ALLOWLIST is set under [shell_environment_policy.set]
  • the allowlist contains only the 14 existing Computer Use / Node REPL variables

I did not modify plugin code, trusted hashes, trusted paths, native-pipe checks, code signing, or either app bundle.

Results after updating and restarting

  • globalThis.nodeRepl.env contains the expected 14 variables and remains frozen
  • the official computer-use-client.mjs wrapper initializes successfully
  • sky.list_apps() succeeds and returns 45 applications
  • Finder get_app_state() succeeds in about one second
  • Accessibility text is present
  • ScreenCapture output is present
  • Calculator end-to-end action test succeeds:
  • read initial value 0
  • click 7
  • verify value changed to 7
  • click Clear
  • verify value returned to 0
  • Firefox automation through Computer Use succeeds using bundle ID org.mozilla.firefox:
  • create a new tab
  • navigate to https://example.com/
  • verify the page title/content
  • close the test tab
  • The dedicated Chrome plugin also succeeds:
  • connect through the extension backend
  • create a new tab
  • navigate to https://example.com/
  • read the title, URL, and DOM
  • clean up the test tab

App display-name targeting was occasionally unstable, but the documented bundle-ID fallback completed successfully.

This environment is now functionally recovered for both Computer Use and the Chrome plugin.

The recovery has been verified through end-to-end, reversible UI and browser automation tests—not only initialization or app enumeration.

Interpretation / caveats

This does not prove that 26.721.41059 automatically fixes the original empty-nodeRepl.env problem, because the narrow config workaround remains enabled. The Computer Use service and @oai/sky versions are also unchanged.

The update is consistent with fixing the later get_app_state() / ScreenCapture failure, but I cannot isolate the app update from restart/process-state effects.

I have not repeated the strict code-signature verification on this build, so I am not claiming that the earlier signing observation has been resolved.

rileyjameson · 27 days ago

Still reproducible on macOS with ChatGPT/Codex 26.727.40816, Computer Use 1.0.1000550, and @oai/sky 0.6.2. nodeRepl.env is empty and frozen, producing the same Computer Use could not load @oai/sky from the cua_node runtime error. The bundled runtime is present and imports successfully outside the Node REPL bridge, and the installed app passes strict code-signature verification.

Feedback/thread ID with diagnostics: 019fb9d2-ad28-7860-8583-9efcb482face

antonreshetov · 27 days ago

The cause in my case was a custom restrictive shell_environment_policy filtering out the environment variables required by Codex’s Node REPL and Computer Use.

The workaround is either:

  1. remove the custom shell_environment_policy; or
  2. explicitly include the Node REPL / Computer Use variables already defined under [mcp_servers.node_repl.env] and set NODE_REPL_UNTRUSTED_ENV_ALLOWLIST under [shell_environment_policy.set].

After updating config.toml and fully restarting the app, Computer Use started working.

So if this issue occurs, check whether a custom shell_environment_policy, especially include_only, is stripping Codex’s required environment variables.