In-app Browser bootstrap fails because node_repl rejects node:process import

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

• #34372

Powered by Codex Action

Confirmed on Windows 11 with the current Codex App / bundled Browser version 26.721.81911.

Observed error:

Importing module "node:process" is not allowed in node_repl

Additional validation performed:

• Fully restarted the Codex App.
• Forced a one-time official bundled-plugin reconcile for browser and chrome.
• Verified that both plugin caches match the App bundle version 26.721.81911.
• Confirmed that cache drift was resolved before retesting.
• The failure still occurs while importing scripts/browser-client.mjs, before setupBrowserRuntime() can initialize globalThis.agent.
• After the failed import, agent remains undefined as a downstream consequence.
• An older cached client is not a viable workaround because it is incompatible with the current packaged browser documentation/protocol.

This appears to be the same cross-platform runtime compatibility regression reported for Linux in #36175: the trusted bundled Browser client statically imports node:process, while the supported node_repl environment rejects that module before Browser Runtime initialization.

This Windows reproduction helps rule out plugin-cache drift, stale installation, and platform-specific browser discovery as the primary cause.

Confirmed again on Windows with the current 26.803 app/plugin generation. This is still reproducible after the earlier #32925 process-shim fix.

Environment

• Platform: Windows x64, 25H2, build 26200.8973
• ChatGPT/Codex app package: OpenAI.Codex_26.803.10989.0_x64
• Bundled Browser plugin: 26.803.81509
• Browser runtime: cua-node 0.0.6/20260808024807-83088b378224
• Runtime Node: 24.14.0
• In-app Browser tab was visibly open when reproduced

Exact failure

Following the Browser skill's prescribed bootstrap with the installed absolute scripts/browser-client.mjs path fails during module import:

Importing module "node:process" is not allowed in node_repl

The generated client contains a static import equivalent to:

import { env as xm } from "node:process";

The failure occurs before setupBrowserRuntime(), browser discovery, tab enumeration, navigation, DOM inspection, screenshots, authentication, or any website-specific action. The open page and its data were not inspected.

A direct runtime-shape check also showed that the task runtime does not expose a normal global process object (process absent; no versions or on), so the bundle cannot simply rely on the host global instead.

Cache/source reconciliation proof

The installed cache and bundled marketplace source are identical:

• Installed cache version: 26.803.81509
• Bundled marketplace version: 26.803.81509
• Installed browser-client.mjs SHA-256:

8676FACA28EDDB6424D4B54116FE8305E2DA6A0CA4E5271E8758FC3C55C3B8FC

• Marketplace browser-client.mjs SHA-256:

8676FACA28EDDB6424D4B54116FE8305E2DA6A0CA4E5271E8758FC3C55C3B8FC

Therefore, deleting/rebuilding the plugin cache or reinstalling the bundled Browser plugin will currently recreate the same incompatible client. This rules out stale cache drift for this reproduction.

Relationship to #32925

#32925 failed because an earlier generated client attempted to redefine globalThis.process. The current 26.803 client no longer fails at that assignment; it now fails because the restricted runtime rejects the client's static node:process import. This appears to be a distinct regression at the same generated-client/runtime contract boundary.

Suggested fix and regression coverage

• Remove the static node:process dependency from the generated Browser client, consistently use the bundle's safe process/environment shim, or explicitly permit only the required safe export for the trusted bundled client.
• Add a release smoke test that imports the exact shipped browser-client.mjs inside the exact shipped restricted node_repl runtime, obtains the iab binding, enumerates an open tab, and performs one harmless metadata/DOM read.

Official Browser documentation says the desktop integration should be able to inspect rendered state and take screenshots, but this bootstrap failure prevents reaching that supported behavior.

Confirmed on Windows with the Chrome extension backend, not only the in-app Browser.

Environment

• Platform: Microsoft Windows NT 10.0.26200.0 x64
• ChatGPT/Codex app package: OpenAI.Codex_26.803.10989.0_x64
• Bundled Browser plugin: 26.803.81509
• Bundled Chrome plugin: 26.803.81509
• ChatGPT Chrome extension: 1.2.27259.19709_0
• Selected Chrome profile: Default
• Feedback/conversation ID: 019ffc8a-9a63-7aa2-9924-2c835d7f8473

Chrome connection checks

The Chrome-side installation and native messaging connection appear healthy:

• Google Chrome is running.
• The ChatGPT Chrome extension is installed, registered, and enabled.
• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension exists and points to the expected manifest.
• The manifest passes direct validation with correct: true.
• The manifest contains the expected host name and allowed extension origins.
• extension-host.exe is running from the path referenced by the manifest.

Exact failure

Following the installed Chrome/Browser skill bootstrap fails during the import of scripts/browser-client.mjs:

Importing module "node:process" is not allowed in node_repl

The failure occurs before setupBrowserRuntime(), browser discovery, agent.browsers.get("chrome"), or tab enumeration. The test was retried after two seconds with the same result.

Troubleshooting already performed

• Removed the separate legacy ChatGPT Desktop application, leaving only OpenAI.Codex.
• Repaired Codex through Windows Advanced Options.
• Restarted Windows.
• Opened Chrome before Codex.
• Confirmed that the repair restored the Windows native-host registry entry.
• Retested from a new Codex conversation.
• Repeated the Browser runtime bootstrap twice.

This extends the existing reproduction to the external Chrome extension backend on the current Windows 26.803 app/plugin generation. The native host is available and running, but the bundled browser client cannot initialize because its static node:process import is rejected by the supported node_repl runtime.

Confirmed on macOS with the bundled Chrome plugin version 26.803.61601.

The active Chrome tab can be read through getTabContext, but interactive
browser control fails immediately while importing browser-client.mjs:

Importing module "node:process" is not allowed in node_repl

The installed bundle still contains:
import { env as xm } from "node:process";

Reinstalling/updating Codex, restarting Chrome, and rebooting macOS did
not resolve it. This also affects the external Chrome integration, not
only the in-app Browser.

Confirmed on macOS 27.0 (Apple Silicon) with Codex CLI 0.149.0 and bundled Chrome plugin 26.727.51351.

Following the plugin SKILL.md bootstrap exactly fails immediately with:

Importing module "node:process" is not allowed in node_repl

The failure occurs before browser discovery, so it is independent of Chrome login or extension state. The current bundled browser-client.mjs still contains a static node:process env import. On macOS, that import is not needed for the macOS code path; replacing it with a safe runtime env lookup or making it platform-conditional should allow the trusted client to load.

This blocks the standard Chrome-control workflow despite a connected macOS node with browser, screen-recording, Accessibility, and AppleScript permissions.

Update — still reproducible on Windows 26.818 (2026-08-23)

The failure persists after upgrading from the environment in my previous comment.

Current environment

• Platform: Windows x64
• Codex Desktop package/process: OpenAI.Codex_26.818.5229.0_x64
• Bundled Chrome plugin: 26.818.41509
• Previous reproduction/comment: https://github.com/openai/codex/issues/35224#issuecomment-5285576583

Fresh reproduction

1. Fully restarted Codex Desktop.
2. Started a local test application at http://localhost:8501/.
3. Verified independently that the target was reachable and returned HTTP/1.1 200 OK.
4. Initialized the installed Chrome plugin through its documented browser-client.mjs bootstrap.
5. The trusted execution process exited immediately, before browser selection, tab discovery, or navigation:

trusted Node process exited unexpectedly; kernel reset, rerun your request

1. Reset the JavaScript kernel and repeated the bootstrap once. It failed identically.

Additional isolation evidence

Using the same bundled runtime in a temporary diagnostic session with the Node sandbox disabled was able to bind to the real Chrome extension backend and enumerate an existing Chrome tab. This shows that Chrome, the extension/native bridge, and the browser binding are reachable outside the failing trusted/sandboxed path.

