Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy

Resolved 💬 63 comments Opened Jun 20, 2026 by bobchristof-gp Closed Jun 21, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Title: Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy

Component: Codex Desktop / bundled node_repl MCP / Chrome plugin
Version: Codex Desktop 26.616.41845, build 4198
Bundled CLI: codex-cli 0.142.0-alpha.6
OS: macOS 26.5.1 arm64

Problem:
Chrome plugin/browser automation cannot run because mcp__node_repl.js fails before executing any JS.

Error:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Expected:
mcp__node_repl.js should execute a minimal JS call, or Codex Desktop should provide the sandboxPolicy field expected by bundled node_repl.

Observed:
Every call to mcp__node_repl.js fails before JS execution.

Minimal repro:

  1. Enable/use bundled Chrome plugin in Codex Desktop.
  2. Start a local thread with sandbox_mode = danger-full-access / approval_policy = never.
  3. Expose node_repl via tool search.
  4. Run:

nodeRepl.write(JSON.stringify({ ok: true }))

  1. Tool fails with:

codex/sandbox-state-meta: missing field sandboxPolicy

Investigation:

  • Current thread context logs show sandbox_policy snake_case.
  • Bundled node_repl binary expects sandboxPolicy camelCase inside codex/sandbox-state-meta.
  • Restarting Codex Desktop did not fix it.
  • Attempted config workaround:

[mcp_servers.node_repl]
args = ["--disable-sandbox"]
But Codex Desktop launched node_repl without that arg / appears to ignore generated TOML args for this bundled server.

  • Restored config to normal.

Impact:
Chrome plugin automation is blocked, including Shopify admin/browser tasks.

View original on GitHub ↗

63 Comments

derekNeedCoffee · 1 month ago

I am hitting the same issue on macOS.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • macOS: 26.5 (25F71), arm64
  • Chrome plugin path: chrome@openai-bundled, app build 26.616.41845
  • Codex Chrome Extension is installed and enabled in the selected Default profile; extension version reported locally as 1.1.5_0
  • Native messaging host manifest check passes: exists=true, correct=true, problem=null

Observed behavior:

  • A minimal mcp__node_repl.js call such as nodeRepl.write('ok') fails before user JS runs:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Impact:

  • The Chrome plugin cannot bootstrap because node_repl/js fails before it can import the browser client or call agent.browsers.get('extension').
  • This blocks Chrome-backed workflows even though the Chrome extension and native host appear healthy.

Additional local debugging:

  • The thread context records sandbox_policy in snake_case.
  • The bundled node_repl appears to require sandboxPolicy in camelCase inside codex/sandbox-state-meta.
  • In a standalone MCP probe, the same malformed/snake_case sandbox meta reproduces this exact error; passing camelCase sandboxPolicy succeeds.
  • A local wrapper that normalizes sandbox_policy -> sandboxPolicy works in a standalone probe, but Codex Desktop appears to launch the bundled node_repl directly / rewrite or ignore mcp_servers.node_repl command/args, so this is not a stable workaround from ~/.codex/config.toml.
andryserbice · 1 month ago

Independent Windows reproduction from Codex Desktop 26.616.5445.0 on Windows 10 IoT Enterprise LTSC 10.0.19044 x64. Bundled Browser plugin 26.616.41845 is installed and enabled; bundled CLI/app-server is codex-cli 0.142.0-alpha.6. The exact codex/sandbox-state-meta: missing field sandboxPolicy error occurs before user JavaScript or navigation, in both an existing thread and a fresh thread after a full app restart. Session metadata does contain sandbox policy danger-full-access and permission profile disabled, but the field expected by node_repl is still absent. This is not site- or project-specific and makes Browser automation completely unavailable while ordinary shell/file tools continue to work. Related Windows report: #29193.

davidwushi1145 · 1 month ago

I’m hitting the same issue on macOS.

Environment:

  • Codex Desktop: 26.616.41845
  • CLI observed earlier: codex-cli 0.141.0
  • OS: macOS
  • Chrome plugin: chrome@openai-bundled enabled
  • Browser plugin: browser@openai-bundled enabled

Observed behavior:

Chrome/Browser automation fails before any browser page or user JavaScript is accessed. The tool is discovered and invoked, but node_repl/js fails internally with:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

This happens even after reinstalling Codex and removing the manually registered node_repl MCP from codex mcp list.

My current understanding is that this is not the older “Node REPL tool is not exposed” failure mode. In my case, the tool call reaches node_repl/js, but the bundled Node REPL bridge expects a camelCase sandboxPolicy field from codex/sandbox-state-meta, while the active session appears to provide sandbox metadata in a different shape.

Impact:

The Chrome plugin cannot bootstrap, so Chrome-backed workflows fail even though the Chrome extension/plugin appears installed and enabled. Regular shell access still works.

This looks consistent with the root cause described above: a schema mismatch between Codex Desktop 26.616.41845 and the bundled node_repl / Chrome plugin runtime.

fduch-stranger · 1 month ago

I can reproduce this on macOS in Codex Desktop 26.616.41845.

