Hi Codex team, I am seeing a persistent issue with the Codex desktop app in-app browser, annotation tool, and browser automation bridge. Error shown to the agent/tooling: ```text codex/sandbox-state-meta: missing field sandboxPolicy ``` Environment: - Codex desktop app version: 26.616.41845 - Platform: macOS - Workspace: local trusted project - Permissions UI shows Full access enabled - Browser plugin and in-app browser are enabled What happens: - The in-app browser can open localhost pages

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #29199 - #29193 - #29189 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Codex desktop browser/annotation tools fail: missing field sandboxPolicy

Resolved 💬 15 comments Opened Jun 20, 2026 by JeanPosthumus Closed Jun 21, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Hi Codex team,

I am seeing a persistent issue with the Codex desktop app in-app browser, annotation tool, and browser automation bridge.

Error shown to the agent/tooling:

codex/sandbox-state-meta: missing field sandboxPolicy

Environment:

Codex desktop app version: 26.616.41845
Platform: macOS
Workspace: local trusted project
Permissions UI shows Full access enabled
Browser plugin and in-app browser are enabled

What happens:

The in-app browser can open localhost pages, but the agent cannot control or inspect it.
Any attempt to use the in-app browser / JS browser bridge fails immediately with:

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

The annotation tool is also unreliable/broken, likely because it depends on the same browser bridge.
Restarting Codex multiple times did not fix it.
Toggling permissions between Ask for approval and Full access did not fix it.
Local state inspection showed the current thread keeps being stored/recreated with:

sandbox_policy = {"type":"disabled"}

The app also rewrites config.toml back to:

js_repl = false

Manually repairing local state while Codex was closed did not persist; Codex rewrote the broken values after startup.

Expected behavior:
The in-app browser and annotation tool should work when the workspace has Full access.

Actual behavior:
Browser/annotation automation fails before the agent can access the page, even though permissions are enabled.

Could you help me fix or safely reset the Codex desktop app state without losing important workspace/thread history?

View original on GitHub ↗

15 Comments

github-actions[bot] contributor · 1 month ago

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

#29199
#29193
#29189

Powered by Codex Action

ZBQtesla · 1 month ago

same problem for me

esj1123 · 1 month ago

I can reproduce this after a Codex Desktop update on Windows. Adding a redacted timeline and checks in case it helps narrow the regression.

Environment

Windows / Codex Desktop
Codex Desktop package observed: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
Current CLI used by generated config: codex-cli 0.142.0-alpha.6
Current generated CODEX_CLI_PATH points to a hash directory under %LOCALAPPDATA%\OpenAI\Codex\bin\...
node_repl.exe is launched from %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_repl.exe
node_repl.exe SHA256 matched the copy bundled in the installed app package, so local runtime file corruption seems unlikely.

Timeline

Earlier on 2026-06-20, node_repl/js worked in Codex Desktop threads. Successful Computer Use calls included bootstrap, sky.list_apps(), get_window_state, and Windows app inspection.
Successful thread examples before the update had DB cli_version values of 0.142.0-alpha.1 or empty.
The app/CLI resources were updated around 2026-06-20 17:18-17:21 KST.
After that, new threads using cli_version = 0.142.0-alpha.6 consistently fail every node_repl/js call with the missing sandboxPolicy error.

Minimal repro

js_reset succeeds:

js kernel reset

But any js execution fails before user JS runs, including:

nodeRepl.write('ok')

Observed:

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

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

Computer Use bootstrap fails at the same MCP boundary before reaching sky.list_apps().

Relevant checks

The current thread row in %USERPROFILE%\.codex\state_5.sqlite has a non-empty saved sandbox_policy JSON with type: managed, restricted filesystem entries, and restricted network.
The global/heartbeat permission state also contains sandboxPolicy for the affected thread.
This makes it look like the sandbox policy is persisted, but is not being serialized into the MCP tool-call _meta["codex/sandbox-state-meta"].sandboxPolicy shape expected by node_repl/js.
Restarting Codex Desktop, resetting the JS kernel, and allowing Codex to regenerate the generated node_repl config block did not fix it.

Current assessment

This looks like a regression or migration issue in the Codex Desktop app-server / CLI 0.142.0-alpha.6 metadata bridge for MCP tool calls. The stored sandbox_policy exists, but node_repl/js receives codex/sandbox-state-meta without required sandboxPolicy.

painh · 1 month ago

I’m seeing the same failure on macOS.

Environment:

