Security: MCP tool approvals should show full arguments before execution

What version of Codex are you using?

Not sure / current Codex Desktop App.

What platform is your computer?

Windows.

What issue are you seeing?

The Codex Desktop App approval UI for MCP tool calls does not appear to show the full tool arguments before the user approves the call.

This is a serious safety problem for MCP tools whose arguments are themselves the dangerous payload. A common example is an MCP tool that executes a script or command supplied as an argument, such as:

{
  "tool": "exec_script",
  "arguments": {
    "code": "... arbitrary script ..."
  }
}

If the approval dialog only shows that an MCP tool is being called, but not the complete arguments object, the user cannot tell what code, command, working directory, environment, file path, or other sensitive operation is actually being approved.

This makes the approval prompt ineffective as a security boundary for many MCP tools. It is especially concerning for tools that run code, modify files, access credentials, make network requests, or invoke privileged local workflows.

What steps can reproduce the bug?

1. Configure an MCP server with a tool that accepts executable script/code/command text as an argument.
2. Ask Codex Desktop App to use that MCP tool.
3. Observe the approval UI shown before the MCP tool call is allowed.
4. The UI does not clearly display the complete raw MCP tool arguments that will be sent to the tool.

What is the expected behavior?

Before approving an MCP tool call, the user should be able to inspect the complete arguments that will be sent to the MCP server.

At minimum, the approval UI should show:

• MCP server name
• tool name
• complete JSON arguments
• command/script/code text in a readable, scrollable, copyable block
• working directory / relevant environment information if applicable
• a clear warning for tools that execute code or shell commands

For high-risk MCP tools, such as script/code/command execution tools, Codex should consider requiring explicit confirmation after showing the full payload.

Why this matters

MCP tool calls can perform arbitrary local actions depending on the server implementation. If the UI hides or truncates the arguments, a malicious prompt injection or model error could cause the user to approve a dangerous operation without seeing the actual payload.

The protocol / app server event model appears to have access to tool arguments internally, so this seems like a UI/UX and safety issue rather than an MCP limitation.

Additional information

A good mitigation would be to provide an expandable "raw arguments" section for every MCP tool call approval, and a specialized preview mode for execution-like tools. Users should not have to inspect local session transcripts or MCP server logs to know what they are approving.