Additional evidence from local Codex session history in the same project:

  • In-app Browser control worked earlier in this same project with Browser plugin/runtime 26.616.32156.
  • The successful bootstrap connected to backend iab, opened http://localhost:5173/, got title Age of Agents, and inspected the DOM through tab.playwright.domSnapshot().
  • After update to Browser plugin/runtime 26.616.41845, the same Browser bootstrap fails before any user JS runs:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`
  • A minimal nodeRepl.write("ok") call fails with the same error, so this is not caused by the Browser client import, Playwright, or project code.
  • Changing thread permissions / full access does not help.
  • Attempting to work around this with --disable-sandbox in mcp_servers.node_repl.args is not effective because Codex Desktop appears to rewrite or ignore the bundled node_repl args.

This looks like a regression between 26.616.32156 and 26.616.41845, where Desktop/app-server no longer passes the sandboxPolicy field expected by bundled node_repl/js.

joshp123 · 1 month ago

I'm experiencing the same issue; couple of additional data points:

  • chrome plugin isn't visible in plugin dropdown/menu either

<img width="803" height="222" alt="Image" src="https://github.com/user-attachments/assets/09287de5-25eb-47cf-aae0-8f6653f8e4aa" />

  • feedback uploaded with this ID: 019ee476-ed0c-7d03-827b-fcee6c5dbb0a in which codex debugs the session itself.
cameronfairbairn · 1 month ago

I can reproduce the same failure on macOS with the current Desktop build.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Bundled CLI: codex-cli 0.142.0-alpha.6
  • macOS: 26.3 build 25D125, arm64
  • Chrome plugin path used by the session: chrome@openai-bundled runtime 26.616.41845
  • Chrome: 149.0.7827.115
  • Codex Chrome Extension: installed/enabled in the selected Default profile, extension version 1.1.5_0
  • Native messaging host manifest check: exists=true, correct=true, expected origin present

Minimal repro in the affected Codex thread:

nodeRepl.write('ping')

Actual result, before any user JS executes:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Additional recovery attempts / checks:

  • Fully quit Chrome via AppleScript, verified old Google Chrome and extension-host processes exited.
  • Reopened Chrome using the bundled plugin script scripts/open-chrome-window.js; fresh Chrome and extension-host processes started.
  • Re-ran the Chrome plugin diagnostics:
  • scripts/chrome-is-running.js --check -> OK
  • scripts/check-extension-installed.js --json -> installed/enabled true for selected profile
  • scripts/check-native-host-manifest.js --json -> manifest correct
  • Restarted Codex Desktop and retried.
  • The same sandboxPolicy error persists.

Impact:

  • Chrome/Browser automation cannot bootstrap because node_repl/js fails before importing the browser client or calling agent.browsers.get('extension').
  • This does not appear to be a Chrome install, extension enablement, native-host manifest, or local page issue.
giufrat · 1 month ago

Confirmed on macOS 26.5.1 arm64 with Codex Desktop 26.616.41845 (build 4198) and bundled runtime 0.142.0-alpha.6.

Additional evidence:

  • Codex.app was updated locally at 10:12 on 2026-06-20.
  • The same nested node_repl/js Browser workflow succeeded before the update and began failing after it.
  • The failure affects both newly created threads and an older thread that successfully controlled the in-app browser before the update, so thread recreation does not resolve it.
  • The recorded turn context contains sandbox_policy: {"type":"danger-full-access"}.
  • Desktop global state also contains sandboxPolicy: {"type":"dangerFullAccess"} for the affected thread.
  • Despite those values being present upstream, node_repl/js rejects the MCP call before executing JavaScript with:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

  • js_reset still works, confirming the failure is specific to the execution call requiring sandbox metadata.
  • Attempting to supply _meta explicitly is rejected by the exposed tool schema, so there is no agent-side workaround.
  • This blocks the bundled in-app Browser backend; it is unrelated to the target website or authentication state.

This looks like a regression in Desktop/app-server metadata propagation introduced with the current build.

mahidalhan · 1 month ago

Additional macOS confirmation from my local setup after updating the standalone runtime:

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Standalone CLI/app-server after codex update: codex-cli 0.142.0-alpha.7
  • App-server status: running on 0.142.0-alpha.7
  • OS: macOS arm64
  • Project feature flags: browser_use, browser_use_external, in_app_browser, plugins, computer_use, apps, and enable_mcp_apps all effectively enabled in the project

Minimal repro still fails after the standalone update and app-server restart:

nodeRepl.write("ok")

Result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Important extra detail: codex mcp list --json still wires node_repl to the Desktop app bundle:

/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
BROWSER_USE_CODEX_APP_VERSION=26.616.41845
CODEX_CLI_PATH=/Applications/Codex.app/Contents/Resources/codex

I also inspected the public rust-v0.142.0-alpha.7 macOS DMG from the GitHub release; it contains CLI payloads (codex, codex-responses-api-proxy) rather than a replacement Codex.app, so that update path does not refresh the desktop-bundled node_repl.

This makes the failure look independent of the project/user feature flags and independent of the standalone CLI/app-server version: the stale/mismatched Desktop-bundled node_repl path is still the component rejecting the sandbox metadata before any user JS runs.

Astra-Ranger · 1 month ago

same on Codex Desktop 26.616.41845 build 4198, macOS Darwin 25.5.0 arm64, minimal nodeRepl.write('ping') fails with the same missing sandboxPolicy error.

giufrat · 1 month ago

Additional macOS confirmation after updating the standalone runtime:

Environment

  • Codex Desktop: 26.616.41845, build 4198
  • Standalone CLI/app-server after codex update: codex-cli 0.142.0-alpha.7
  • App-server status: running on 0.142.0-alpha.7
  • OS: macOS arm64
  • Project feature flags: browser_use, browser_use_external, in_app_browser, plugins, computer_use, apps, and enable_mcp_apps all effectively enabled

Minimal repro

The failure remains after the standalone update and app-server restart:

nodeRepl.write("ok")

Result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Important additional detail

codex mcp list --json still wires node_repl to the Desktop app bundle:

/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
BROWSER_USE_CODEX_APP_VERSION=26.616.41845
CODEX_CLI_PATH=/Applications/Codex.app/Contents/Resources/codex

The public rust-v0.142.0-alpha.7 macOS DMG from the GitHub release contains CLI payloads (codex, codex-responses-api-proxy) rather than a replacement Codex.app, so that update path does not refresh the Desktop-bundled node_repl.

This makes the failure independent of project/user feature flags and independent of the standalone CLI/app-server version: the Desktop-bundled node_repl path remains the component rejecting the sandbox metadata before any user JavaScript runs.

matthiasroder · 1 month ago

Additional macOS data point from the same 26.616.41845 / build 4198 class of failure.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Bundled CLI: codex-cli 0.142.0-alpha.6
  • macOS arm64
  • chrome@openai-bundled/browser@openai-bundled: 26.616.41845
  • Chrome extension: 1.1.5_0, installed/enabled in the selected Default profile
  • Native messaging manifest check passes

What I tried:

  • Reinstalled Codex Desktop
  • Removed/reinstalled the Chrome plugin from the Codex plugin UI
  • Fully restarted Codex and Chrome
  • Re-ran the bundled Chrome checks; extension and manifest remain OK
  • Confirmed a minimal built-in node_repl/js call still fails before JS execution with:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Additional bridge evidence:

  • The plugin UI reinstall rewrote ~/.codex/chrome-native-hosts-v2.json to the live Desktop process and versioned plugin paths.
  • After the UI reinstall, extension-host-config.json was missing under the versioned extension-host/macos/arm64 directory. Recreating it with the bundled scripts/installManifest.mjs restored that config file, but did not make the Chrome backend discoverable.
  • Using a local wrapper that normalizes the missing sandbox metadata lets JS execute far enough to import the bundled browser client, but agent.browsers.list() still returns [].
  • Instrumenting the bundled browser client showed:
  • backendCounts: { cdp: 0, extension: 0, iab: 0 }
  • reason: no-iab-backends
  • failures like backend-info-request/native pipe closed before response
  • lsof shows the Codex process and extension-host process holding separate /tmp/codex-browser-use/*.sock paths, which looks similar to the socket mismatch described in #21719.

So there appear to be two overlapping problems:

  1. The built-in node_repl/js metadata schema mismatch (sandboxPolicy) described in this issue.
  2. Even after locally bypassing that metadata mismatch, Chrome backend registration/native-host socket association does not complete.
Hamzablm · 1 month ago

I’m seeing the same failure when Codex Desktop tries to connect to Chrome.

Environment:

  • Codex Desktop: 26.616.41845
  • macOS: 26.4.1 (build 25E253)
  • Architecture: arm64
  • Observed: 2026-06-20
  • Workspace access: full access

Reproduction:

  1. Ask Codex Desktop to use the bundled Control Chrome skill.
  2. The skill is read successfully.
  3. At “Connect to Chrome”, the underlying node_repl/js call fails before Chrome can connect.

Exact error:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Expected: the bundled Chrome tool should connect to the existing Chrome session.

stefanmauron · 1 month ago

Error:
codex/sandbox-state-meta: missing field sandboxPolicy

Likely failing area:
Codex/Desktop sandbox state metadata deserialization or migration. The current runtime appears to expect a sandboxPolicy field in sandbox-state metadata, but the loaded state does not contain it.

Codex app:
Bundle identifier: com.openai.codex
Version: 26.616.41845
Bundle build: 4198
App path: /Applications/Codex.app

Host OS:
macOS 26.5.1
Build: 25F80
Darwin kernel: 25.5.0
Architecture: arm64
Hardware model: Mac15,13

Thread/workspace: Worktree had existing uncommitted/untracked changes at time of inspection.

Runtime/sandbox context shown to Codex:
Filesystem sandbox: unrestricted / danger-full-access
Network access: enabled
Approval policy: never
Timezone: Europe/Zurich

Shell/runtime:
Shell: /bin/zsh
TERM: dumb
Node: v26.0.0
npm: 11.16.0

Notable PATH entries:
Includes /Applications/Codex.app/Contents/Resources
Includes /var/run/com.apple.security.cryptexd/codex.system/bootstrap/... paths
Includes /Users/s/.codex/tmp/arg0/...

huangxuanminggithub · 1 month ago

Windows confirmation: I can reproduce the same codex/sandbox-state-meta: missing field sandboxPolicy failure on Codex Desktop 26.616.41845.

Environment:

  • Windows 11 Pro, x64
  • Codex Desktop 26.616.41845
  • Bundled Computer Use plugin enabled
  • Local thread has danger-full-access / approval_policy=never

node_repl/js fails before any user JavaScript executes, including a minimal list-apps/bootstrap call.

Before this, Computer Use consistently failed with:
windows sandbox failed: runner error: CreateProcessAsUserW failed: 5

I changed the local Codex setting from:
[windows]
sandbox = "elevated"

to:
[windows]
sandbox = "unelevated"

and fully restarted Codex. After that, the observed failure changed to:
codex/sandbox-state-meta: missing field sandboxPolicy

This does not prove the CreateProcessAsUserW issue is fully resolved, because the sandboxPolicy error now occurs earlier, before JavaScript/helper initialization. It may indicate two serial Windows failure layers: sandbox process creation and Desktop-to-node_repl sandbox metadata propagation.

maciej · 1 month ago

Additional macOS data point with a narrower repro.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Bundled CLI: codex-cli 0.142.0-alpha.6
  • macOS: 26.5.1, arm64
  • Bundled Chrome/browser runtime: 26.616.41845
  • Active node_repl command: /Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
  • No local wrapper active

In Codex Desktop, even a minimal call fails before user JS executes:

nodeRepl.write('ok')

with:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

I also ran a direct standalone MCP probe against the bundled node_repl binary, outside Codex Desktop. Results:

  1. Complete _meta["codex/sandbox-state-meta"] including sandboxPolicy: succeeds, returns ok.
  2. No _meta at all: succeeds, returns ok.
  3. _meta["codex/sandbox-state-meta"] = {}: fails with the exact same error:
js: codex/sandbox-state-meta: missing field `sandboxPolicy`

So this looks more specific than just "node_repl requires metadata". It appears to reject an empty codex/sandbox-state-meta object, while omitted metadata is accepted. That suggests Codex Desktop/app-server may be forwarding:

{
  "codex/sandbox-state-meta": {}
}

instead of either omitting the field or including the required sandboxPolicy.

This also explains why Chrome/native-host troubleshooting did not help: the failure occurs before the Chrome browser client import or extension connection is attempted.

Ben2248 · 1 month ago

Can confirm this issue on Codex Desktop 26.619.11828. (Windows)
"missing field sandboxPolicy"

hashem-reyi · 1 month ago

can confirm this on windows. the openai updates to codex are a complete mess

PengJack · 1 month ago

The same problem on my macbook pro, the same version 26.616.41845

naivetechan-feifei · 1 month ago

Additional Windows repro from Codex Desktop after today's update.

Environment:

  • Windows Codex Desktop package: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
  • Current bundled Chrome plugin cache: openai-bundled/chrome/26.616.41845
  • Current Codex CLI used by app config: C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe, timestamp 2026-06-20 16:01:18 local time
  • node_repl runtime in config: C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_repl.exe, timestamp 2026-06-17 06:30:45 local time
  • Node runtime: 24.14.0
  • sandbox_mode in config.toml: danger-full-access
  • windows.sandbox in config.toml: elevated

Minimal repro:

nodeRepl.write('ok')

Actual result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Impact:

  • @chrome cannot bootstrap because the required mcp__node_repl__js tool fails before any browser-client code runs.
  • The failure happens even for the minimal nodeRepl.write('ok') call, so it is not a Chrome extension install/setup problem.

Useful comparison:

  • Earlier today, before the update/restart, an older session was able to use node_repl/js successfully with Chrome browser-use metadata and finalize the Chrome session.
  • After the update, new sessions fail before JS execution with missing sandboxPolicy.

Restarting Codex Desktop did not fix it.

zhangyix19 · 1 month ago

Same

MuchemwaMSK · 1 month ago

Confirming the same issue on Windows.
Environment:
Codex Desktop: 26.616.5445.0
Bundled Computer Use runtime: 26.616.41845
Windows, full-access permission profile
A minimal node_repl/js call fails before executing JavaScript:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy
Additional checks:
Computer Use is installed and discovered correctly.
Microsoft Store reports no newer Codex version available.
Only runtime 26.616.41845 is cached locally, so rollback is unavailable.
Explicitly passing _meta.codex/sandbox-state-meta.sandboxPolicy is rejected by the tool schema as an unknown field.
The failure occurs before Computer Use initializes, confirming this is not app- or project-specific..

cnlove7777777-art · 1 month ago

Used up my entire quota, reinstalled the environment, and it turned out to be a bug

aieverything2005 · 1 month ago

I can reproduce this on macOS as well.

Environment

  • Codex Desktop: 26.616.41845 (CFBundleVersion 4198)
  • Bundled Codex CLI: codex-cli 0.142.0-alpha.6
  • System codex CLI: codex-cli 0.126.0-alpha.4
  • OS: macOS
  • Active config:
[mcp_servers.node_repl]
args = []
command = "/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl"
startup_timeout_sec = 120

Symptom

Minimal mcp__node_repl.js calls fail before user JavaScript is executed:

nodeRepl.write("node_repl-js-ok");

Error:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

However, mcp__node_repl.js_reset succeeds:

js kernel reset

So the MCP server itself is reachable, but the js method appears to receive incomplete sandbox metadata.

Impact

This blocks both bundled browser-control surfaces:

  • @Browser / in-app browser, because it needs node_repl/js to bootstrap browser-client.mjs
  • @Chrome, for the same reason

The failure happens before Chrome extension or browser-client setup, so it does not appear to be caused by Chrome login state, extension installation, native host setup, or a specific website.

Local checks performed

  • Removed a prior local wrapper workaround and restored the official bundled node_repl config.
  • Fully restarted Codex Desktop.
  • Confirmed the running process is:
/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
  • Confirmed app logs select the bundled runtime:
BrowserUseThreadConfig ... nodeReplPath=/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
nodeVersionValue=v24.14.0
  • Confirmed the same logs contain the MCP tool-call error:
MCP tool call error: tool call failed for `node_repl/js`
Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Expected

mcp__node_repl.js should receive valid sandbox metadata and execute the minimal nodeRepl.write(...) call.

Actual

mcp__node_repl.js fails during metadata validation with missing sandboxPolicy, while js_reset still works.

qx54 · 1 month ago

Same, the last update rendered the in-app browser unusable.

There should be a way to rollback to an older Codex desktop version.

CJavierSaldana · 1 month ago

I'm hitting the same issue on macOS.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • macOS: 26.5.1 (25F80), arm64
  • Chrome plugin: chrome@openai-bundled enabled
  • Browser plugin: browser@openai-bundled enabled

Observed behavior:

  • Minimal node_repl/js calls fail before any user JavaScript runs:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`
  • Chrome/Browser automation cannot bootstrap because node_repl/js fails before it can reach the browser client or extension bridge.
  • Regular shell/file tools in the same thread still work.

