Skip to content

Codex App Browser fails on macOS when node_repl receives file URL sandboxCwd #29348

Open

Description

@ruarua6666

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:

  1. node_repl rejects missing sandboxPolicy:
Mcp error: -32602: js: codex/sandbox-state-meta: missing field sandboxPolicy
  1. sandboxCwd can be passed as a file:// 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?

  1. Use Codex App on macOS with the bundled Browser plugin.
  2. Start or have a local web app available, for example http://127.0.0.1:5173/.
  3. Manually opening the in-app browser works.
  4. Ask Codex to use the Browser plugin / in-app Browser against the local page.
  5. The model-side Browser flow fails in the node_repl MCP 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__js executed successfully
  • nodeRepl.cwd was /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:

  • sandboxCwd as either a native filesystem path or a file:// URL, normalizing to the native path before launching Node.
  • sandboxPolicy.type values consistently, or compatibly accept both the app-server/API style workspaceWrite and the legacy/sandbox-mode style workspace-write where 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:

main...ruarua6666:codex/normalize-node-repl-sandbox-meta

That reference patch changes the public sender-side metadata to:

  • include a legacy-compatible sandboxPolicy
  • serialize sandboxCwd as an inferred native filesystem path instead of a file:// URI
  • update the existing RMCP integration assertion for sandbox metadata

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    mcpIssues related to the use of model context protocol (MCP) servers
    sandboxIssues related to permissions or sandboxing
    on Jun 21, 2026
  2. ruarua6666 commented on Jun 21, 2026

    @ruarua6666
    Author

    Why this matters:

    This is not just a cosmetic metadata mismatch. In this state, Codex App can show that the in-app Browser backend is available, and the user can open the browser manually, but model-side Browser use fails before the JS kernel starts. That makes Browser / node_repl-backed MCP tools unusable for affected users.

    The failure also looks like a local Node/runtime path problem:

    failed to start Node runtime: No such file or directory (os error 2)

    but the underlying issue appears to be metadata shape incompatibility: sandboxCwd is passed as a file:// URI while the bundled runtime expects a native filesystem path, and sandboxPolicy.type may differ between workspaceWrite and workspace-write.

    Normalizing this boundary would make the App and bundled node_repl tolerant across nearby release versions, reduce duplicate reports like the existing missing sandboxPolicy issues, and provide clearer errors when metadata is genuinely incomplete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverssandboxIssues related to permissions or sandboxing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions