ACP session/request_permission

[blackshot]

I've been trying to implement my own web interface that communicates with dsh, and so far I'm doing well. However, when I receive a payload requesting tool execution permission, the payload doesn't contain any useful information to display in the graphical interface. It's not helpful for a human.

Am I doing something wrong? Or does dsh need to send a more informative payload?

[denial123789]

You are not decoding the payload incorrectly. In rc.8 this is the deliberate dsh-acp boundary: the bridge constructs toolCall with only toolCallId, plus allow_once / reject_once. Its package contract describes ACP as automation-only and explicitly keeps tool presentation and interactive rendering out of this wire surface.

So an ACP-only client has two honest choices:

1. Apply a policy configured for that Session/job before the request.
2. Show a generic, fail-closed prompt: “DSH requests one-time permission for tool call …; tool details are unavailable on this connection.” Preserve the exact Allow once wording and default to reject.

Do not infer a command, path, tool name, or risk level from the call id. For a rich Web card, the host needs an additional authoritative DSH-native tool-event registry and must join metadata by Session id + exact call id; if that join is missing or stale, fall back to the generic prompt or reject.

I wrote up the payload ledger, TypeScript policy handler, rich-host join, redaction/replay controls, and cancellation/reconnect race tests here:
https://sandbaseai.github.io/deepseek-harness-handbook/acp-permission-request-ui.html

The relevant source seam is packages/acp/acp/src/index.ts around lines 212–228.