Headless `codex exec` blocks side-effecting MCP tools under read-only/workspace-write sandboxes

[kamilio]

Summary

When spawning codex non-interactively via spawn/spawn.pretty with mode: "read" or mode: "edit", the agent is unable to invoke side-effecting MCP tools — the tool call is silently canceled before it reaches the MCP server. Only mode: "yolo" (codex -s danger-full-access) lets MCP tool calls through.

This forces any agent that must call an MCP tool (e.g. to post a Slack reply, file a ticket, etc.) to run in full-access mode, even when the agent only needs a read-only filesystem for its actual work.

Mode → codex flag mapping (current)

From providers/codex.js:

read:  ["-s", "read-only"]
edit:  ["-s", "workspace-write"]
yolo:  ["-s", "danger-full-access"]

codex exec has no --ask-for-approval prompt path (it's headless), so under read-only/workspace-write a side-effecting MCP tool call is auto-canceled rather than executed.

Reproduction

Spawn codex via codex exec with an MCP server configured (-c mcp_servers.<name>.command=...) and a prompt instructing it to call one of that server's tools. Observe the tool result per sandbox mode:

codex sandbox (-s)	MCP tool call
read-only	canceled / blocked
workspace-write	canceled / blocked
read-only + -a never	errors out (exit 2)
danger-full-access	executes

The MCP server itself is correct: driving the same server with a standard MCP client (@modelcontextprotocol/sdk Client + StdioClientTransport) executes the tool in ~14ms. The gating is entirely in codex's headless sandbox/approval handling.

Impact

A read/edit agent that needs to call an MCP tool fails silently — the model "calls" the tool, codex cancels it, and the run completes without the side effect ever happening. There's no error surfaced to the caller from codex's side.

Request

Provide a way to run codex headlessly with a restricted filesystem sandbox (read-only / workspace-write) while still permitting configured MCP tool calls — e.g.:

• an approval-policy/MCP-trust option that auto-approves configured MCP servers' tools under read-only/workspace-write, or
• treating configured MCP tools as out-of-sandbox (they're trusted, caller-configured servers), or
• at minimum, surfacing a clear error when an MCP tool call is canceled due to sandbox policy instead of silently dropping it.

Today we have to set mode: "yolo" for any codex agent that posts to Slack, which over-grants filesystem/network access purely to unblock the MCP reply tool.

[kamilio]

Follow-up: tested the approval-policy angle — it does not help

To save the next person time, I tested whether keeping a restricted sandbox + overriding the approval policy unblocks MCP tools in headless codex exec:

flags	MCP tool call
-s read-only -c approval_policy="never"	canceled — stderr: user cancelled MCP tool call (exit 0)
-s workspace-write -c approval_policy="never"	canceled — user cancelled MCP tool call (exit 0)
-s read-only -a never	invalid — -a is not an exec flag (tip: to pass '-a' as a value, use '-- -a', exit 2)
-s danger-full-access	runs ✓

So:

• -a/--ask-for-approval is only on the interactive codex command, not codex exec.
• -c approval_policy="never" parses fine but does not auto-approve MCP tool calls — codex still emits user cancelled MCP tool call under read-only/workspace-write. This lines up with codex's own description that approvals gate running outside the sandbox; MCP tools run outside the sandbox, so headless (no approver) → auto-cancel regardless of approval_policy.

The only thing that works today is fully disabling the sandbox (danger-full-access), which over-grants FS/network just to allow a trusted, caller-configured MCP server's tool.

Refined request: a way to trust/allowlist a configured MCP server so its tools run under read-only/workspace-write without per-call approval in headless exec — e.g. mcp_servers.<name>.trusted = true or an auto-approve list. Today there's no config knob for this that I could find.

[poe-code-agent]

Issue was resolved by #fbfa067

Update poe-code via npm install -g poe-code@3.0.242