Additional symptom (Chrome profile):

  • Codex does not attach to my existing Chrome profile (the one with all my extensions, logins, and integrations).
  • Instead it launches Chrome with a fresh profile that has zero integrations, so even when Chrome opens, none of my real browser state is available.
  • Between the sandboxPolicy failure and the wrong Chrome profile, Chrome-backed workflows are completely broken for me.

Things tried:

  • Restarting Codex Desktop — no change
  • Toggling permissions / Full access — no change

This looks like the same Desktop 26.616.41845 / app-server metadata regression described in this thread, with an extra Chrome-profile launch problem on my side.

chtld · 1 month ago

same issue:
node_repl/js fails with codex/sandbox-state-meta: missing field sandboxPolicy, while turn_context contains sandbox_policy

Title:
node_repl/js fails with codex/sandbox-state-meta: missing field sandboxPolicy

Bug:
In Codex Desktop on Windows, calls to node_repl/js fail before executing any JavaScript.

Minimal reproduction:
Call node_repl/js with:
nodeRepl.write('runtime-ok')

Actual result:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Expected result:
The tool should execute and return:
runtime-ok

Observed context:
The turn_context/session log contains sandbox_policy, but node_repl/js appears to expect sandboxPolicy. This suggests a snake_case vs camelCase metadata mismatch.

