[Bug]: Cursor (Beta): steered message silently lost when the replacement run stalls — no output, no timeout, no error, not re-queued #21040

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Honest caveat up front: the underlying stall is intermittent and I could not force it on demand. The sequence below is a real incident recorded in T3's own protocol/orchestration logs, and the loss mechanism (unbounded wait + steer-as-cancel/restart, no re-queue) is deterministic in packages/provider-cursor/src/server/CursorAgentSdk.ts on main.

Reproduction sequence (Cursor provider, cursor-agent-sdk.local, cursor-agent CLI, model glm-5p3-flash):

1. Start a thread and send a message. The first three runs complete normally in 6–100s (23:04–23:08 UTC).
2. While a run is active, steer (send another message). Orchestrator v2 implements steering as interrupt-current-run + start-new-run.
3. The replacement run starts (run.started reaches T3) but then emits zero downstream events — no deltas, no completion — indefinitely.

Observed timeline from ~/.t3/userdata/logs/provider/events.<thread>.log and the orchestration_events table in statev2.sqlite (thread 24e06057…):

Each steer consumed the pending message via cancel+restart; each replacement run stalled. Control test the next day: fresh and --resume runs on the same model/binary/CLI answered in 3.5–6.7s, so this is a transient backend/driver stall that T3 masks rather than surfaces.

Expected behavior

A steered message is either delivered by a run or explicitly accounted for: if the run it was queued onto is interrupted or stalls, the message is marked undelivered and re-queued (or surfaced as "steer not delivered"), and a stalled run becomes visible (stalled/error state with a retry path) instead of an indefinite spinner.

Actual behavior

The steered message is silently lost. Its run sits in run.wait() forever (no timeout, deadline, or no-event watchdog anywhere in CursorAgentSdk.ts on main — only exit is the orchestrator's run.cancel + run.start). When the user gives up and presses Stop, the run ends interrupted, the thread goes idle, and the last steered message (59329318) has no answer, no terminal delivery state, no error, and is never re-queued. From the user's perspective the message simply vanished.

Suggested direction (one problem: don't consume a steer until a run delivers it):

• When a run ends via interrupt/steer without emitting a terminal result, mark the steered message undelivered and re-queue it — matching the recovery semantics already accepted in fix(server): restarts keep queued steering and stop duplicate launches #17589 — or at minimum surface "steer not delivered".
• Add a bounded no-event watchdog on provider runs (no interaction.update for N minutes → stalled state + retry) instead of the unbounded run.wait().

Impact

Minor bug or occasional failure

Version or commit

main @ c0c495e (driver file packages/provider-cursor/src/server/CursorAgentSdk.ts re-verified unchanged on latest main at filing time); desktop: T3 Code (Beta) 0.1.0

Environment

macOS (darwin 27.0.0), T3 Code (Beta) 0.1.0, provider: Cursor via cursor-agent CLI (cursor-agent-sdk.local), model glm-5p3-flash

Logs or work traces

# Protocol log (thread 24e06057…), post-first-steer runs:
23:08:29  steer msg 4c0d3eb9  → cancel run-1 + start run-e802e767
23:08:4x  run-e802e767 streams 4 assistant messages, then NO events for 56s
23:10:05  cancel → steer msg 6fab65f7 → run-46201dcc: run.started, ZERO events for 479s
23:18:11  cancel → steer msg 59329318 → run-beed715b: run.started, ZERO events for 128s
23:20:19  user presses Stop → status "interrupted", thread idle
          msg 59329318: no answer, no terminal delivery state, not re-queued, no error

# Control (next day, same binary/model/CLI): fresh run 6.7s, resumed run 3.5s

Related: #14585 (earlier steering-reliability fix; its closure invites a new report if problems persist — this is that report), #19689 (same bug class on Antigravity ACP), #17589 (crash-recovery steer loss; open PR records undelivered steer ids).

Workaround

None reliable. Once the stall starts, Stop + manually re-sending the message works when the pipeline is healthy again; the lost steer has to be retyped from memory since nothing marks it undelivered.