macOS: Shell execution silently fails in workspace-write and read-only sandboxes via mcp-server; danger-full-access works

macOS: Shell execution silently fails in workspace-write and read-only sandboxes when launched via mcp-server; danger-full-access works

Summary

When running codex mcp-server (stdio) on macOS and calling the codex tool with sandbox: workspace-write or sandbox: read-only, shell command execution is blocked at sandbox setup before any exec_command_begin event is emitted. The model reasons, produces plans, and acknowledges the failure ("The failure is happening before command execution, at sandbox setup itself"), but never actually runs the command. The same session with sandbox: danger-full-access works correctly.

This makes Codex unusable as an MCP server for any code task on macOS unless the caller opts into danger-full-access, which defeats the purpose of sandboxing.

Environment

• macOS 26.4.0 (arm64, Apple Silicon)
• Codex CLI: codex-cli 0.99.0-alpha.5
• Binary: /Applications/Codex.app/Contents/Resources/codex
• Model: gpt-5.4
• Transport: stdio (codex mcp-server)
• Client: custom stdio JSON-RPC client (issue also reproduces from Kiro CLI + AIM agent setup)

Reproduction

Send this sequence to codex mcp-server via stdio:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"codex","arguments":{"prompt":"Run: ls -la in the current directory. Just do it. Report what you see.","cwd":"/tmp","sandbox":"workspace-write","approval-policy":"never"}}}

Expected

• exec_command_begin event with ["/bin/zsh","-lc","ls -la"]
• exec_command_end with stdout + exit_code 0
• Agent message reporting the directory contents

Actual

• No exec_command_begin is ever emitted
• The model produces 4 sequential agent_message events attempting workarounds:

1. "I'm going to load the required workspace context first, then I'll run ls -la..."
2. "The shell tool is being blocked by the local sandbox wrapper, so I'm trying a narrower invocation..."
3. "I can't get a sandboxed shell at all. I'm testing whether the tool will allow a direct non-sandboxed ls -la..."
4. "The failure is happening before command execution, at sandbox setup itself. I'm checking whether it's specific to this workspace or a broader shell outage."

• Model falls back to list_mcp_resources and list_mcp_resource_templates (both empty), eventually gives up or resorts to web search

Control: danger-full-access works correctly

Identical request with "sandbox":"danger-full-access":

CMD: ['/bin/zsh', '-lc', 'ls /tmp']
  STDOUT: Kiro-45ddc189-fc1f-46ce-96d5-ebfb5530d2d1.sock
MacSpoolerService
a62ed1c1-e1a9-5495-9038-16bd49ec7341
...
  EXIT: 0

→ exec_command_begin + exec_command_end fire normally, stdout is captured, agent reports results.

Session configuration echoed by server

{
  "type": "session_configured",
  "session_id": "019d98dd-df2c-7421-b2cf-52ecb2711d25",
  "model": "gpt-5.4",
  "model_provider_id": "openai",
  "approval_policy": "never",
  "sandbox_policy": {
    "type": "workspace-write",
    "network_access": false,
    "exclude_tmpdir_env_var": false,
    "exclude_slash_tmp": false
  },
  "cwd": "/Users/asulgrov/.openclaw/workspace/claudia-cockpit"
}

Sandbox policy is parsed correctly and set to workspace-write, but shell execution still fails.

Impact

• Renders Codex unusable as an MCP-driven subagent for autonomous code tasks on macOS (the primary use case for the MCP surface) unless callers grant danger-full-access.
• In my setup (Kiro CLI + AIM agent package registering Codex as a subagent), every code-analysis task fails this way — Codex cannot rg, ls, or cat to inspect the workspace it was given.
• Silent failure: no error is returned to the MCP client. The model just gives up after several reasoning cycles. Clients that don't inspect reasoning traces see only an unresponsive agent.

Suggested fixes

1. Emit an explicit error event (e.g., exec_command_error with a clear sandbox-setup message) when seatbelt/landlock setup fails, so MCP clients can surface the problem.
2. Verify that workspace-write + approval-policy: never correctly wraps shell commands via Seatbelt on macOS in mcp-server mode (parity with codex exec / interactive CLI, where the same sandbox modes work fine).

Related

• #13987 ([Windows] read-only sandbox mode causes MCP shell_command to stall indefinitely — same category of issue, different platform)
• #14115 (codex exec on macOS initializes external MCP and lists tools but never sends tools/call — related macOS + MCP stall pattern)

Happy to provide full JSONL event logs (~2500 lines per run) if useful.