[macOS] Chrome plugin bootstrap fails with "Cannot redefine property: process" in node_repl

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

• #32925
• #32936
• #32938
• #32934
• #32946

Powered by Codex Action

Local cache-only workaround verified on macOS for app/plugin version 26.707.71524.

The workaround described in #32941 (adding globalThis.processShim, wrapping the global assignments in try/catch, and rewriting global.process.<field> reads) got past the original exception on this machine, but then failed during module evaluation with:

Cannot read properties of undefined (reading 'node')

A module-scoped shim worked instead.

Patch

The Browser and Chrome copies of browser-client.mjs were byte-identical before patching (original SHA-256: 57ee77a283eb230c6c6d47353af13a25cec4c331b511868c8fbf7ccd3dd1b2f6).

Affected cached files:

~/.codex/plugins/cache/openai-bundled/chrome/26.707.71524/scripts/browser-client.mjs
~/.codex/plugins/cache/openai-bundled/browser/26.707.71524/scripts/browser-client.mjs

Back up both files first. Then replace:

globalThis.process = processShim;
globalThis.global = globalThis.global ?? globalThis;
globalThis.global.process = processShim;

with:

const process = processShim;
const global = Object.create(globalThis, {
  process: {
    value: processShim,
    writable: true,
    configurable: true,
  },
});

This keeps the complete processShim available to bare process.* and global.process.* references inside the generated bundle without attempting to overwrite the managed Node REPL's protected globalThis.process.

Verification performed

• Both patched files passed the app-bundled Node --check.
• The Chrome browser client imported successfully.
• setupBrowserRuntime({ globals: globalThis }) completed.
• The Chrome backend documentation loaded successfully.
• The extension connection succeeded and open Chrome tabs could be enumerated.
• No page contents, titles, URLs, cookies, or browsing history were read during verification.

Patched SHA-256 in this environment: 838cbc8b921e97bc24d0fc81986cae5889e77dca97325f60be43c8454185f329.

This is an unsupported local workaround. A ChatGPT/Codex or bundled-plugin update may overwrite the cached files. After an update, test the unmodified upstream bundle first and do not blindly reapply this patch unless the same source pattern and failure are still present.

Additional macOS reproduction, with a potentially relevant multi-user setup.

Environment:

• ChatGPT/Codex desktop app: 26.707.72221 (build 5307)
• macOS: 15.7.7 (24G720), Apple Silicon
• Google Chrome: 150.0.7871.115
• Bundled Chrome plugin cache: openai-bundled/chrome/26.707.51957
• Codex task ID: 019f63c5-f437-7063-9fac-07be96611a53

Setup:

• One Mac with two macOS user accounts logged in concurrently via Fast User Switching.
• Codex and Chrome are used in both user sessions.
• I suspect this topology may contribute, but I have not isolated it as the cause.

Reproduction:

1. In one macOS user session, open a Codex task.
2. Invoke @chrome.
3. The documented Chrome bootstrap dynamically imports browser-client.mjs.
4. Import fails immediately and consistently, including after resetting the JavaScript kernel and retrying several times:

TypeError: Cannot redefine property: process
    at $HOME/.codex/plugins/cache/openai-bundled/chrome/26.707.51957/scripts/browser-client.mjs:33:22
    at SourceTextModule.evaluate (node:internal/vm/module:233:26)
    at importResolved (.../kernel.js:905:27)

Diagnostics:

• Chrome was running.
• The Chrome extension/native-host installation checks succeeded.
• The native-host process was active for the expected extension.
• Importing the browser client alone reproduces the failure before Chrome discovery.
• Resetting the Node/JS kernel and retrying at least three times did not help.
• Codex Computer Use could attach to the same Chrome session, so Chrome itself was available; the failure appears specific to the Chrome plugin bootstrap.

Expected:

• The Chrome plugin should initialize independently for each macOS user session and proceed to browser discovery.
• If simultaneous user sessions are unsupported, it should return an actionable error instead of failing while redefining the protected global process.

Actual:

• @chrome is completely blocked before it can discover or control any tab.

This appears to confirm the same protected-process collision on another macOS/app/plugin version. The two-user/two-Chrome topology is included as additional context only, not as a confirmed root cause.