Stop hook reports the wrong generation_id when a follow-up prompt aborts an in-progress agent turn

Support Bug Reports
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

When a user submits a new prompt while a previous agent turn is still generating, Cursor correctly aborts the previous turn — but the stop hook event carrying status: “aborted” is tagged with the new prompt’s generation_id, not the one that was actually aborted. A hook consumer has no way to determine which turn was cut off from the stop payload alone.

Steps to Reproduce

  1. Submit Prompt A in Agent mode; wait until it visibly starts working (e.g. one afterAgentThought has fired for A’s generation_id).
  2. While A is still running, submit Prompt B.
  3. Inspect the stop hook payloads.

Expected Behavior

A stop event for A’s own generation_id with status: “aborted”, then B proceeds under its own id.

Operating System

Windows 10/11

Version Information

Cursor 3.12.30

Additional Information

This issue occurs only when a follow-up message is sent before the initial response has finished generating. The stop hook incorrectly uses the generation ID of the latest follow-up prompt instead of the aborted generation.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. The steps, expected vs actual, and the version make this a lot easier.

I reproduced it. When you send a follow-up prompt during an active turn, the stop event with status: "aborted" is tagged with the generation_id of the new prompt, not the interrupted turn. That’s a bug on our side. I’ve reported it internally to the hooks team. I can’t share a fix timeline yet. Once I have an update, I’ll reply in the thread.

One more context note. In the same scenario, other fields in the aborted stop event payload can also be wrong, like token usage and model. Same root cause. If your hook pipeline depends on those fields, please keep that in mind.