Cloud Agents API / SDK: mid-run steer (parity with cursor.com/agents UI)

Ideas Feature Requests
,
1

Feature request for product/service

Cursor SDK

Describe the request

Please expose mid-run steering for Cloud Agents over the SDK and REST API — the same behavior the product UI already has on Cursor - The best way to code with AI | Cursor - The best way to code with AI send additional input while a run is active without cancelling the run, with delivery at the next tool call.

What works in the SDK today (local only)
The TypeScript SDK already has the right API shape:

Docs: Steering a run in flight — run.steer(text) with outcomes complete_delivered | revert_to_followup but always resolve revert_to_followup.

So for cloud, steer is effectively a no-op that tells you to wait and agent.send() afterward — i.e. a new run, not mid-run inject.

Recent changelog: Cloud Agents and Cursor Harness Improvements · Cursor

Why this matters

We’re building automation that orchestrates long-lived cloud agents (bc-…). Human / system feedback often arrives while the agent is still working (Slack, PR comments, CI signals, operator notes). Today we must either:

  • Wait until the turn finishes (steering arrives late; wasted work if the agent went the wrong way), or
  • Cancel and start a new run (loses in-flight progress the UI steering path is designed to preserve).

Is cloud mid-run steering on the roadmap for the public Cloud Agents API / @cursor/sdk? Even a rough ETA or “not planned” would help us make a decision. Thanks for your time!

4

The CI-signal case makes this concrete. When a failing check arrives mid-run, do you currently cancel, or let that run finish before sending the correction? I’m curious how you handle the race where the run finishes just as the feedback arrives.

5

Currently, we let every run finish and send the correction later. This is because killing the turn had unintended side-effects from non-idempotent operations on our tools. We tried:

  • Kill turn and issue new input (unintended side effects can happen due to non-idempotent operations; we can’t control what the model does exactly and in what order)
  • Queue next input behind turn1 (this is what we currently do; subpar user experience; wasted time and tokens; our top user complaint)

Considering it’s available in other channels, we really hope you enable this in SDK soon :slight_smile: :crossed_fingers:

6

Hey @Kannan_Mavila!

Steering has been a big hit. :slight_smile: I’ve passed your feedback onto the team working on the SDK!

9

Thanks @Colin . Appreciate the good work. Eagerly waiting for this to drop in SDK :slight_smile:

10

That explains the trade-off, Kannan. Cancelling risks repeating side effects, but waiting means the correction arrives after the work it was meant to change. Glad Colin has passed this on—the non-idempotent case makes the need for steering much more concrete.