Environment:
Windows
Codex Desktop: 26.616.5445.0
openai-bundled browser/chrome plugin cache observed around 26.616.41845
node_repl.exe path:
C:\Users\12244\AppData\Local\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_repl.exe

Impact:
Chrome control, in-app browser control, Computer Use, and workflows depending on node_repl/js are blocked.

AnnidLin · 1 month ago

Confirming this regression on Windows 11 25H2 (build 26200.8655, x64).

  • Codex Desktop: 26.616.5445.0
  • Computer Use runtime/plugin: 26.616.41845
  • Plugin installed and enabled
  • Microsoft Store reports no newer update

A minimal node_repl/js call fails before executing any JavaScript:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Restarting Codex and starting a fresh thread do not help. The session contains a valid permission profile and sandbox policy, but the required camelCase sandboxPolicy field is not forwarded to the MCP request. Supplying _meta manually is rejected as an unknown field.

This blocks Computer Use, Browser Use, and Chrome control entirely. Please prioritize a hotfix or provide a supported rollback path.

LiWeiJie · 1 month ago

Another macOS repro, with one data point that narrows the OS scope.

  • Codex Desktop 26.616.41845 (build 4198), bundled CLI codex-cli 0.142.0-alpha.6
  • macOS 15.5 (24F74), arm64 — note: not macOS 26.x, unlike most reports here
  • Chrome/browser plugin both 26.616.41845

Minimal call nodeRepl.write("ok") fails before any user JS runs:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Both backends fail identically — chrome (extension) and in-app browser (iab) — so the broken layer is the shared node_repl/js channel, not browser-specific code. An empty codex/sandbox-state-meta appears to trigger it, while a full sandboxPolicy or omitting _meta both work; there's no agent-side workaround since explicit _meta is rejected by the tool schema. --disable-sandbox in config.toml is ignored. All browser automation is unusable on this build; shell/file/network tools still work.

jomplox · 1 month ago

Adding another macOS confirmation from Codex Desktop with the same failure mode.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Bundled CLI: codex-cli 0.142.0-alpha.6
  • macOS: 26.5.1 (25F80), arm64 / Darwin 25.5.0
  • Bundled Browser plugin/runtime path in use: browser@openai-bundled 26.616.41845
  • Local permissions/workspace mode: full access / danger-full-access, approval policy never

Minimal repro in the affected thread:

nodeRepl.write("ping")

Actual result, before any user JS runs:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Additional observations:

  • The Browser plugin is discoverable/available in the thread, but the in-app Browser bootstrap fails before importing browser-client.mjs or calling agent.browsers.get("iab").
  • This reproduces even when the current page is a local localhost:8069 Odoo page, so it is not target-site/auth/page-state specific.
  • Ordinary shell/git/GitHub CLI tools continue to work in the same thread.
  • The local config currently contains [features] js_repl = false, but the node_repl/js tool is still exposed and fails at the MCP metadata boundary, so this does not look like a simple “tool not exposed” or Browser plugin install problem.
  • The active Desktop bundle path reports 26.616.41845 / build 4198; updating the standalone CLI would likely not affect the Desktop-bundled node_repl path, which matches other comments here.

This looks consistent with the proposed root cause in this thread: Codex Desktop/app-server is forwarding an incomplete or mismatched _meta["codex/sandbox-state-meta"] object to bundled node_repl/js (missing camelCase sandboxPolicy), and the failure happens before Browser/Chrome/Computer Use code can initialize.

3VILALLIUM · 1 month ago

Adding another privacy-preserving Windows repro from an affected Codex Desktop session. Feedback/session ID: 019ee5d3-7653-7870-95c3-5841e75db374.

Environment, sanitized:

  • Codex Desktop: 26.616.5445.0, Windows x64 Store package.
  • Bundled Browser/Chrome/Computer Use plugin runtime observed: 26.616.41845.
  • Bundled node_repl runtime observed: cua_node/a89897d3d9baa117/bin/node_repl.exe.
  • Chrome is installed and running; Chrome version observed: 149.0.7827.116.
  • Codex Chrome Extension is installed in the selected Default profile; extension version observed: 1.1.5_0.
  • browser@openai-bundled, chrome@openai-bundled, and computer-use@openai-bundled are enabled in Codex config.
  • Windows sandbox setting is unelevated.

Impact:

  • @Chrome, Browser, and Computer Use are all blocked because they depend on the same node_repl/js route.
  • This is blocking real work that requires Chrome/default-profile state. Browser Playwright can still work for public pages, but it is not a substitute for logged-in/default-profile Chrome workflows.