Codex Desktop: 26.616.41845, bundle version 4198
Bundled Codex CLI: codex-cli 0.142.0-alpha.6
Global CLI: codex-cli 0.136.0
Bundled Node: v24.14.0
Chrome: 149.0.7827.115
Chrome plugin enabled: chrome@openai-bundled
Browser backends configured: chrome,iab

Chrome-side checks passed:

Chrome is running
selectedProfileDirectory is Profile 1
Codex Chrome Extension hehggadaopoacecdllhhajmbjkdcmajg is installed and enabled in Profile 1
Extension version: 1.1.5_0
Native messaging host manifest exists and has the expected origin

Node REPL behavior:

tool_search exposes node_repl tools
js_reset works
js_add_node_module_dir works
minimal js execution fails before user code runs:

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

So this looks like the same Desktop/app-server/MCP metadata issue rather than a Chrome extension/profile/native-host problem.

CJavierSaldana · 1 month ago

I can reproduce this on macOS as well.

Environment:

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

Observed behavior:

In-app browser / annotation / browser automation all fail with:

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

The agent cannot control or inspect the browser because node_repl/js rejects the tool call before any JS runs.
Restarting Codex and toggling permissions (Ask for approval ↔ Full access) did not fix it.

Additional symptom (Chrome profile):

When Codex tries to use Chrome, it does not use my existing Chrome profile.
It launches a brand-new Chrome profile with zero integrations (no extensions, no saved logins, no connected services).
My real Default profile — where the Codex Chrome extension and everything else is configured — is never used.
Net result: browser, annotation, and Chrome-backed automation are all broken end-to-end.

Impact:

In-app browser control: broken
Annotation tool: broken (depends on same bridge)
Chrome plugin: broken (wrong profile + sandboxPolicy error)
Shell/file tools: still work

Same regression as #29189 / #29193 from my side — Desktop 26.616.41845 is not passing the sandboxPolicy field that bundled node_repl now requires.

mingxuanli424-creator · 1 month ago

I can reproduce this on Windows Codex Desktop 26.616.5445.0.

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

After deleting bundled plugin caches and restarting, Codex regenerates config.toml with:
js_repl = false
[mcp_servers.node_repl]
[mcp_servers.node_repl.env]

I submitted in-app feedback with ID:
019ee5ad-e439-75c0-ae27-3fc8e965559c

H1ghSyst3m · 1 month ago

Same issue here

stridr5555 · 1 month ago

They broke it with this update.
Luckily, Browser Chrome CDP Skill working as a backup with cloned chrome profile.

karlfrankeser · 1 month ago

I am hitting the same issue on Codex Desktop with both `@chrome` and `@Browser`.

Error:

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

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

Environment:

Codex Desktop app version: 26.616.41845
Bundled CLI: codex-cli 0.142.0-alpha.6
macOS: 26.5.1
Workspace sandbox: workspace-write
Network access: enabled
Approval policy: never
Browser plugins enabled:
browser@openai-bundled
chrome@openai-bundled
node_repl MCP is enabled and configured.

I tried:

Quitting Codex completely.
Backing up ~/.codex/config.toml and ~/.codex/.codex-global-state.json.
Removing stale [features] js_repl = false.
Clearing ~/.codex/node_repl/active_execs/*.
Reopening Codex and retrying @chrome.

The error still happens before the Chrome/browser bridge can initialize. Also, Codex appears to rewrite js_repl = false back into ~/.codex/config.toml on startup.

This happens before browser-client code can run, so it does not look like a Chrome extension/native-host issue. It looks like the MCP/tool-call metadata sent to node_repl/js is missing the internal camelCase sandboxPolicy field.

neonwatty · 1 month ago

Adding one more macOS reproduction data point.

Basic machine details:

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

Observed behavior matches this issue: Chrome/browser automation fails before reaching the browser because node_repl/js fails immediately. A minimal call also fails:

nodeRepl.write('node bridge ok')

Result:

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

This looks like the same node_repl/js metadata issue, not a Chrome extension or webpage-specific failure.

m-thomson · 1 month ago

Same problem here after the latest update: 26.616.41845 . The screenshot is from a brand new session after a restart.

How can we download the previously working version?

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.

karlfrankeser · 29 days ago

@etraut-openai i can confirm it works now, thanks a lot!

oppenheimor · 29 days ago

It works! Thank you!

Inostruct · 29 days ago

This is still now working when using desktop app on windows.
019eede0-c321-7481-97ae-af327f81fec1