Codex Desktop ignores node_repl args and sends malformed sandbox metadata to js tool

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

• #29189
• #29213
• #29214
• #29205
• #29193

Powered by Codex Action

Can confirm this issue on Codex Desktop 26.619.11828. (Windows)
Browser/Chrome tools fail before execution with:
"missing field sandboxPolicy"

MacOS also has this same problem.

Also seeing this on Windows with Codex Desktop 26.616.5445.0 and bundled browser/chrome plugin 26.616.41845.

What I tried locally:

1. Verified mcp__node_repl.js fails before any JavaScript runs with:

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

1. Tried updating C:\Users\USER\.codex\config.toml:

[features]
js_repl = true

[mcp_servers.node_repl]
args = ["--disable-sandbox"]

The live helper was still launched with no args, and after restarting Codex Desktop the config was regenerated back to js_repl = false and args = [].

1. Built a small user-space wrapper that forwards stdio to the real node_repl.exe while injecting --disable-sandbox, then pointed mcp_servers.node_repl.command at it. codex mcp get node_repl showed the wrapper and args before restart, but Codex Desktop rewrote the managed MCP block back to the bundled node_repl.exe path with no args.

1. Tried a runtime-path swap as a reversible test: backed up the real helper as node_repl.original.exe and placed the wrapper at the bundled node_repl.exe path. The wrapper worked when called directly, but after restarting Codex Desktop the runtime was restored to the original 13 MB node_repl.exe and the backup was gone.

Result: the issue still reproduces after restart. The failure happens before Chrome or Edge extension communication, so this does not appear to be a browser-extension setup issue. Local config and runtime-file workarounds are being reverted by Desktop startup/runtime management.

Additional Windows confirmation from Codex Desktop 26.616.5445.0.

Environment:

• Windows 11 Pro, x64 (10.0.26200)
• Codex Desktop package: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
• Codex CLI: codex-cli 0.142.0-alpha.6
• cua_node runtime: 20260609.1, Node 24.14.0
• Browser plugin/runtime observed: 26.616.41845
• Permission state: approvalPolicy=never, sandboxPolicy.type=dangerFullAccess, activePermissionProfile.id=:danger-full-access

Minimal repro:

nodeRepl.write('node_repl_ok')

Actual:

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

Additional checks:

• codex doctor --json reports config/auth/db/network mostly OK; no MCP config failure.
• gh / shell / PowerShell work normally.
• codex mcp get node_repl sees the configured MCP server.
• Trying args = ["--disable-sandbox"] in config.toml is not a reliable workaround: CLI can show the arg, but Desktop-spawned node_repl.exe processes still start without it.
• Making config.toml read-only preserved the setting but did not change the Desktop-spawned process command line.
• Config was restored to normal (args = [], writable).

Impact:

• node_repl/js fails before any user JavaScript executes.
• This blocks Browser runtime / in-app browser automation.
• This is not project-specific; repo files were not changed.

Adding my Windows data point because the node_repl metadata / trusted bridge angle here matches what I found locally. Feedback/session ID: 019ee5d3-7653-7870-95c3-5841e75db374.

Sanitized environment:

• 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 under cua_node/a89897d3d9baa117/bin/node_repl.exe.
• Chrome extension/native-host side appears present: Chrome is running, the Codex native messaging host is running, the manifest points to extension-host.exe, and the Codex Chrome Extension exists in the selected Default profile as 1.1.5_0.
• Named pipes for chrome.nativeMessaging, codex-browser-use, and codex-computer-use are present.

What I am seeing in the affected Desktop thread:

mcp__node_repl.js_reset -> Transport closed
mcp__node_repl.js with nodeRepl.write('official-node-repl-ok') -> Transport closed
mcp__node_repl.js_add_node_module_dir -> Transport closed

Multiple Codex restarts and troubleshooting passes have not recovered the Desktop-managed Browser/Chrome/Computer Use route for me.

The useful technical finding is from a disposable standalone MCP probe against the same bundled node_repl.exe runtime, without touching browser/account data:

