ACP permission prompts show only the tool title (e.g. "Shell") — the actual command being approved is not visible #4420
Description
Activity
Hi @docker/ai-agent-team, I'd like to help with this. I reproduced the protocol-side behavior on current main (
bb694b9): the permission request containsrawInput.cmd = "docker ps -a", but the permission, pending, and running titles all remainShell. The reproducer uses a fake runtime and the ACP SDK without a model or executing the command; I haven't verified rendering in Zed or IntelliJ.Before implementing, could you advise on these points?
- Ownership and scope: Is anyone already working on this, and would you be comfortable with me taking a shell-only fix, leaving filesystem and other tools for a follow-up?
- Truncation: What preview limit would you prefer (bytes, characters, or display width), and how should omitted text be indicated?
- Multiline commands: Should newlines and control characters be visibly escaped into a single-line title, or represented another way? I'd avoid collapsing whitespace because it can misrepresent quoted arguments.
- Sensitive arguments: Is copying command arguments from
rawInputinto the more prominent title acceptable, or should this follow a particular redaction policy?
My proposed approach is to share title generation between the start and permission/update paths and reuse the shell's existing
cmd/commandresolver. The originalrawInput, lifecycle IDs, permission choices, and session-scoped approval behavior would stay unchanged, with no additional command-bearing logging or telemetry.Hi @dgageot, a gentle follow-up on the proposal above: would a shell-only command preview in ACP permission and transcript titles be a suitable scope? Guidance on the preferred truncation, multiline/control-character display, and handling of sensitive arguments would help. I haven't started a production patch and will wait for scope and format guidance. Thanks!
Hi @dgageot, checking back on the shell-only ACP command-preview proposal. Would that be a useful first step, or would you prefer a different scope or presentation? Happy to adjust to your guidance; I haven't started a production patch. Thanks!
Description
When running an agent in ACP mode (
docker agent serve acp ./agent.yaml) from an ACP-compatible client,tool-approval prompts for the shell tool display only the word "Shell". The actual command that would be
executed is not visible anywhere in the prompt, so you're asked to approve (or reject) a command you can't
see.
The command does appear to be sent over the wire — it's present in the rawInput field of the permission
request's tool call update (e.g.
{"cmd": "...", "cwd": ".", "timeout": 30}) — but the human-readable title isjust the tool's static annotation title ("Shell"), which is what my client renders in the dialog. The same
static title is used for the tool call updates in the transcript, so those also show only "Shell".
Expected Behavior
The approval prompt should convey what is actually being approved. For the shell tool, the prompt should
include the command (or a truncated preview), e.g. as the tool call title (
Shell: docker ps -a / Run: rm -rf /tmp/scratch) in addition to rawInput. Ideally this generalizes: derive a descriptive title from themeaningful arguments of well-known tools (command for shell, path for file operations, etc.).
Actual Behavior
The permission prompt shows only "Shell" with the options "Allow this action" / "Allow and remember my choice"
/ "Skip this action" and no command text. Seeing the command requires an ACP client that renders rawInput (raw
JSON) somewhere in its UI.
Steps to Reproduce
docker agent serve acp ./agent.yaml.Versions
Docker Agent: v1.139.0
ACP clients:
Screenshots