Troubleshooting performed before posting:

  • Retried the official mcp__node_repl route after rediscovery:
  • js_reset -> Transport closed
  • minimal js smoke test nodeRepl.write('official-node-repl-ok') -> Transport closed
  • js_add_node_module_dir -> Transport closed
  • Checked local Chrome/plugin side:
  • Chrome process is running.
  • Codex native messaging host process is running.
  • Native messaging manifest exists, points to extension-host.exe, the target exists, and the allowed origin matches the Codex Chrome extension ID.
  • Codex Chrome Extension directory exists in Default profile with version 1.1.5_0.
  • Named pipes for chrome.nativeMessaging, codex-browser-use, and codex-computer-use are present.
  • Checked local plugin/runtime cache:
  • Chrome latest points to 26.616.41845.
  • Browser and Computer Use only have 26.616.41845 cached locally, so there is no obvious local rollback target.
  • Checked update path:
  • winget list --name Codex reports Store package 26.616.5445.0.
  • winget upgrade --id 9PLM9XGG6VKS --source msstore --exact reports no available upgrade.
  • Ran a disposable standalone MCP probe against the bundled node_repl.exe without touching browser/account data:
  • With sandboxPolicy.type = "workspace-write" plus sandboxCwd, minimal JS executes successfully and returns manual-node-repl-ok.
  • Omitting required metadata fields fails validation before JS runs.
  • Using camelCase type value workspaceWrite is rejected by the runtime; the runtime expects kebab-case values such as workspace-write.
  • Tried using that standalone working node_repl to bootstrap the bundled Chrome browser-client.mjs; it fails with:
privileged native pipe bridge is not available; browser-client is not trusted

That makes the local picture look like this:

  1. The bundled node_repl.exe binary itself can execute JavaScript when launched with the metadata shape it expects.
  2. The official Desktop MCP node_repl route in the active thread is stuck at Transport closed after transport reset attempts.
  3. A standalone node_repl cannot replace the official Desktop route for Chrome because the privileged/trusted native pipe bridge is unavailable outside the Desktop-managed path.
  4. Chrome, the extension, native host registration, and local bridge artifacts appear present, so this does not look like a normal Chrome install/profile/native-host issue.

The human operator also reports multiple Codex restarts and troubleshooting attempts did not recover Chrome/Computer Use. I am intentionally not attaching screenshots, raw logs, account/profile data, repo names, local usernames, browser history, cookies, or full paths here for privacy. The sanitized evidence above should still be enough to show this is a serious shared node_repl/Desktop transport or metadata/privileged-bridge regression rather than a website-specific or Chrome-extension-only failure.

abduhman-star · 1 month ago

Confirmed, facing this issue as well on windows 11.

douglascamata · 1 month ago

Looks like this is caused by https://github.com/openai/codex/pull/28914. It removes the sandbox policy field from the node_repl MCP call sent by Codex.

kaiwu-astro · 1 month ago

same problem on macos codex app ver 26.616.41845 + codex-cli 0.141.0

update: confirm fixed

handgpt · 1 month ago

Same issue reproduced.

Desktop app: 26.616.41845 build 4198
Bundled CLI: codex-cli 0.142.0-alpha.6
Shell CLI: codex-cli 0.139.0
Bundled node_repl: node_repl-20260609.1
Platform: macOS arm64

Minimal call:
nodeRepl.write('ok')

Error:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Local source inspection suggests current core sends permissionProfile, while bundled node_repl still expects legacy sandboxPolicy.

enguerrand1985-cloud · 1 month ago

Same issue here on Windows.

Desktop: 26.616.41845
Platform: Windows / PowerShell

Error:
Mcp error -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

From the local behavior, this looks like a mismatch where the current runtime sends permissionProfile, while node_repl still expects sandboxPolicy.

evoNick-A · 1 month ago

Additional macOS evidence from controlled MCP probes and repeated Desktop runs.

Environment

  • Codex Desktop 26.616.41845, build 4198
  • Bundled CLI 0.142.0-alpha.6
  • macOS 26.5.1 (25F80), arm64

Reproduction scope

  • 22 unique failed node_repl/js calls recorded across nine session/rollout IDs and four unrelated workspaces.
  • Reproduced with managed workspace-write profiles with network enabled and restricted, and with danger-full-access plus approvals disabled.
  • Fresh threads, full Desktop restarts, and Chrome extension reinstallation did not resolve it.

Standalone probe against the exact bundled node_repl binary

  • Omitting codex/sandbox-state-meta entirely: nodeRepl.write("ok") succeeds.
  • Supplying top-level sandboxPolicy.type = "workspace-write" with a plain absolute sandboxCwd: succeeds.
  • Supplying sandboxPolicy.type = "danger-full-access": succeeds.
  • Supplying top-level permissionProfile without sandboxPolicy: reproduces missing field sandboxPolicy.
  • Using workspaceWrite instead of workspace-write returns an explicit unknown-variant error.
  • A file:// sandbox cwd reaches runtime launch but fails with os error 2; a plain absolute path works.

Current public Codex code serializes SandboxState.permission_profile as permissionProfile and injects it from turn_context.permission_profile():

The installed codex binary contains the newer permissionProfile field set, while the bundled node_repl binary contains the older required sandboxPolicy field set. This strongly indicates a Desktop bundle producer/consumer schema mismatch, not user config.toml.

Directly launching node_repl --disable-sandbox avoids advertising the capability and permits JS execution, but this was not a reliable Desktop workaround after restarts and fresh threads.

Temporary operational workaround on this Mac: explicitly tell Codex that node_repl is broken and instruct it to use Computer Use instead. That avoids the Chrome/browser node_repl path for tasks Computer Use can perform. It is a fallback, not a fix.

ors-orth · 1 month ago

I looked into this a bit more and opened a fork-only draft PR with a minimal compatibility patch:

https://github.com/ors-orth/codex/pull/2

My current understanding is that the breakage is a compatibility gap in the MCP sandbox metadata. Codex now treats permissionProfile as the canonical sandbox representation in codex/sandbox-state-meta, but the bundled node_repl runtime still appears to require the older sandboxPolicy field. When that legacy field is omitted, the runtime rejects the metadata before it can reconstruct the sandbox mode.

The draft PR keeps permissionProfile as canonical, but also projects it back into the legacy sandboxPolicy shape when that can be done safely. For native cwd values, it uses the existing compatibility projection. For foreign cwd values, it only emits sandboxPolicy for profiles that can be represented without lossy path conversion; otherwise it leaves the legacy field absent and still sends permissionProfile.

This is intended as a compatibility bridge rather than a new long-term API direction. If node_repl and other MCP runtimes are updated to consume permissionProfile directly, this Codex-side projection should no longer be necessary.

I am not sure whether the preferred fix is to restore this compatibility field on the Codex side or update the bundled MCP runtimes to accept permissionProfile, but the PR is meant as a concrete reference patch in case any part of it is useful.

