copilot --acp responses return incorrect tool IDs when requesting permissions

[richardpark-msft]

Describe the bug

Copilot, in --acp mode, sends "tool permission requests", to the client, with a tool call ID set to something more akin to a title (ie: shell-permission) instead of something like the ID (ex: 'call_GN0nGMSBTdQOrviuem2vgxtg').

This doesn't happen with other tool call updates or even the initial tool call, only when requesting permissions.

Affected version

0.0.382 Commit: 18bf0ae

Steps to reproduce the behavior

1. Run copilot --acp
2. Connect, and send a request that will cause a shell execution to occur.
3. Observe that the ToolCall updates all pass a properly formatted ToolCallId but the "request permission" request uses a non-unique friendly ID (ie: 'shell-permission')

Expected behavior

The same tool call ID used to report the initial 'Pending' ToolCall should be used in all subsequent messages pertaining to that tool call.

Additional context

No response

[carlos-algms]

I can confirm. I'm the Author of https://github.com/carlos-algms/agentic.nvim

And while writing an Adapter to support copilot-cli ACP, I noticed it doesn't send the right toolCallId when asking for permissions.

Specifically for the edit, instead of sending the tool-call id, it always sends a static value write-permission, making it difficult to tie it to which tool call it's asking for permissions.

And it's a Copilot only behaviour. All other CLIs, like Claude, Gemini, OpenCode, etc...
They all send the id of the tool call they are asking permission for.