Security: MCP tool approvals should show full arguments before execution

Open 💬 2 comments Opened May 27, 2026 by psyche314

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?

Configure an MCP server with a tool that accepts executable script/code/command text as an argument.
Ask Codex Desktop App to use that MCP tool.
Observe the approval UI shown before the MCP tool call is allowed.
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.

View original on GitHub ↗

2 Comments

Ram9199 · 2 months ago

@psyche314 agreed that full arguments are the security boundary here. For MCP tools, a prompt that hides or truncates arguments is closer to a blind approval than a meaningful approval.

We have been working on Agent_Sudo around this exact issue. The model we landed on for audit/interop is that the proposed tool call should preserve enough structured data to verify what was approved later: server/tool, full or hashed canonical args, risk classification, resource/path/domain, approval decision, and execution result.

For UI, I think your raw-arguments proposal is the right minimum. For logs/audit, I would also want the exact canonical arguments hash included in the approval record so a later verifier can prove the payload that executed is the same payload the user approved.

rpelevin · 2 months ago

I would treat the approval dialog and the executed MCP call as two views of the same canonical request.

For risky MCP tools, the approval record probably needs:

server id / server label
tool name
full structured arguments in the UI, with only secret values redacted
canonical args digest
working directory or target resource scope when available
risk class
requested_at
decision
decided_by
consumed_at

The important part is that redaction should hide secret values without hiding the dangerous payload. If the argument is a script, shell command, path, URL, SQL statement, or generated patch, the user needs enough of that exact payload to know what will execute.

If the payload is too large for the prompt, I would fail toward an expandable/full-view state rather than a truncated approval. The digest can make the audit trail precise, but the UI still has to show the human enough context to make the decision.

Useful regressions: approval for command A cannot execute command B; a tool-call argument change after approval makes the decision stale; secret redaction cannot hide the command/path/action class; and a truncated preview cannot be the only approval surface for executable or mutating payloads.