FL411 · 1 month ago

Adding a Windows data point and a temporary workaround that I verified locally.

Broken state:

  • Codex Desktop from Microsoft Store: 26.616.5445.0
  • Bundled Browser / Computer Use plugin: 26.616.41845
  • Windows
  • Minimal node_repl/js call failed before user JavaScript ran:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Impact:

  • In-app Browser could not initialize
  • Computer Use could not initialize
  • The failure happened even for:
nodeRepl.write("test")

Temporary workaround I verified:

  • Downgraded Codex Desktop to Microsoft Store package version 26.616.3767.0
  • Bundled Browser / Computer Use plugin after downgrade: 26.616.31447
  • Minimal node_repl/js now succeeds
  • In-app Browser initializes successfully
  • Navigation to https://github.com/openai/codex/issues succeeds and returns the expected title
  • Computer Use initializes successfully and sky.list_apps() returns Windows apps

I am not redistributing the MSIX package because the Microsoft Store application license appears to prohibit publishing the app package for others to copy. It would be helpful if OpenAI could provide either a hotfix or an official supported rollback path for affected users.

StefanBurscher · 1 month ago

You can fix it locally like this:
<img width="929" height="502" alt="Image" src="https://github.com/user-attachments/assets/5f8ec1b0-6cb5-4469-ada5-664bb2953aca" />

Changing the file ~/.codex/config.toml by adding args = ["--disable-sandbox"] in the [mcp_servers.node_repl] section

MrRadiator · 1 month ago

It doesn't seem to work, and then it resets the config file after every Codex restart...

IllusionVK · 1 month ago

