subagentStart/subagentStop report 4 different id fields with the same session_id value, making it difficult to identify which prompt spawned a subagent

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

In subagentStart and subagentStop, four identifier fields, conversation_id, generation_id, session_id, and parent_conversation_id, all carry the same value, the session id. generation_id is documented as changing with every user message, but here it does not reflect the generation_id of the prompt that actually triggered the subagent. As a result, there is no field in either hook that identifies which specific user prompt caused a given subagent to spawn.

Steps to Reproduce

  1. In Agent mode, send a prompt that triggers a subagent
  2. Capture the full subagentStart and subagentStop payloads.
  3. Compare generation_id, conversation_id, session_id, and parent_conversation_id against the generation_id that beforeSubmitPrompt and stop reported for the actual triggering prompt.
  4. Observe all four fields are identical and match the session id, not the prompt’s own generation_id.

Expected Behavior

generation_id in subagentStart and subagentStop should match the generation_id of the specific parent turn that spawned the subagent, distinct from session_id and conversation_id, so a subagent invocation can be attributed to the exact prompt that caused it.

Operating System

Windows 10/11

Version Information

Cursor 3.12.30

Additional Information

Example for illustration: the triggering prompt had generation_id PROMPT_GEN_ID_1 under session SESSION_ID_1. Both subagentStart and subagentStop for that same subagent reported conversation_id, generation_id, session_id, and parent_conversation_id all as SESSION_ID_1, never PROMPT_GEN_ID_1. Also noticed subagentStop reported tool_call_count 0 and message_count 0 despite multiple real tool calls, possibly a related accuracy issue.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. It’s really clearly laid out.

The main symptom, where all four fields conversation_id, generation_id, session_id, and parent_conversation_id collapse into the session id, so the subagent can’t be linked to a specific prompt, is already a known bug on our side. It overlaps with this thread subagentStart hook: parent_conversation_id always equals conversation_id, and subagent conversations have no link back to their parent. According to the docs, generation_id should change on every turn, so this behavior is definitely wrong. We’re tracking the issue, but I can’t share a fix timeline yet.

Separately, your note about tool_call_count: 0 and message_count: 0 in subagentStop even when there were real tool calls is valid. I’ve logged it as a separate accuracy issue. If I get an update on either point, I’ll post it here.