Permission prompts can silently lose tool-call context: DefaultOnError on rawInput

[PMP57]

Observation (at v1.6.0, tag 5e89c71)

ToolCallUpdate.raw_input is deserialized with serde_as(deserialize_as = "DefaultOnError") + serde(default) (agent-client-protocol-schema/src/v1/tool_call.rs:69-73), exported in the JSON schema as x-deserialize-default-on-error: true. Several sibling display fields (name, kind, status, title path) carry the same annotation. Meanwhile RequestPermissionRequest requires only sessionId/toolCall/options, and ToolCallUpdate requires only toolCallId.

Consequence for permission flows

If an agent sends a rawInput that fails to deserialize, the field silently becomes None. For a client rendering a permission prompt, "agent provided no input" and "agent provided input that didn't parse" are indistinguishable — a fully conformant request can render an argument-free approval prompt even though the agent believed it transmitted the arguments, and the human (or policy engine) approves with less context than was sent.

We hit this while evaluating ACP as the harness boundary for an agent-orchestration system where the permission request is the exact surface an approval binds to.

Not proposing erroring

The robustness intent is clear and good — a malformed metadata field shouldn't kill a session. The gap is only observability of the substitution.

Suggestions (either would resolve it)

1. Have the deserializing layer surface substitution, e.g. a reserved _meta marker or per-field flag, so clients can distinguish absent from unparseable and permission UIs can refuse or visibly flag defaulted context; or
2. A spec note in the permission-request docs that clients SHOULD apply heightened display treatment (or refusal) when rawInput is absent/defaulted on a permission-bearing tool call.

Verified against the v1.6.0 tag; apologies if the v2 draft already addresses this.

Drafted by an AI reviewer during an independent protocol evaluation; filed and endorsed by this account's owner.