Render sandbox command approvals as terminal confirmations

[Osvaldo Ortega (osortega)]

Sandbox command approvals render as a plain text card instead of the terminal confirmation, so the user approves a command they cannot see.

Before / after

A shell-command permission request from a cloud sandbox session:

Before	Title "Run command", body showing the agent's stated intention (e.g. "Find copilot CLI sandbox builder"). The command itself is never shown.
After	The standard terminal confirmation card, with the command rendered as shellscript.

Why it happens

isTerminalToolCall has three ways to recognize a terminal call, but two of them only apply once the tool is Running/Completed. At confirmation time — the moment that matters — the only live signal is _meta.toolKind === 'terminal'.

toolKind is a VS Code-private rendering hint, not part of the Agent Host Protocol. Our own getToolKind says so: "This is not part of the protocol and is injected by the agent adapter." Our in-process adapters (mapSessionEvents.ts, claudeToolDisplay.ts) stamp it; a remote agent host is a separate implementation and has no reason to know about it. With no toolKind, the call falls through to the generic tool card.

Note the contrast with subagents: isSubagentTool already has a tool-name fallback for exactly this "server didn't send _meta" case. Terminal had none.

The change

getToolKind falls back to the permission metadata a remote host does provide on a pending confirmation, mapping it to the rendering hint:

• a shell-command request → terminal
• a file-read request → read

Everything downstream is untouched: the existing terminal confirmation renderer takes over, reading the command from toolInput, which was already available. Putting the fallback in getToolKind rather than in isTerminalToolCall means all eight call sites agree — confirmation, live rendering, and history replay.

Path-batched requests are deliberately not mapped to terminal. Their subject is a list of paths rather than a command line, so rendering one as a command would misdescribe what is being approved. Covered by a regression test.

Why this isn't temporary

The Agent Host Protocol has no field that identifies a pending tool call as a shell command — not toolName, intention, confirmationTitle, or anything else on ToolCallPendingConfirmationState. The only in-protocol signal is a Terminal content block, which does not exist until the tool is already running, i.e. after approval. So this gap is not something a host-side change alone can close today, and the fallback is expected to be long-lived.

An earlier revision of this PR also adapted file-write permissions (restating the target file as a markdown link so the card and sessions list showed a file pill). That has been removed: it duplicated information a host can supply directly, so it would have become dead code rather than a lasting fix. Tracked separately with the agent host team.

Testing

Three unit tests in stateToProgressAdapter.test.ts, built from a real pending-confirmation payload:

• a command permission renders the terminal confirmation with the real command
• the alternate payload shape is honoured when the primary one is absent (older hosts send only the raw form)
• a path-batched permission stays on the generic card

Verified the first two fail without the change. Full suite: 814 passing across the adapter, chat contribution, client tools, confirmations, approval model and tool-display suites; typecheck and layer checks clean.

Risk

The fallback only fires when _meta.toolKind is absent, which is only ever a remote host — local sessions cannot reach it. No shared VS Code rendering code is modified; the adapter's own diff is a documentation comment plus the delegation to getToolKind.

[Copilot]

Copilot review overview

🟡 Changes recommended

Remote write labels and cross-platform paths remain incorrect, and newly editable inputs are silently ignored.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 3

New issues introduced by this change (3)

Severity	Finding
	src/​vs/​workbench/​contrib/​chat/​browser/​agentSessions/​agentHost/​stateToProgressAdapter.ts — The normalized write data does not update the invocation label. AgentSessionApprovalModel reads…
	src/​vs/​workbench/​contrib/​chat/​browser/​agentSessions/​agentHost/​stateToProgressAdapter.ts — This converts a remote filesystem path with URI.file inside getEditFileMessage, whose separator…
	src/​vs/​workbench/​contrib/​chat/​browser/​widget/​chatContentParts/​toolInvocationParts/​chatToolConfirmationSubPart.ts — This makes the JSON editor appear for plain-string Agent Host confirmations, but that editor is…

What changed in this PR

Improves Agent Host sandbox permission prompts so command and file approvals use specialized renderers.

Changes:

• Infers rendering metadata from remote permission requests.
• Normalizes write-permission messages and inputs.
• Adds regression tests for command, path, and write prompts.

File	Description
stateToProgressAdapter.test.ts	Tests remote permission rendering.
chatToolConfirmationSubPart.ts	Renders structured input alongside plain messages.
stateToProgressAdapter.ts	Adapts command and write permission metadata.
copilotToolDisplay.ts	Reuses shared edit-message formatting.
streamingToolCallDisplay.ts	Adds shared edit-message helper.
sessionReducers.ts	Infers tool kinds from permission metadata.
agentPermissionRequestMeta.ts	Parses remote permission metadata.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.