• With sandboxPolicy.type = "workspace-write" plus sandboxCwd, minimal JavaScript executes and returns manual-node-repl-ok.
• Omitting required metadata fields fails validation before JS runs.
• Using the camelCase type value workspaceWrite is rejected; this runtime expects kebab-case values such as workspace-write.

That suggests the node_repl.exe binary itself is capable of running JS when invoked with metadata shaped the way it expects.

But that is not a usable workaround for Browser/Chrome. When I used the standalone working node_repl to import/bootstrap the bundled Chrome browser-client.mjs, it failed with:

privileged native pipe bridge is not available; browser-client is not trusted

So my current read is:

1. The bundled runtime can execute JS with valid metadata.
2. The Desktop-managed MCP route is stuck/broken in the affected thread.
3. The standalone runtime cannot replace the Desktop-managed route because it is not trusted and cannot access the privileged native pipe bridge.
4. Chrome, extension install, native-host registration, and bridge artifacts appear present, so this does not look like a browser-extension-only issue.

I am intentionally not attaching screenshots, raw logs, account/profile data, repo names, local username, browser history, cookies, or full local paths here for privacy.

Follow-up to my earlier technical comment with a newer trace and feedback ID.

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

The new trace reinforces the managed-Desktop-route theory here, but from a different angle than my earlier standalone node_repl probe:

• node_repl/js was visible in the affected thread.
• js_reset succeeded.
• A minimal JS call still failed before user JavaScript ran:

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

• A same-host, same-project new-thread comparison reproduced the same error.
• Shell, CMD, Git, ordinary local Node, DNS, HTTPS, and a public unauthenticated browser comparison path worked.
• Chrome install/runtime pieces were visible locally: Chrome process, Codex Chrome extension, native messaging manifest, and native host process.
• Computer Use plugin/client files were visible locally.
• @Chrome and Computer Use failed before their own bootstrap because node_repl/js rejected the call first.

Most actionable new observation: local 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 reported sandboxPolicy missing. That suggests the bug may be specifically in the Desktop app-server's live MCP params._meta construction/forwarding path, or in a producer/consumer schema mismatch between that path and the bundled node_repl runtime, rather than simply in the persisted TOML/config values.

This still does not look like a user-config workaround problem. A product fix likely needs the Desktop-managed trusted route to either pass the compatibility sandboxPolicy shape expected by the bundled runtime or update the bundled runtime to accept the newer permission-profile metadata, and existing affected threads may also need the node_repl transport/kernel invalidated or recreated after the fix.

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

I am seeing the same issue in Codex Desktop on Windows while trying to use the bundled Chrome plugin / Codex Chrome Extension.

The Chrome extension appears installed/available, but Codex cannot reach Chrome because node_repl/js fails before any JavaScript runs.

Exact error:

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

Impact:

• @chrome cannot initialize.
• Codex cannot list or claim existing Chrome tabs.
• Browser automation fails before page navigation or account verification.
• This blocks Chrome-extension workflows that were supposed to use the logged-in Chrome profile.
• The failure happens before any user JS executes, so it does not appear to be caused by the target website, login state, Chrome tabs, or project code.

In my case this blocks a workflow that must use the Codex Chrome Extension only. I cannot safely use DevTools, Playwright, an in-app browser, or a fresh unauthenticated browser as fallback because the workflow requires the real logged-in Chrome profile and visible account verification.

Environment/context:

• OS: Windows 11
• Codex Desktop
• Plugin: chrome@openai-bundled / Codex Chrome Extension
• Workspace: D:\Balcony\social media agent
• node_repl/js fails immediately during Chrome plugin bootstrap

Minimal repro from my session:

1. Invoke @chrome in a Codex Desktop thread.
2. Try to initialize the bundled Chrome plugin browser client.
3. node_repl/js fails immediately with:

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

Expected:

Codex Desktop should provide the sandboxPolicy field required by node_repl/js, or the plugin should return a clearer actionable repair message.

Actual:

The Chrome plugin is blocked before browser connection, before tab listing, and before any JavaScript execution.

Additional macOS reproduction with causal evidence and a working metadata-injection smoke test