That diagnostic is not a workaround or a successful end-to-end browser test: navigation then failed closed because the browser security/auto-review check was unavailable. No security control was bypassed, no persistent sandbox change was made, and the normal Codex-integrated Chrome path remains unusable.

Compared with the earlier reproduction, the outward error has changed from the explicit node:process rejection to a generic trusted-process exit, but the failure is still before any website-specific action. This continues to point to the Codex Desktop trusted execution / sandbox / code-mode-host layer rather than the local website or Chrome installation.

macOS update: CLI failed with a stale bundle, then recovered after bundle refresh

I reproduced this on macOS 26.5.2 (arm64) with Codex CLI 0.149.1 and ChatGPT/Codex Desktop 26.818.61809 (build 7019).

Two fresh CLI sessions loaded cached Chrome plugin 26.803.61601 and failed before browser discovery with:

Importing module "node:process" is not allowed in node_repl

Computer Use in the same CLI runtime also failed before reaching macOS with:

process is not defined

Chrome itself was running; the ChatGPT extension was enabled in the intended profile; and the native-host manifest was present and correct. Restarting the JS kernel and reinstalling the Chrome extension did not resolve the original failure.

The local desktop app had been updated, but the cached browser and chrome bundles were still 26.803.61601. I backed up and removed those two stale cache directories, stopped only the ChatGPT for Chrome host, fully restarted the desktop app, and let it regenerate both bundles as 26.818.61809.

After regeneration:

• A Codex Desktop task successfully initialized Chrome control, enumerated an existing signed-in tab, claimed it, and read its DOM.
• A completely fresh read-only codex exec session using the standalone CLI 0.149.1 also initialized Chrome control successfully and enumerated existing tabs without modifying them.
• The regenerated 26.818.61809 client no longer contains the rejected static node:process import seen in 26.803.61601.

This instance is resolved locally. The useful product finding is that current CLI 0.149.1 could continue selecting an older cached bundled plugin after the desktop app had updated. Automatic cache reconciliation (or an explicit version-mismatch diagnostic) would prevent the CLI-only failure and avoid unnecessary extension/native-host troubleshooting.

This may also help distinguish the current broader Computer Use reports (for example #40394) from the specific static-import/cache-skew failure tracked here.

Follow-up after the cache refresh:

The original Importing module "node:process" is not allowed in node_repl failure is resolved locally. A full ChatGPT/Codex Desktop restart regenerated the browser and chrome bundles to 26.818.41509; the rejected static import is absent from the regenerated Chrome bundle.

However, browser bootstrap still fails when Codex is launched through the OpenClaw adapter, with a different error:

Browser use requires a trusted Node REPL browser service

The new browser-client.mjs explicitly requires nodeRepl.rpc. In this integration the Node REPL context has cwd, env, homeDir, tmpDir, requestMeta, write, and emitImage, but no rpc, so it cannot create a browser service at all. This happens before Chrome tab discovery or extension communication.

Environment:

• ChatGPT/Codex Desktop: 26.818.41509
• Codex CLI: 0.149.0-alpha.4.1
• OpenClaw: 2026.7.1-2
• @openclaw/codex: 2026.7.1-1 (the latest published adapter version at the time of testing)

So the stale-bundle issue is fixed, but this remaining failure appears to need a trusted browser-RPC bridge for the OpenClaw/Codex app-server integration. It is distinct from the cache-skew failure in the original report.

I can independently reproduce this issue on macOS while using Codex in ChatGPT Work Mode with GPT-5.6 Terra.

The Playwright MCP browser fails before creating a browser connection with:

Importing module "node:process" is not allowed in node_repl

Reproduction notes:

• The failure persisted across multiple newly created Codex sessions.
• Local Playwright Codegen works successfully.
• No website navigation or authentication occurred.
• No REST APIs were called.
• No repository files were modified.
• No alternative browser/tool was substituted during the failed attempts.

Observed on August 26, 2026 at approximately 1:30 AM IST (UTC+05:30).

This appears to confirm that the failure is in the hosted browser/MCP runtime rather than in the target repository or local Playwright installation.