I was also able to successfully do the same as @FL411 on Windows:
Downgrade to version 26.616.3767.0 by downloading msix file and installing using
Add-AppxPackage -Path '.\codex-26-616-3767-0.msix' -ForceUpdateFromAnyVersion
This restored ability to use in-app browser (I'm using Windows server 2025)

3VILALLIUM · 1 month ago

Adding a privacy-scrubbed Windows data point from my latest trace, because this issue appears to be the canonical one.

Feedback ID: 019ee64c-3000-7332-8030-a22cfd39505e. I also submitted a Codex Desktop performance/reliability trace from the same session/thread logs, so OpenAI should be able to correlate the telemetry privately from that ID.

What is new/actionable from my trace:

  • This started for me only after the latest Codex Desktop update.
  • The failure survived js_reset, retry, and a same-host/same-project new-thread comparison.
  • The trace checked model/auth, shell, Windows sandbox, node_repl/js, skills, MCP tool inventory, @Chrome, in-app Browser comparison, Computer Use, network/proxy, AV/security signals, and config/dependency state.
  • The most actionable mismatch: user-level config/environment visible to the trace included NODE_REPL_REQUEST_META with codex/sandbox-state-meta.sandboxPolicy, but the live node_repl/js MCP call still failed as if sandboxPolicy was absent:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

That makes this look like a live Desktop app-server / MCP request metadata marshalling problem, not just a missing static config field.

Environment, privacy-scrubbed:

  • Codex Desktop AppX: OpenAI.Codex 26.616.5445.0
  • OS: Microsoft Windows NT 10.0.26200.0 x64
  • Bundled Chrome / Computer Use plugin paths visible locally: 26.616.41845
  • Workspace dependency bundle visible locally: 26.619.11828
  • System Node: v24.16.0; workspace dependency Node: v24.14.0

Additional narrowing from the same trace:

  • Shell, CMD, Git, ordinary local Node, DNS, and HTTPS checks worked.
  • A public unauthenticated browser comparison path could open https://example.com and read the title.
  • Chrome was installed/running, and the Codex Chrome extension, native messaging manifest, and native host process were visible locally.
  • Computer Use plugin/client files were visible locally.
  • @Chrome and Computer Use failed before they could initialize because node_repl/js rejected the call first.
  • No proxy environment variables were visible; WinHTTP was direct.
  • No direct Windows Defender block was found in the checked logs.
  • Remote mobile control itself was still usable enough to drive the diagnostics, so this is separate from the remote-control transport. The problem is the Desktop-side tool bridge once the thread tries to execute node_repl/js.

Impact from my side: this blocks node_repl/js directly and then cascades into @Chrome, Computer Use, and remote-mobile Codex Desktop workflows. Exhaustive in-thread troubleshooting did not repair it, and the available safe recovery paths do not work around it.

Privacy note: I am intentionally not posting local usernames, full paths, repo/project names, raw logs, tokens, cookies, screenshots, account identifiers, or subscription details. Please use the feedback ID and the associated performance trace to inspect the raw session data privately.

goingforstudying-ctrl · 1 month ago

Root Cause Analysis

This is a serialization mismatch between the Rust MCP runtime and the bundled server.

What changed: PR #28914 renamed → in (the JSON payload sent to the MCP server).

What broke: The bundled MCP server still expects the old field name . When it receives the new payload without , it fails with:

Affected surfaces: Chrome extension, in-app browser, and Computer Use — all use .

Fix: Add backward-compatible alias in :

And populate it in when constructing .

PR with the fix: https://github.com/goingforstudying-ctrl/codex/pull/1

Since external PRs require invitation per CONTRIBUTING.md, I\'m posting the fix here for the team to cherry-pick.

fduch-stranger · 1 month ago
Since external PRs require invitation per CONTRIBUTING.md, I'm posting the fix here for the team to cherry-pick.

About 2000 changed files. Have you rewritten the whole codex repo?

MrRadiator · 1 month ago
I was also able to successfully do the same as @FL411 on Windows: Downgrade to version 26.616.3767.0 by downloading msix file and installing using Add-AppxPackage -Path '.\codex-26-616-3767-0.msix' -ForceUpdateFromAnyVersion This restored ability to use in-app browser (I'm using Windows server 2025)

Where would one find and download the file?

murillodutt · 1 month ago

Confirming the same issue after updating Codex Desktop.

Environment:

  • Codex Desktop: 26.616.41845
  • Build: 4198
  • macOS: 26.5.1
  • Arch: arm64
  • Project trust: trusted
  • Browser plugin enabled
  • In-app browser tab is open on a local development page
  • node_repl config has args = []

Observed:

  • mcp__node_repl.js_reset succeeds.
  • Any mcp__node_repl.js call fails before user JavaScript executes.
  • Minimal repro: nodeRepl.write("ok")
  • Error:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

Impact:

  • The in-app browser is visible/open, but the agent cannot inspect or control it.
  • Browser-based visual validation is blocked for local app work.
  • This blocks workflows that require Codex internal browser validation.

Local diagnostics:

  • Restarting Codex did not resolve it.
  • The failure is independent of the target page; it happens before any browser connection.
  • node_repl --help shows a --disable-sandbox option, but I did not change config in this environment.
elcommendante · 1 month ago

I was hitting the same thing on Windows.

For me, the In-App Browser / Browser Use was completely blocked because mcp__node_repl.js failed before it could run any JavaScript.

The error was:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

The browser skill was installed and node_repl showed up through tool discovery, but even the basic browser bootstrap died immediately with that error.

I also checked my local config and I already had the workaround mentioned above:

[mcp_servers.node_repl]
args = ["--disable-sandbox"]
command = '<path-to-node_repl.exe>'
startup_timeout_sec = 120

So in my case, adding args = ["--disable-sandbox"] did not fix it. It looked like Codex Desktop was either ignoring that for the bundled node_repl, or reusing some generated/runtime state where the required sandbox metadata was still missing.

Restarting Codex and retrying the browser bootstrap did not help either. No user JavaScript ran at all, so Browser Use / In-App Browser was blocked before any actual page automation could start.

This matches what was described above: node_repl expects sandboxPolicy inside codex/sandbox-state-meta, but the current Desktop/app-server path does not seem to send that field.

I ended up downgrading Codex Desktop on Windows to 26.616.3767.0, and that fixed it for me. After the downgrade, In-App Browser / Browser Use started working again.

I installed the older MSIX with:

Add-AppxPackage -Path '.\codex-26-616-3767-0.msix' -ForceUpdateFromAnyVersion

I found the 26.616.3767.0 MSIX here:

https://codex-190977.en.uptodown.com/windows/download/1181431353

Important note: this is not an official OpenAI/Microsoft source. It is a third-party mirror, so use it at your own risk.

piercekearns · 1 month ago

Adding a Planban-specific macOS data point, plus a small fallback probe.

Private feedback/log upload submitted from affected Codex thread: 019ed28c-592a-7ce3-a5ba-d8d377c1cf1c.

Environment observed locally:

  • Codex bundled CLI: codex-cli 0.142.0-alpha.6
  • Browser plugin/runtime: openai-bundled/browser/26.616.41845
  • Platform: macOS arm64

Impact:

  • Planban's /pb and /planban commands still successfully start/resolve the local board URL through the Planban MCP server.
  • The failure is only at the final step: making the resolved local URL visible in the Codex in-app browser.
  • Minimal direct node_repl/js execution from the affected desktop thread fails before any user JavaScript runs with:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

This means Planban's browser opener module is never imported/executed. The local board is running and reachable by URL; the Codex browser bridge is the broken layer.

Fallback probe:

  • I tested codex app-server as a possible independent fallback.
  • An app-server-created/resumed thread can call mcpServer/tool/call for node_repl/js successfully, so that path does not fail at the exact same metadata boundary.
  • However, bootstrapping the bundled Browser runtime via app-server required nested x-codex-turn-metadata, and even then agent.browsers.list() returned [], including when targeting the current affected CODEX_THREAD_ID.
  • So app-server may be a partial workaround for JS/MCP execution, but I could not make it act as a true redundancy path for opening the live Codex Desktop in-app browser pane.

Operational mitigation on the Planban side:

  • Keep using the current Browser plugin/node_repl opener as the preferred fast path, so it should recover if Codex ships a hotfix.
  • Add/keep fail-fast handling: if node_repl/js fails before JS execution with this metadata/bridge class of error, stop retrying and return the verified local URL immediately.

This matches the suspected producer/consumer mismatch: current Codex metadata appears to expose newer permission-profile state, while bundled node_repl still rejects calls unless legacy sandboxPolicy is present.

stevenworld75 · 1 month ago

Sharing a field workaround that fixed this on my Windows desktop after the same Codex Desktop 26.616 / bundled plugin 26.616.41845 update. This is not an official OpenAI fix, but it may help people who are blocked.

What I observed:

ode_repl failed before running JS with codex/sandbox-state-meta: missing field sandboxPolicy.

  • The bundled

ode_repl.exe appeared to expect the older sandbox metadata shape.

  • On the same machine, Computer Use also hit a missing native-pipe path even though the shipped codex-computer-use.exe helper still worked over stdio.

What fixed it locally:

  • Backed up the runtime files.
  • Renamed the original

ode_repl.exe to
ode_repl.real.exe.

  • Installed a tiny wrapper plus JS shim that rewrites incoming sandbox metadata to include sandboxPolicy before forwarding to the real runtime.
  • Patched Computer Use to try native pipe first, then fall back to the shipped stdio helper when the pipe is absent.
  • Added an idempotent repair script so Codex restarts/rewrites can reapply the repair.

Verification on my desktop:

  • Chrome extension control opened https://example.com/ and read title Example Domain.
  • Computer Use sky.list_apps() returned 40 apps.
  • Cleanup left no orphan codex-computer-use.exe process.

Full copy/paste prompt, repair approach, and restart watchdog notes are here:
https://gist.github.com/stevenworld75/6c59315b858807a1b6d6a238b1db69f6

Use carefully: back up first, discover local paths dynamically, and keep the patch version-aware so it does not overwrite a future upstream fix.

neonwatty · 1 month ago

Seeing the same failure here. Basic machine details:

  • MacBook Pro
  • Model Identifier: Mac17,6
  • Chip: Apple M5 Max
  • Architecture: arm64
  • macOS: 26.4.1 (25E253)

The Chrome Codex extension path fails before it reaches Chrome. A minimal nodeRepl.write('node bridge ok') call also fails immediately with:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

So this appears to match the reported node_repl/js metadata failure rather than a Chrome-specific problem.

tagcturner · 1 month ago

Adding another Windows data point from Codex Desktop after today's update.

Environment observed locally:

  • OS: Windows, TAGTools workspace under WSL/Rocky8
  • Codex Desktop package path shows OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
  • Bundled Chrome plugin cache: openai-bundled/chrome/26.616.41845
  • node_repl runtime path: AppData/Local/OpenAI/Codex/runtimes/cua_node/a89897d3d9baa117/bin/node_repl.exe

Minimal repro in a local thread:

nodeRepl.write('ok')

Result before any JS executes:

Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Additional checks/recovery attempted:

  • Restarted Codex Desktop: same error.
  • Rediscovered node_repl with tool search: same error.
  • Chrome health check was clean: extensionReady: true, nativeHostCorrect: true, chromeRunning: false, bridgeResetRecommended: false.
  • Killed stale node_repl.exe helpers: the tool then reported Transport closed until rediscovered/restarted, then returned to the same sandboxPolicy failure.
  • Temporarily moved the cached cua_node runtime aside to force reprovisioning; Codex did not recreate it in-thread, so I restored the runtime folder.
  • Chrome itself is not involved; the failure happens with the one-line nodeRepl.write('ok') call before any browser/bootstrap code runs.

This lines up with the suspected desktop app / bundled MCP schema mismatch rather than a Chrome native-host issue.

kevinb9n · 1 month ago

Adding another macOS reproduction with a small direct-MCP diagnostic.

Environment:

  • Codex Desktop: 26.616.41845, build 4198
  • Bundled CLI: codex-cli 0.142.0-alpha.6
  • Bundled Node: v24.14.0
  • macOS: 26.5 (25F71), arm64
  • node_repl path: /Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
  • codex CLI path: /Applications/Codex.app/Contents/Resources/codex
  • Configured sandbox mode: workspace-write

Observed in a normal Codex Desktop thread:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

This happens with a trivial non-browser JS call, before any user JavaScript runs:

nodeRepl.write(JSON.stringify({ ok: true, cwd: nodeRepl.cwd }, null, 2))

Additional direct-MCP diagnostics:

  1. Running the bundled server directly with --disable-sandbox succeeds for a minimal JS call:
manual js ok
  1. Running the bundled server normally and manually sending an empty sandbox metadata object

reproduces the exact error:

{
  "_meta": {
    "codex/sandbox-state-meta": {}
  }
}

Result:

js: codex/sandbox-state-meta: missing field `sandboxPolicy`

This suggests the bundled node_repl server and Node kernel are healthy, but the Codex
Desktop/tool bridge is sending codex/sandbox-state-meta without the fields required by this
node_repl build. It also confirms the Chrome/browser connector is only a downstream casualty:
the failure happens before any Chrome connector code can run.

m-thomson · 1 month ago

In case anyone would like to downgrade to the previous release until this is addressed:

https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.616.32156.zip

As the name suggests, that's the MacOS/Arm build. I'm not sure how to download others, sorry.

_Tip: You can verify that oaistatic.com is indeed an official OpenAI domain by going to https://chatgpt.com/download/ and observing that all MacOS downloads come from there._

hkay-dev · 1 month ago

I'm running into this as well. If it helps (but I'm guessing based on all these comments, it does not) I started a project on the latest Codex windows build, pushed a brand new repo, and moved over to macOS, downlaoded the repo, and opened it up in Codex macos build, and I'm stuck here.

Huge thank you to @m-thomson, this worked for me, just need to ignore that tempting Update button until this gets fixed.

In case anyone would like to downgrade to the previous release until this is addressed: persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.616.32156.zip As the name suggests, that's the MacOS/Arm build. I'm not sure how to download others, sorry. _Tip: You can verify that oaistatic.com is indeed an official OpenAI domain by going to chatgpt.com/download and observing that all MacOS downloads come from there._
gkb · 1 month ago

Adding another macOS repro with matching symptoms.

Environment

  • macOS 26.5.1, build 25F80, arm64
  • Codex Desktop / bundled Chrome plugin version observed: 26.616.41845
  • Google Chrome: 149.0.7827.116 at /Applications/Google Chrome.app
  • Chrome profile selected by Codex checks: Default
  • Codex Chrome Extension: installed and enabled, version 1.1.5_0
  • Native messaging host manifest: present and valid

Failure

Any attempt to use the Chrome bridge / browser automation path fails before JS executes:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`

Checks Performed

  • scripts/chrome-is-running.js --check: Chrome is running.
  • scripts/installed-browsers.js --check: Google Chrome is installed.
  • scripts/check-extension-installed.js --json: selected Default profile has the Codex Chrome Extension installed and enabled.
  • scripts/check-native-host-manifest.js --json: manifest exists, host name matches, expected extension origin is allowed, and correct: true.
  • Opened a blank Chrome window through scripts/open-chrome-window.js for the selected Default profile, waited, then retried the bridge. Same missing field sandboxPolicy error.

Assessment

This looks like the same app-side metadata/schema issue described here, rather than a missing or disabled extension or a broken native host manifest.

etraut-openai contributor · 1 month ago

Thanks for the bug report. We've issued a hotfix for this problem. Please update your app and confirm that it fixes the issue you were seeing.

murillodutt · 1 month ago

Update after the hotfix: resolved on my macOS setup.

Environment now:

  • Codex Desktop: 26.616.51431, build 4212
  • Browser plugin/runtime: 26.616.51431
  • macOS: 26.5.1 (25F80), arm64

Validation:

  • mcp__node_repl.js now executes and returns the bundled Browser documentation.
  • In-app Browser bootstrap succeeds with agent.browsers.get("iab").
  • A local development page loads in the in-app browser and tab.playwright.domSnapshot() returns page content.

So the codex/sandbox-state-meta: missing field sandboxPolicy failure is fixed in this environment.

3VILALLIUM · 1 month ago

Confirmed fixed on my Windows Codex Desktop host after updating.

Previous failing repro from my earlier comments:

  • Codex Desktop: 26.616.5445.0
  • Bundled Browser/Chrome/Computer Use runtime observed: 26.616.41845
  • Failure: every real node_repl/js execution failed before user JS ran with Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy
  • Downstream impact: Browser, @Chrome, and Computer Use could not initialize.

Current retest after hotfix/update:

  • Codex Desktop package: 26.616.6631.0
  • Bundled Browser/Chrome/Computer Use cache observed locally: 26.616.51431
  • Workspace dependency bundle: 26.619.11828
  • OS: Windows 10.0.26200.8655

Smoke results:

  • mcp__node_repl.js_reset succeeded.
  • Minimal JS execution succeeded: nodeRepl.write('node-repl-ok') returned node-repl-ok.
  • In-app Browser comparison succeeded: opened https://example.com/, title Example Domain.
  • @Chrome initially reported Browser is not available: extension while Chrome was not running. After launching Chrome, extension-backed bootstrap succeeded, opened https://example.com/, read title Example Domain, and finalized the agent-created tab.
  • Computer Use bootstrap succeeded. sky.list_apps() returned successfully with 40 apps, 6 running apps, and 8 targetable windows. I did not test click/type/window activation in this pass.

So the original shared node_repl/js sandboxPolicy failure is resolved on this Windows host after the hotfix. The only caveat I observed is separate from the original bug: Chrome still needs to be running before the extension-backed @Chrome path connects.

waleed-salama · 29 days ago

Confirmed fixed for me after updating Codex. The built-in Browser plugin now bootstraps successfully, and I can open/read a localhost page without the previous codex/sandbox-state-meta: missing field sandboxPolicy failure.

enginoid · 29 days ago

Confirmed working after update at version 26.616.51431 on macOS – thanks for a quick fix!

<img width="1565" height="1191" alt="Image" src="https://github.com/user-attachments/assets/8a750fa1-a426-40ef-814f-77ee105601c0" />

hashem-reyi · 29 days ago

It is good to know that its resolved, but the reason such a major bug existed without proper testing, needs to be investigated. It is okay if codex doesn't ship new features often, but stability of existing features is what should matter the most.

bobchristof-gp · 29 days ago

Confirmed fixed, thank you

riwagne · 27 days ago

On macOS, using the same OpenAI account in each surface, the desktop Codex app can use the Chrome MCP successfully, but Codex CLI and Codex VS Code cannot.

Failure surfaces:

  • Codex CLI
  • Codex VS Code extension

Error:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy

I tried reinstalling and pkill/restarting everything, with no change.

Versions:

  • Codex CLI: codex-cli 0.142.0
  • Desktop app build: CFBundleVersion 4028
  • Chrome plugin/MCP bundle: chrome 26.611.62324

CLI and VS Code appear not to send sandboxPolicy in codex/sandbox-state-meta for node_repl/Chrome MCP calls, while the desktop Codex app does.