codex exec: no way to allow MCP tool calls non-interactively without --dangerously-bypass-approvals-and-sandbox

Proposed Solution: MCP-Specific Approval Config for Non-Interactive Mode

Root Cause

MCP tool calls go through the same approval prompt as other tools. When stdin is closed (non-interactive), EOF is interpreted as "user declined". No config key bypasses MCP approval while keeping sandbox active.

Fix

1. Add [mcp_servers.<name>] auto_approve_tools = true config key
2. Respect approval_policy = "never" for MCP calls (currently only affects non-MCP)
3. Split --dangerously-bypass-approvals-and-sandbox into --bypass-approvals + --bypass-sandbox

fn handle_mcp_tool_call(call, config) {
    let auto_approve = config.mcp_servers.get(&call.server_name)
        .map(|s| s.auto_approve_tools).unwrap_or(false);
    if auto_approve || config.approval_policy == Never {
        return execute_tool_call(call);
    }
    prompt_for_approval(call)
}

Full solution: solutions/codex-24135-mcp-tool-calls-non-interactive-fix.md

I think there is one safety detail worth making explicit if Codex adds an MCP-specific non-interactive approval path.

For headless codex exec, I would avoid making this only a broad boolean like auto_approve_tools = true. The production-safe shape is closer to:

• keep the filesystem/network sandbox setting independent from MCP approval
• trust a server by stable identity: configured name, transport, command/url, cwd, and env-file boundary
• trust individual tools by namespaced key, for example spike.echo_hello, not just raw tool name
• store a reviewed discovery snapshot from tools/list
• re-enter review if a tool is added, removed, or its metadata/schema changes
• treat server annotations such as read-only/destructive/idempotent as advisory inputs, not proof
• in non-interactive mode, fail closed if no reviewed allow entry matches

That would preserve the thing this issue is asking for: first-party MCP tools can run in codex exec -s read-only without stdin approval prompts, while the user does not have to use the broader dangerous bypass flag.

I made a small free helper for this exact review artifact while testing MCP launch/security workflows:

https://github.com/kayalopez/ai-agent-launch-tools/releases/tag/v0.1.7

It turns non-sensitive tools/list JSON into an allow / ask / deny matrix and emits a snapshot digest plus per-tool metadata digests. It can also print a Codex config.toml review snippet: allow -> approval_mode = "approve", ask -> approval_mode = "prompt", and deny -> disabled_tools, without changing sandbox settings. The useful bit for this issue is the acceptance-test pattern: run discovery, approve exact tool keys, then verify a changed tools/list snapshot forces review instead of inheriting approval silently.

No tool calls are executed by the helper; it only classifies pasted/exported metadata.

For non-interactive codex exec, I would keep sandbox policy and MCP approval policy completely separate.

The unsafe shape is a broad switch that means "auto-approve MCP tools" and accidentally becomes equivalent to bypassing the sandbox. The safer shape is a scoped MCP approval policy that can be evaluated without stdin:

• MCP server identity;
• tool name;
• canonical args digest or args pattern;
• read/write/destructive classification;
• allowed workspace or resource scope;
• network scope, if relevant;
• expiry;
• policy id;
• decision: allow, deny, require_interactive.

Then headless execution can work like this:

• if a pending MCP call matches an explicit allow rule, execute under the existing sandbox;
• if it matches deny, return a terminal denied tool result;
• if it requires interactive approval and stdin is closed, fail closed with a clear approval-required result;
• never make --dangerously-bypass-approvals-and-sandbox the only path to non-interactive MCP.

Regression tests I would want:

• read-only sandbox remains active while an allowed MCP tool runs;
• write/destructive tool is denied without a matching policy;
• changed args do not reuse a prior allow decision;
• closed stdin produces a visible approval-required result, not silent cancellation;
• policy expiry invalidates future headless calls.

That gives automation a safe path without making approval bypass and sandbox bypass the same lever.

This is exactly the kind of problem I'm trying to validate.

I've been building a small Python authorization layer that sits outside the agent and evaluates individual tool calls before execution, rather than having to choose between interactive approval and effectively bypassing the safety layer.

The interesting use case seems to be headless/CI agents where you still want deterministic permissions and possibly approval policies without a human sitting at stdin.

If you've still got the use case around, I'd be happy to give you the prototype to test against your MCP setup.

I'd be especially interested in whether it actually solves the gap or just adds another layer you wouldn't want in the stack.