I am seeing the same failure on macOS when using the Codex Chrome extension:

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

The failure occurs for the smallest possible call:

nodeRepl.write("ok")

It therefore happens before the Chrome browser client is imported and before Codex attempts to communicate with Chrome.

Environment:

Platform: macOS, Apple Silicon
Codex Desktop Chrome plugin version: 26.616.41845
node_repl: the binary bundled inside Codex.app

Chrome itself appears healthy:

• Google Chrome is running.
• The Codex Chrome extension is installed and enabled.
• The Native Messaging Host manifest is present and correct.
• The extension host process is running.
• Reinstalling the Codex Chrome extension and plugin did not help.
• Restarting Chrome, Codex Desktop, macOS, and starting fresh threads did not help.

I inspected the bundled node_repl binary. Its sandbox-state deserialization appears to expect fields including:

sandboxPolicy
codexLinuxSandboxExe
sandboxCwd
useLegacyLandlock

I then performed a standalone MCP-style smoke test. When I injected a sandboxPolicy field into:

_meta["codex/sandbox-state-meta"]

the same basic JavaScript execution succeeded.

This is strong evidence that the missing field is the immediate blocker, rather than Chrome, the extension, the selected tab, or the JavaScript being executed.

This also appears consistent with the metadata change in #28914, which removed the legacy sandboxPolicy field and made permissionProfile the source of truth. The packaged Desktop components may be version-skewed: the Codex MCP caller sends the newer schema while the bundled node_repl still expects the older schema.

I also tested possible workarounds:

1. Setting NODE_REPL_REQUEST_META did not affect Codex Desktop's actual tool calls. It appears that the per-request MCP _meta generated by Desktop overrides or bypasses that environment fallback.

1. I created a proxy wrapper that injects sandboxPolicy into incoming MCP requests and then forwards them to the official bundled node_repl.

The wrapper works in a direct local MCP smoke test.

1. I configured [mcp_servers.node_repl].command to use the wrapper, but Codex Desktop continued producing the original error after a complete restart. This indicates that Desktop is not launching the active managed node_repl through the configured MCP command, or is restoring or caching a separate built-in binding.

This reproduces both parts of this issue:

• Desktop sends sandbox metadata incompatible with the bundled node_repl.
• Desktop ignores the configured node_repl command, preventing a local wrapper workaround.

One potentially relevant mechanism is CODEX_NODE_REPL_PATH. An earlier macOS report, #21722, describes Codex Desktop successfully launching a wrapper through that environment variable while retaining the Desktop browser bridge. I have not yet confirmed whether the current Desktop build still honors it.

Suggested fixes:

• Ship a node_repl that accepts the new permissionProfile-based metadata.
• Temporarily send both permissionProfile and the legacy sandboxPolicy.
• Make sandboxPolicy optional for compatibility.
• Ensure all bundled Desktop components use the same sandbox metadata schema.
• Honor the configured node_repl command, or document a supported override such as CODEX_NODE_REPL_PATH.

This blocks Codex Desktop workflows that require access to the user's authenticated Chrome session.

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.

Mee too

Codex Desktop Browser Use is broken.

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

Impact:
@Browser / in-app browser control cannot run. A minimal node_repl/js call fails before JavaScript executes, so this is not caused by the target website or local project.

Related open issues:
https://github.com/openai/codex/issues/29193
https://github.com/openai/codex/issues/29219
https://github.com/openai/codex/issues/29241

This appears related to a Desktop/app-server/node_repl metadata mismatch after Codex Desktop 26.616.x / 26.619.x.

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.

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.

@etraut-openai I can confirm it's working again, thanks for the fast action.

Since a hotfix shipped, I would close this with producer/consumer compatibility tests. Cover app-server launches of managed node_repl with configured args, injected sandbox metadata, and Browser/Chrome/Computer Use bootstrap across Windows and macOS.

The regression should assert user-configured args are either honored or explicitly marked unsupported for managed helpers, and that minimal JS executes before browser bootstrap. Also verify the config reconciler does not flip js_repl back to false after restart.

---

_Generated with ax._