Repository navigation
Permission requests should carry toolCall.name for every approval kind (file change, MCP, non-unified-exec commands) #553
Description
Versions
@agentclientprotocol/codex-acp:1.13.1(b1b8490c). The behaviour is unchanged on currentmain.- Codex CLI:
0.156.1, as bundled - ACP protocol version:
1
Summary
Most session/request_permission requests reach the client with no toolCall.name, and so does the tool_call frame before each of them. A client that applies policy by tool identity can't tell what it is being asked to approve. It sees only a human-readable title, and that is not a stable identifier.
ToolCallUpdate treats an omitted name as "unchanged", so a client can't recover it from an earlier frame either: a request and its preceding frame are named together or nameless together.
Minimal reproduction
- Start
codex-acpand create a new ACP session inread-onlymode. - Prompt for work that needs approval: a file change outside the workspace, or an MCP tool call.
- Record the
session/request_permissionrequests and thetool_call/tool_call_updateframes with the sametoolCallId.
In our captures, 3 of 3 permission requests and their preceding frames had no name. Auto-approved command frames in the same sessions do carry exec_command.
Actual behavior
From the source at b1b8490c (unchanged on main):
| Approval | toolCall.name |
Where |
|---|---|---|
Command, unifiedExecStartup source |
exec_command |
src/ToolCallName.ts:8-18 |
Command, agent / userShell source |
undefined ("these sources do not identify a unique model tool") | src/ToolCallName.ts:8-18, used by src/permissions/presentation.ts:22,37 |
| stdin to a running process | write_stdin or undefined; the bytes being written are not in rawInput |
CommandExecutionRequestApprovalParams |
| File change / apply_patch | undefined, and rawInput is also absent |
src/permissions/presentation.ts:56-68 |
| MCP tool approval | undefined; the identity is only in title (mcp.<server>.<tool>) |
src/permissions/mcp.ts:98-129 |
| MCP question / URL elicitation | undefined | same |
| Plan review | undefined | src/permissions/plan-review.ts:7-30 |
A client that mediates permissions for policy, audit or human approval has to deny a request it can't identify. That rules out file changes outside the workspace, MCP tools and network access under any client-side policy.
Expected behavior
Every permission request, and the tool_call it refers to, carries a stable name for the approval kind. For example:
apply_patch/file_changemcp_tool_call, with the server and tool inrawInputexec_commandfor every command sourcewrite_stdin, with the input bytes inrawInputplan_review
A structured rawInput for file changes, with paths and the operation, would also make these approvals auditable.
Related: #401 (MCP calls running before permission mediation) is the other half of the same problem. A client can only govern what is both asked about and identified.
Activity