Codex App Browser fails on macOS when node_repl receives file URL sandboxCwd
What version of the Codex App are you using?
Codex App / Browser plugin release observed locally: 26.616.41845
What subscription do you have?
Not included here; this report is about local Codex App / bundled MCP runtime behavior.
What platform is your computer?
macOS
Additional local runtime details:
- Bundled Node:
v24.14.0 - Bundled node_repl path:
/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl - Browser backend:
iab - Local URL tested:
http://127.0.0.1:5173/
What issue are you seeing?
Codex App can open the in-app browser manually, and the Browser backend appears ready, but model-side Browser plugin use fails through the bundled node_repl MCP path.
I observed two related sandbox metadata compatibility failures around codex/sandbox-state-meta:
node_replrejects missingsandboxPolicy:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy
sandboxCwdcan be passed as afile://URL:
{
"sandboxCwd": "file:///Users/zhangyifan/self_driven"
}
The bundled runtime then fails while launching Node:
failed to start Node runtime: No such file or directory (os error 2)
My root-cause hypothesis is that the bundled node_repl expects sandboxCwd to already be a native filesystem path, but Codex App / the sender side can pass a file:// URL. I also found a metadata shape mismatch around sandboxPolicy.type: a payload with workspaceWrite is rejected by the bundled node_repl, while workspace-write is accepted.
What steps can reproduce the bug?
- Use Codex App on macOS with the bundled Browser plugin.
- Start or have a local web app available, for example
http://127.0.0.1:5173/. - Manually opening the in-app browser works.
- Ask Codex to use the Browser plugin / in-app Browser against the local page.
- The model-side Browser flow fails in the
node_replMCP path with sandbox metadata errors.
I verified a local workaround by setting CODEX_NODE_REPL_PATH to a wrapper that sits between Codex App and the bundled node_repl. The wrapper normalized the metadata before forwarding:
sandboxCwd:file:///Users/...->/Users/...sandboxPolicy.type:workspaceWrite->workspace-write- filled in missing sandbox metadata when safely derivable
After that workaround:
mcp__node_repl__jsexecuted successfullynodeRepl.cwdwas/Users/zhangyifan/self_driven- Browser runtime connected to
iab - Codex could open and read
http://127.0.0.1:5173/ - The page title was read as
Self Driven
What is the expected behavior?
Codex App and bundled node_repl should agree on the codex/sandbox-state-meta payload shape.
In particular, node_repl or the sender side should handle:
sandboxCwdas either a native filesystem path or afile://URL, normalizing to the native path before launching Node.sandboxPolicy.typevalues consistently, or compatibly accept both the app-server/API styleworkspaceWriteand the legacy/sandbox-mode styleworkspace-writewhere this metadata boundary requires it.- missing required metadata with a clear validation error that identifies the missing field and expected shape, rather than surfacing as
failed to start Node runtime: No such file or directory.
Additional information
I searched existing issues and found nearby Windows reports about missing field sandboxPolicy, but I did not find one covering this macOS sandboxCwd: file://... launch failure.
The bundled node_repl receiver implementation does not appear to be present in the public repo, but the public sender-side code that builds codex/sandbox-state-meta is present.
I prepared a small sender-side patch for reference, but did not open a PR because docs/contributing.md says unsolicited PRs are closed without review:
https://github.com/openai/codex/compare/main...ruarua6666:codex/normalize-node-repl-sandbox-meta
That reference patch changes the public sender-side metadata to:
- include a legacy-compatible
sandboxPolicy - serialize
sandboxCwdas an inferred native filesystem path instead of afile://URI - update the existing RMCP integration assertion for sandbox metadata
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