Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy
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:
- Enable/use bundled Chrome plugin in Codex Desktop.
- Start a local thread with sandbox_mode = danger-full-access / approval_policy = never.
- Expose node_repl via tool search.
- Run:
nodeRepl.write(JSON.stringify({ ok: true }))
- Tool fails with:
codex/sandbox-state-meta: missing field sandboxPolicy
Investigation:
- Current thread context logs show
sandbox_policysnake_case. - Bundled node_repl binary expects
sandboxPolicycamelCase insidecodex/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.
63 Comments
I am hitting the same issue on macOS.
Environment:
Observed behavior:
mcp__node_repl.jscall such asnodeRepl.write('ok')fails before user JS runs:Impact:
node_repl/jsfails before it can import the browser client or callagent.browsers.get('extension').Additional local debugging:
sandbox_policyin snake_case.node_replappears to requiresandboxPolicyin camelCase insidecodex/sandbox-state-meta.sandboxPolicysucceeds.sandbox_policy -> sandboxPolicyworks in a standalone probe, but Codex Desktop appears to launch the bundlednode_repldirectly / rewrite or ignoremcp_servers.node_replcommand/args, so this is not a stable workaround from~/.codex/config.toml.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 sandboxPolicyerror 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 policydanger-full-accessand permission profiledisabled, but the field expected bynode_replis 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.I’m hitting the same issue on macOS.
Environment:
Observed behavior:
Chrome/Browser automation fails before any browser page or user JavaScript is accessed. The tool is discovered and invoked, but
node_repl/jsfails internally with:This happens even after reinstalling Codex and removing the manually registered
node_replMCP fromcodex 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 camelCasesandboxPolicyfield fromcodex/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.I can reproduce this on macOS in Codex Desktop 26.616.41845.
Additional evidence from local Codex session history in the same project:
26.616.32156.iab, openedhttp://localhost:5173/, got titleAge of Agents, and inspected the DOM throughtab.playwright.domSnapshot().26.616.41845, the same Browser bootstrap fails before any user JS runs:nodeRepl.write("ok")call fails with the same error, so this is not caused by the Browser client import, Playwright, or project code.--disable-sandboxinmcp_servers.node_repl.argsis not effective because Codex Desktop appears to rewrite or ignore the bundlednode_replargs.This looks like a regression between
26.616.32156and26.616.41845, where Desktop/app-server no longer passes thesandboxPolicyfield expected by bundlednode_repl/js.I'm experiencing the same issue; couple of additional data points:
<img width="803" height="222" alt="Image" src="https://github.com/user-attachments/assets/09287de5-25eb-47cf-aae0-8f6653f8e4aa" />
I can reproduce the same failure on macOS with the current Desktop build.
Environment:
26.616.41845, build4198codex-cli 0.142.0-alpha.626.3build25D125, arm64chrome@openai-bundledruntime26.616.41845149.0.7827.115Defaultprofile, extension version1.1.5_0exists=true,correct=true, expected origin presentMinimal repro in the affected Codex thread:
Actual result, before any user JS executes:
Additional recovery attempts / checks:
Google Chromeandextension-hostprocesses exited.scripts/open-chrome-window.js; fresh Chrome andextension-hostprocesses started.scripts/chrome-is-running.js --check-> OKscripts/check-extension-installed.js --json-> installed/enabled true for selected profilescripts/check-native-host-manifest.js --json-> manifest correctsandboxPolicyerror persists.Impact:
node_repl/jsfails before importing the browser client or callingagent.browsers.get('extension').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:
node_repl/jsBrowser workflow succeeded before the update and began failing after it.sandbox_policy: {"type":"danger-full-access"}.sandboxPolicy: {"type":"dangerFullAccess"}for the affected thread.node_repl/jsrejects the MCP call before executing JavaScript with:Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicyjs_resetstill works, confirming the failure is specific to the execution call requiring sandbox metadata._metaexplicitly is rejected by the exposed tool schema, so there is no agent-side workaround.This looks like a regression in Desktop/app-server metadata propagation introduced with the current build.
Additional macOS confirmation from my local setup after updating the standalone runtime:
Environment:
26.616.41845, build4198codex update:codex-cli 0.142.0-alpha.70.142.0-alpha.7browser_use,browser_use_external,in_app_browser,plugins,computer_use,apps, andenable_mcp_appsall effectively enabled in the projectMinimal repro still fails after the standalone update and app-server restart:
Result:
Important extra detail:
codex mcp list --jsonstill wiresnode_replto the Desktop app bundle:I also inspected the public
rust-v0.142.0-alpha.7macOS DMG from the GitHub release; it contains CLI payloads (codex,codex-responses-api-proxy) rather than a replacementCodex.app, so that update path does not refresh the desktop-bundlednode_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_replpath is still the component rejecting the sandbox metadata before any user JS runs.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.Additional macOS confirmation after updating the standalone runtime:
Environment
codex update:codex-cli 0.142.0-alpha.70.142.0-alpha.7browser_use,browser_use_external,in_app_browser,plugins,computer_use,apps, andenable_mcp_appsall effectively enabledMinimal repro
The failure remains after the standalone update and app-server restart:
Result:
Important additional detail
codex mcp list --jsonstill wiresnode_replto the Desktop app bundle:The public
rust-v0.142.0-alpha.7macOS DMG from the GitHub release contains CLI payloads (codex,codex-responses-api-proxy) rather than a replacementCodex.app, so that update path does not refresh the Desktop-bundlednode_repl.This makes the failure independent of project/user feature flags and independent of the standalone CLI/app-server version: the Desktop-bundled
node_replpath remains the component rejecting the sandbox metadata before any user JavaScript runs.Additional macOS data point from the same 26.616.41845 / build 4198 class of failure.
Environment:
What I tried:
node_repl/jscall still fails before JS execution with:Additional bridge evidence:
~/.codex/chrome-native-hosts-v2.jsonto the live Desktop process and versioned plugin paths.extension-host-config.jsonwas missing under the versionedextension-host/macos/arm64directory. Recreating it with the bundledscripts/installManifest.mjsrestored that config file, but did not make the Chrome backend discoverable.agent.browsers.list()still returns[].backendCounts: { cdp: 0, extension: 0, iab: 0 }reason: no-iab-backendsbackend-info-request/native pipe closed before responselsofshows the Codex process andextension-hostprocess holding separate/tmp/codex-browser-use/*.sockpaths, which looks similar to the socket mismatch described in #21719.So there appear to be two overlapping problems:
node_repl/jsmetadata schema mismatch (sandboxPolicy) described in this issue.I’m seeing the same failure when Codex Desktop tries to connect to Chrome.
Environment:
26.616.4184526.4.1(build25E253)arm64Reproduction:
node_repl/jscall fails before Chrome can connect.Exact error:
Expected: the bundled Chrome tool should connect to the existing Chrome session.
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
sandboxPolicyfield 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/...
Windows confirmation: I can reproduce the same
codex/sandbox-state-meta: missing field sandboxPolicyfailure on Codex Desktop 26.616.41845.Environment:
node_repl/jsfails 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
sandboxPolicyThis 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.
Additional macOS data point with a narrower repro.
Environment:
26.616.41845, build4198codex-cli 0.142.0-alpha.626.5.1, arm6426.616.41845node_replcommand:/Applications/Codex.app/Contents/Resources/cua_node/bin/node_replIn Codex Desktop, even a minimal call fails before user JS executes:
with:
I also ran a direct standalone MCP probe against the bundled
node_replbinary, outside Codex Desktop. Results:_meta["codex/sandbox-state-meta"]includingsandboxPolicy: succeeds, returnsok._metaat all: succeeds, returnsok._meta["codex/sandbox-state-meta"] = {}: fails with the exact same error:So this looks more specific than just "node_repl requires metadata". It appears to reject an empty
codex/sandbox-state-metaobject, while omitted metadata is accepted. That suggests Codex Desktop/app-server may be forwarding: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.
Can confirm this issue on Codex Desktop 26.619.11828. (Windows)
"missing field sandboxPolicy"
can confirm this on windows. the openai updates to codex are a complete mess
The same problem on my macbook pro, the same version 26.616.41845
Additional Windows repro from Codex Desktop after today's update.
Environment:
Minimal repro:
Actual result:
Impact:
@chromecannot bootstrap because the requiredmcp__node_repl__jstool fails before any browser-client code runs.nodeRepl.write('ok')call, so it is not a Chrome extension install/setup problem.Useful comparison:
node_repl/jssuccessfully with Chrome browser-use metadata and finalize the Chrome session.sandboxPolicy.Restarting Codex Desktop did not fix it.
Same
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
sandboxPolicyAdditional 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..
Used up my entire quota, reinstalled the environment, and it turned out to be a bug
I can reproduce this on macOS as well.
Environment
26.616.41845(CFBundleVersion4198)codex-cli 0.142.0-alpha.6codexCLI:codex-cli 0.126.0-alpha.4Symptom
Minimal
mcp__node_repl.jscalls fail before user JavaScript is executed:Error:
However,
mcp__node_repl.js_resetsucceeds:So the MCP server itself is reachable, but the
jsmethod appears to receive incomplete sandbox metadata.Impact
This blocks both bundled browser-control surfaces:
@Browser/ in-app browser, because it needsnode_repl/jsto bootstrapbrowser-client.mjs@Chrome, for the same reasonThe 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
node_replconfig.Expected
mcp__node_repl.jsshould receive valid sandbox metadata and execute the minimalnodeRepl.write(...)call.Actual
mcp__node_repl.jsfails during metadata validation with missingsandboxPolicy, whilejs_resetstill works.Same, the last update rendered the in-app browser unusable.
There should be a way to rollback to an older Codex desktop version.
I'm hitting the same issue on macOS.
Environment:
26.616.41845, build419826.5.1(25F80), arm64chrome@openai-bundledenabledbrowser@openai-bundledenabledObserved behavior:
node_repl/jscalls fail before any user JavaScript runs:node_repl/jsfails before it can reach the browser client or extension bridge.Additional symptom (Chrome profile):
sandboxPolicyfailure and the wrong Chrome profile, Chrome-backed workflows are completely broken for me.Things tried:
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.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
sandboxPolicyExpected 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 expectsandboxPolicy. 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.
Confirming this regression on Windows 11 25H2 (build 26200.8655, x64).
A minimal
node_repl/jscall fails before executing any JavaScript:Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicyRestarting Codex and starting a fresh thread do not help. The session contains a valid permission profile and sandbox policy, but the required camelCase
sandboxPolicyfield is not forwarded to the MCP request. Supplying_metamanually 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.
Another macOS repro, with one data point that narrows the OS scope.
Minimal call nodeRepl.write("ok") fails before any user JS runs:
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.
Adding another macOS confirmation from Codex Desktop with the same failure mode.
Environment:
26.616.41845, build4198codex-cli 0.142.0-alpha.626.5.1 (25F80), arm64 / Darwin25.5.0browser@openai-bundled 26.616.41845danger-full-access, approval policyneverMinimal repro in the affected thread:
Actual result, before any user JS runs:
Additional observations:
browser-client.mjsor callingagent.browsers.get("iab").localhost:8069Odoo page, so it is not target-site/auth/page-state specific.[features] js_repl = false, but thenode_repl/jstool 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.26.616.41845/ build4198; updating the standalone CLI would likely not affect the Desktop-bundlednode_replpath, 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 bundlednode_repl/js(missing camelCasesandboxPolicy), and the failure happens before Browser/Chrome/Computer Use code can initialize.Adding another privacy-preserving Windows repro from an affected Codex Desktop session. Feedback/session ID:
019ee5d3-7653-7870-95c3-5841e75db374.Environment, sanitized:
26.616.5445.0, Windows x64 Store package.26.616.41845.node_replruntime observed:cua_node/a89897d3d9baa117/bin/node_repl.exe.149.0.7827.116.1.1.5_0.browser@openai-bundled,chrome@openai-bundled, andcomputer-use@openai-bundledare enabled in Codex config.unelevated.Impact:
@Chrome, Browser, and Computer Use are all blocked because they depend on the samenode_repl/jsroute.Troubleshooting performed before posting:
mcp__node_replroute after rediscovery:js_reset->Transport closedjssmoke testnodeRepl.write('official-node-repl-ok')->Transport closedjs_add_node_module_dir->Transport closedextension-host.exe, the target exists, and the allowed origin matches the Codex Chrome extension ID.1.1.5_0.chrome.nativeMessaging,codex-browser-use, andcodex-computer-useare present.latestpoints to26.616.41845.26.616.41845cached locally, so there is no obvious local rollback target.winget list --name Codexreports Store package26.616.5445.0.winget upgrade --id 9PLM9XGG6VKS --source msstore --exactreports no available upgrade.node_repl.exewithout touching browser/account data:sandboxPolicy.type = "workspace-write"plussandboxCwd, minimal JS executes successfully and returnsmanual-node-repl-ok.workspaceWriteis rejected by the runtime; the runtime expects kebab-case values such asworkspace-write.node_replto bootstrap the bundled Chromebrowser-client.mjs; it fails with:That makes the local picture look like this:
node_repl.exebinary itself can execute JavaScript when launched with the metadata shape it expects.node_replroute in the active thread is stuck atTransport closedafter transport reset attempts.node_replcannot replace the official Desktop route for Chrome because the privileged/trusted native pipe bridge is unavailable outside the Desktop-managed path.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.Confirmed, facing this issue as well on windows 11.
Looks like this is caused by https://github.com/openai/codex/pull/28914. It removes the sandbox policy field from the
node_replMCP call sent by Codex.same problem on macos codex app ver 26.616.41845 + codex-cli 0.141.0
update: confirm fixed
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
sandboxPolicyLocal source inspection suggests current core sends permissionProfile, while bundled node_repl still expects legacy sandboxPolicy.
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.
Additional macOS evidence from controlled MCP probes and repeated Desktop runs.
Environment
26.616.41845, build41980.142.0-alpha.626.5.1(25F80), arm64Reproduction scope
node_repl/jscalls recorded across nine session/rollout IDs and four unrelated workspaces.workspace-writeprofiles with network enabled and restricted, and withdanger-full-accessplus approvals disabled.Standalone probe against the exact bundled
node_replbinarycodex/sandbox-state-metaentirely:nodeRepl.write("ok")succeeds.sandboxPolicy.type = "workspace-write"with a plain absolutesandboxCwd: succeeds.sandboxPolicy.type = "danger-full-access": succeeds.permissionProfilewithoutsandboxPolicy: reproducesmissing field sandboxPolicy.workspaceWriteinstead ofworkspace-writereturns an explicit unknown-variant error.file://sandbox cwd reaches runtime launch but fails withos error 2; a plain absolute path works.Current public Codex code serializes
SandboxState.permission_profileaspermissionProfileand injects it fromturn_context.permission_profile():The installed
codexbinary contains the newerpermissionProfilefield set, while the bundlednode_replbinary contains the older requiredsandboxPolicyfield set. This strongly indicates a Desktop bundle producer/consumer schema mismatch, not userconfig.toml.Directly launching
node_repl --disable-sandboxavoids 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_replis broken and instruct it to use Computer Use instead. That avoids the Chrome/browsernode_replpath for tasks Computer Use can perform. It is a fallback, not a fix.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
permissionProfileas the canonical sandbox representation incodex/sandbox-state-meta, but the bundlednode_replruntime still appears to require the oldersandboxPolicyfield. When that legacy field is omitted, the runtime rejects the metadata before it can reconstruct the sandbox mode.The draft PR keeps
permissionProfileas canonical, but also projects it back into the legacysandboxPolicyshape when that can be done safely. For native cwd values, it uses the existing compatibility projection. For foreign cwd values, it only emitssandboxPolicyfor profiles that can be represented without lossy path conversion; otherwise it leaves the legacy field absent and still sendspermissionProfile.This is intended as a compatibility bridge rather than a new long-term API direction. If
node_repland other MCP runtimes are updated to consumepermissionProfiledirectly, 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.Adding a Windows data point and a temporary workaround that I verified locally.
Broken state:
Impact:
Temporary workaround I verified:
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.
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.tomlby addingargs = ["--disable-sandbox"]in the[mcp_servers.node_repl]sectionIt doesn't seem to work, and then it resets the config file after every Codex restart...
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' -ForceUpdateFromAnyVersionThis restored ability to use in-app browser (I'm using Windows server 2025)
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:
js_reset, retry, and a same-host/same-project new-thread comparison.node_repl/js, skills, MCP tool inventory,@Chrome, in-app Browser comparison, Computer Use, network/proxy, AV/security signals, and config/dependency state.NODE_REPL_REQUEST_METAwithcodex/sandbox-state-meta.sandboxPolicy, but the livenode_repl/jsMCP call still failed as ifsandboxPolicywas absent: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:
OpenAI.Codex 26.616.5445.0Microsoft Windows NT 10.0.26200.0 x6426.616.4184526.619.11828v24.16.0; workspace dependency Node:v24.14.0Additional narrowing from the same trace:
https://example.comand read the title.@Chromeand Computer Use failed before they could initialize becausenode_repl/jsrejected the call first.node_repl/js.Impact from my side: this blocks
node_repl/jsdirectly 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.
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.
About 2000 changed files. Have you rewritten the whole codex repo?
Where would one find and download the file?
Confirming the same issue after updating Codex Desktop.
Environment:
node_replconfig hasargs = []Observed:
mcp__node_repl.js_resetsucceeds.mcp__node_repl.jscall fails before user JavaScript executes.nodeRepl.write("ok")Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicyImpact:
Local diagnostics:
node_repl --helpshows a--disable-sandboxoption, but I did not change config in this environment.I was hitting the same thing on Windows.
For me, the In-App Browser / Browser Use was completely blocked because
mcp__node_repl.jsfailed before it could run any JavaScript.The error was:
The browser skill was installed and
node_replshowed 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:
So in my case, adding
args = ["--disable-sandbox"]did not fix it. It looked like Codex Desktop was either ignoring that for the bundlednode_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_replexpectssandboxPolicyinsidecodex/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:
I found the
26.616.3767.0MSIX 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.
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-cli 0.142.0-alpha.6openai-bundled/browser/26.616.41845Impact:
/pband/planbancommands still successfully start/resolve the local board URL through the Planban MCP server.node_repl/jsexecution from the affected desktop thread fails before any user JavaScript runs with: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:
codex app-serveras a possible independent fallback.mcpServer/tool/callfornode_repl/jssuccessfully, so that path does not fail at the exact same metadata boundary.x-codex-turn-metadata, and even thenagent.browsers.list()returned[], including when targeting the current affectedCODEX_THREAD_ID.Operational mitigation on the Planban side:
node_repl/jsfails 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_replstill rejects calls unless legacysandboxPolicyis present.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.
ode_repl.exe appeared to expect the older sandbox metadata shape.
What fixed it locally:
ode_repl.exe to
ode_repl.real.exe.
Verification on my desktop:
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.
Seeing the same failure here. Basic machine details:
The Chrome Codex extension path fails before it reaches Chrome. A minimal
nodeRepl.write('node bridge ok')call also fails immediately with:So this appears to match the reported node_repl/js metadata failure rather than a Chrome-specific problem.
Adding another Windows data point from Codex Desktop after today's update.
Environment observed locally:
OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0openai-bundled/chrome/26.616.41845node_replruntime path:AppData/Local/OpenAI/Codex/runtimes/cua_node/a89897d3d9baa117/bin/node_repl.exeMinimal repro in a local thread:
Result before any JS executes:
Additional checks/recovery attempted:
node_replwith tool search: same error.extensionReady: true,nativeHostCorrect: true,chromeRunning: false,bridgeResetRecommended: false.node_repl.exehelpers: the tool then reportedTransport closeduntil rediscovered/restarted, then returned to the samesandboxPolicyfailure.cua_noderuntime aside to force reprovisioning; Codex did not recreate it in-thread, so I restored the runtime folder.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.
Adding another macOS reproduction with a small direct-MCP diagnostic.
Environment:
26.616.41845, build4198codex-cli 0.142.0-alpha.6v24.14.026.5(25F71), arm64node_replpath:/Applications/Codex.app/Contents/Resources/cua_node/bin/node_replcodexCLI path:/Applications/Codex.app/Contents/Resources/codexworkspace-writeObserved in a normal Codex Desktop thread:
This happens with a trivial non-browser JS call, before any user JavaScript runs:
Additional direct-MCP diagnostics:
--disable-sandboxsucceeds for a minimal JS call:reproduces the exact error:
Result:
This suggests the bundled
node_replserver and Node kernel are healthy, but the CodexDesktop/tool bridge is sending
codex/sandbox-state-metawithout the fields required by thisnode_replbuild. It also confirms the Chrome/browser connector is only a downstream casualty:the failure happens before any Chrome connector code can run.
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._
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.
Adding another macOS repro with matching symptoms.
Environment
/Applications/Google Chrome.appDefault1.1.5_0Failure
Any attempt to use the Chrome bridge / browser automation path fails before JS executes:
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: selectedDefaultprofile 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, andcorrect: true.scripts/open-chrome-window.jsfor the selectedDefaultprofile, waited, then retried the bridge. Samemissing field sandboxPolicyerror.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.
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.
Update after the hotfix: resolved on my macOS setup.
Environment now:
Validation:
mcp__node_repl.jsnow executes and returns the bundled Browser documentation.agent.browsers.get("iab").tab.playwright.domSnapshot()returns page content.So the
codex/sandbox-state-meta: missing field sandboxPolicyfailure is fixed in this environment.Confirmed fixed on my Windows Codex Desktop host after updating.
Previous failing repro from my earlier comments:
26.616.5445.026.616.41845node_repl/jsexecution failed before user JS ran withMcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy@Chrome, and Computer Use could not initialize.Current retest after hotfix/update:
26.616.6631.026.616.5143126.619.1182810.0.26200.8655Smoke results:
mcp__node_repl.js_resetsucceeded.nodeRepl.write('node-repl-ok')returnednode-repl-ok.https://example.com/, titleExample Domain.@Chromeinitially reportedBrowser is not available: extensionwhile Chrome was not running. After launching Chrome, extension-backed bootstrap succeeded, openedhttps://example.com/, read titleExample Domain, and finalized the agent-created tab.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/jssandboxPolicyfailure 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@Chromepath connects.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 sandboxPolicyfailure.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" />
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.
Confirmed fixed, thank you
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:
Error:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field
sandboxPolicyI tried reinstalling and pkill/restarting everything, with no change.
Versions:
CLI and VS Code appear not to send
sandboxPolicyincodex/sandbox-state-metafor node_repl/Chrome MCP calls, while the desktop Codex app does.