GET /v0/agents/{id}/conversation returns different message IDs for identical messages across repeated reads

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

When I call GET /v0/agents/{id}/conversation multiple times for the same agent, the returned messages are textually identical (same type and text) but messages[ ].id changes on each fetch. This makes message IDs unstable for deduplication and incremental sync.

Steps to Reproduce

  1. Create or use an existing agent with at least one user/assistant message.
  2. Run:
   curl -sS 
   -u “${CURSOR_API_KEY}:” 
   -H “Content-Type: application/json” 
   “https://api.cursor.com/v0/agents/<agent-id>/conversation” | jq
  1. Run the exact same command again immediately.
  2. Compare the two responses:
    • messages[ ].type and messages[ ].text are identical
    • messages[ ].id is different between the two calls

Expected Behavior

For the same persisted conversation, each message should keep a stable ID across repeated GET requests. If IDs are intentionally ephemeral, the API docs should explicitly state that and provide a stable field for message identity/deduplication.

Operating System

Linux

Version Information

CLI Version 2026.03.20-44cb435

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the report, this is a really well-described bug.

Confirmed, it’s a bug on our side. Message IDs are getting regenerated on every request instead of returning stable values from storage. I’ve passed this to the team.

As a workaround for deduping, you can use the message position in the array + type + a hash of text. The message order is stable between calls.

7

Thanks for the quick confirmation and for sharing the workaround.

Understood that message IDs are currently regenerated per request.
For now, I’ll use (message index + type + text hash) for deduplication.

Appreciate the fast triage and escalation to the team.