Skip to content

Allow non-UUIDs as message ids#718

Open
SteffenDE wants to merge 1 commit intoagentclientprotocol:mainfrom
SteffenDE:sd-message-id-format
Open

Allow non-UUIDs as message ids#718
SteffenDE wants to merge 1 commit intoagentclientprotocol:mainfrom
SteffenDE:sd-message-id-format

Conversation

@SteffenDE
Copy link
Contributor

PR #244 introduced the messageId field and required both clients and agents to use the UUID format for IDs. It also states that the ID should be treated as an opaque value.

I propose to drop the requirement on UUIDs and instead focus on IDs being unique with the exact format not being imposed by ACP.

For example, OpenCode uses a different message ID format internally and I'm not sure if it would be worth the effort to add logic for using UUIDs just for ACP.

PR agentclientprotocol#244 introduced the `messageId` field and required both clients
and agents to use the UUID format for IDs. It also states that the
ID should be treated as an opaque value.

I propose to drop the requirement on UUIDs and instead focus on IDs
being unique with the exact format not being imposed by ACP.

For example, OpenCode uses a different message ID format internally
and I'm not sure if it would be worth the effort to add logic for
using UUIDs just for ACP.
@SteffenDE SteffenDE requested a review from a team as a code owner March 10, 2026 15:59
@benbrandt
Copy link
Member

I kind of had this concern before. But now I also have a concern: the RFD as it stands allows for BOTH sides to generate ids.

If it was only one side, I don't think we'd need to standardize. This was also my argument for potentially starting with just agent-generated ids.

I wonder if the agent should perhaps emit a notification for a user message once it receives it to work around this issue?

@SteffenDE
Copy link
Contributor Author

That would work for me.

Another problem I encountered when looking into message ids for Claude is that the Claude Agent SDK does not emit the ID for the agent message until it is fully generated. So if we'd want to support partial message streaming and message IDs in claude-agent-acp, we'd need to have a way for ACP to generate a temporary message ID for agent chunks and then send an update with the "final" ID later. (Assuming we cannot get Anthropic to change the SDK to provide stable IDs for stream events. Probably very unlikely)

@benbrandt
Copy link
Member

Yeah ok this was kind of my concern from the beginning... message ids are very useful. Probably any agent who natively supports ACP will be able to do this, but Claude Code is always the most popular but we're limited because it is an adapter...

@SteffenDE
Copy link
Contributor Author

fwiw we don't even need a notification. The RFD already says that the agent must provide the userMessageId on the response when it generated the ID, so we could just not include user provided IDs for now.

Copy link
Contributor

@yordis yordis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this change, enforcing a UUID format other than string is already limiting the system design without knowing the situation.

I would change the language to SHOULD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants