The TypeScript Agent SDK exposes fields that allow hosts to correlate submitted user messages with the SDK turns/results that answer them:
- user_message_uuid
- user_message_uuids
- queued_turn_count
Relevant TypeScript releases:
- v0.3.216: added user_message_uuid to successful results.
- v0.3.243: added queued_turn_count to results.
- v0.3.246: added user_message_uuid to error results and first reply frames.
- v0.3.259: added user_message_uuids, containing every submitted message answered by a merged turn.
The Python SDK currently does not expose these fields in its message dataclasses or preserve them in _internal/message_parser.py, even though its bundled Claude CLI is at parity with CLI versions used by the TypeScript releases.
Requested parity:
- Expose user_message_uuid and user_message_uuids on the equivalent Python first-reply and result message types.
- Expose queued_turn_count on ResultMessage.
- Preserve these fields in message_parser.py.
- Ensure/document that structured Python user-message input can carry a caller-supplied uuid, matching the TypeScript SDK.
- Keep all new fields optional for compatibility with older CLI versions.
This is useful when several messages are submitted while a turn is running. Claude Code may merge those inputs into one turn and emit one ResultMessage; user_message_uuids allows the host to determine which inputs that result answered. queued_turn_count tells the host whether another queued turn/result is expected.
This request is only for parity with behavior already available in the TypeScript SDK.
would the maintainers accept a PR implementing the TypeScript parity described above?
The TypeScript Agent SDK exposes fields that allow hosts to correlate submitted user messages with the SDK turns/results that answer them:
Relevant TypeScript releases:
The Python SDK currently does not expose these fields in its message dataclasses or preserve them in _internal/message_parser.py, even though its bundled Claude CLI is at parity with CLI versions used by the TypeScript releases.
Requested parity:
This is useful when several messages are submitted while a turn is running. Claude Code may merge those inputs into one turn and emit one ResultMessage; user_message_uuids allows the host to determine which inputs that result answered. queued_turn_count tells the host whether another queued turn/result is expected.
This request is only for parity with behavior already available in the TypeScript SDK.
would the maintainers accept a PR implementing the TypeScript parity described above?