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

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

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.

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.