[Bug]: Cursor run continues after T3 marks parent and native subagents failed #15447

Activity

1. juliusmarminge commented on Oct 4, 2026

   

   juliusmarminge

   on Oct 4, 2026 – with Cursor

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the careful timeline and bundle notes, @j0nsh1n. This is a real lifecycle bug, and it's still present on current main (737993303d). No commit since your nightly changes this path.

   What I found

   The stored terminal matches the ingestion-failure write in RunExecutionService, not a Cursor adapter terminal. The catchCause around the provider-event consumer logs orchestration V2 provider event ingestion failed with the real cause, then calls writeFinalRunEvents. makeProviderFailure only keeps a specific message for a handful of error tags, so anything else (a schema error, for example) becomes the generic Provider turn failed. with class unknown, and the thread never shows the actual exception.

   writeFinalRunEvents then runs cascadeTerminalizeRunOwnedSubagents, which marks every still-open run-owned subagent, node and turn item failed in the same write. That explains the parent and four unfinished subagents failing together, while the one that had just completed was already settled.

   The Cursor run keeps going because that path never cancels it:

   • Cursor sessions don't implement subscribeEvents, so closing eventSubscription does nothing.
   • interruptTurn is what calls run.cancel, and the failure path doesn't call it. activeTurn stays set until the SDK run actually finishes.
   • The continued protocol frames mean the SDK callback is still succeeding; those events just queue up with nobody reading them.

   This also likely explains the failed retry. The synthetic terminal makes the thread look reusable, but the next send hits CursorAdapterV2.startTurn's guard (Cursor provider turn … is still active) before anything cancels the old run. Stop isn't offered either, because the run is already marked failed. For now, quitting the desktop app closes the Cursor session, which is the practical way to drop the leftover turn.

   #15316 is the same ingestion-failure finalization gap with a Claude AskUserQuestion trigger. #12374, #13284 and #9047 are different paths.

   Likely fix area

   RunExecutionService's ingestion-failure path. Some options:

   • Interrupt or cancel the provider turn when ingestion fails before the turn ends (for Cursor, run.cancel).
   • Keep the original cause somewhere that survives log rotation, or surface it on the failed terminal, so the triggering event can be identified. Cancelling alone won't tell us which event threw.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 4, 2026
3. topitopongsala commented on Oct 16, 2026

   

   topitopongsala

   on Oct 16, 2026

   More actions

   Another datapoint on 0.0.46-nightly.20261011.2994 (Linux x86_64, Cursor provider, grok-4.7). Here T3 marked the run cancelled, not failed, and the next turn could not start. This is the case the issue leaves open: "A later retry also failed to start".

   Timeline from the Cursor provider protocol log and the run projections (UTC, 2026-10-15):

   13:45:18.231  outgoing run.start   (app run 18)
   13:45:18.297  incoming run.started run-822cd5b7-...
   14:02:42.428  app run 18 -> cancelled          (no outgoing run.cancel is logged)
   14:02:49.937  outgoing agent.open operation=resume   (same agentId)
   14:02:51.553  outgoing run.start   (app run 21: a delegated-task completion notice)
   14:02:51.567  app run 21 -> failed "The provider could not start this turn"  (no run.started)
   14:15:35 ... 15:51:47  incoming interaction.update for run-822cd5b7 (tool calls continue)
   15:52:48.466  incoming run.completed run-822cd5b7-...
   

   So the native run worked for another 110 minutes after T3 cancelled the app run. It ran shell commands, and it wrote state outside T3. None of that output was shown. The provider log contains no run.cancel event for this agent. In CursorAdapterV2.interruptTurn, if (context === null && turnInput.requestRuntimeRestart === true) return; returns with no cancel. This may be the path that ran, but I cannot prove it from the retained logs.

   The failed run 21 then left the thread stuck through the missed-run handoff budget (#19875). Every later turn failed with "Insufficient context allowance", so this bug has a larger effect on Cursor threads than one lost turn.

   Expected: T3 sends run.cancel for the native run, or does not mark the app run terminal while the native run is live. A new run.start should not be sent to an agent whose previous run is still running, or it should go through the existing listRuns / cancelRun recovery in startRun.