# acp: Handle acp message ids when we get them \(\#59927\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/70fd3c577468f109d123defaeef436081ff0727c)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 70fd3c577468f109d123defaeef436081ff0727c

Requested commit: 70fd3c577468f109d123defaeef436081ff0727c

Commit: 70fd3c577468f109d123defaeef436081ff0727c

Tree: 8309776c85ec125bb37b070bbe4501fe23ca52a0

Author: Ben Brandt

Committer: GitHub

## Message

```
acp: Handle acp message ids when we get them (#59927)

This separates the two user-message identities we currently need in
agent threads:

- `protocol_id`: the ACP `messageId` used to group or split streamed
message chunks from ACP agents.
- `client_id`: the Zed-generated user message ID used by the native
agent for truncate, rewind, edit/regenerate, checkpoints, token usage,
and persistence.

The main behavior change is that ACP protocol message IDs now affect
message merging/rendering without leaking Zed-native client IDs into ACP
agents by default. Agents that can accept Zed-generated user message IDs
opt into that path through `AgentSessionClientUserMessageIds`, which
owns both ID generation and prompt submission. The native Zed agent
implements that capability; normal ACP agents continue through the
protocol-only `prompt` path.

In ACP v2 we'll have a mechanism for getting user message replays that
will allow the agent to adequately generate it's own opaque id that we
can then use for these other capabilities. But for now, this split at
least makes sure we keep the two concepts distinct.

Release Notes:

- N/A

---------

Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
```

## Parents

- [f2006b20aceff6ad660b6436bd48413388318e34](https://git.cafe/gitcafe/zed/commit/f2006b20aceff6ad660b6436bd48413388318e34?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/70fd3c577468f109d123defaeef436081ff0727c?format=markdown)