Cursor SDK: steer a live run, and background subagents report back

At 16:08 UTC on 5 October 2026, Cursor posted that SDK agents can be steered while they run. The post says run.steer() “adds your message to the next turn,” and that if a subagent is mid-task “it moves to the background and keeps working.” A reply five seconds later says background subagents “now report back.” Their results “return to the parent as a follow-up turn on the same run, so stream() and wait() carry through until every subagent finishes.”

The SDK changelog writes that behavior under the heading 1.0.31, with two further items in the same entry. On 6 October 2026 that heading was the newest one on the page. The npm page for @cursor/sdk showed version 1.0.36, and the registry latest dist-tag matched it, with that version’s publish time at 2026-10-05T16:38:15.517Z. The changelog page stops at 1.0.31. It does not say whether 1.0.36 still matches that heading.

run.steer()

The changelog says run.steer(text) injects a message into the turn already in flight. The promise resolves complete_delivered, or revert_to_followup when the text should be sent as a normal follow-up. The X post says the call adds the message to the next turn. revert_to_followup is the changelog’s name for the case where the in-flight turn did not take it.

The changelog limits a delivered steer to TypeScript local runs. Cloud runs resolve revert_to_followup. The TypeScript SDK docs add that cloud runs and detached local handles expose steer and still always resolve revert_to_followup. Steering during a foreground subagent is supported there: that subagent moves to the background and keeps going so the parent turn can take the message. The docs also say steer is optional on Run and is not a RunOperation, so callers check run.steer before using it.

The Python SDK docs do not document run.steer().

Background subagents

The changelog says a background subagent’s result “returns to the parent as a follow-up turn on the same run instead of being dropped when the parent turn ends.” run.stream() keeps yielding through those turns, and run.wait() resolves after them. The scope line is local agents, in TypeScript and Python.

The X post says stream() and wait() carry through “until every subagent finishes.” The changelog describes follow-up turns on that run.

The TypeScript docs use run.stream() and run.wait(), and they say wait() resolves with the last turn’s text as result. They limit this to local agents. The Python docs describe the same follow-up for local agents, and they name run.messages() and run.wait().

Two other items under 1.0.31

systemPrompt on Agent.create() replaces Cursor’s built-in system prompt for the main agent loop. Rules, skills, and tool schemas still load, and subagents keep their own prompts. The changelog says this is TypeScript local agents only, that the value is passed again on Agent.resume(), and that access is enabled per account. The TypeScript docs say a cloud agent rejects systemPrompt with a configuration error, that a blank string is rejected, and that without per-account access the first send() fails with an error naming --system-prompt.

annotations on a local.customTools entry pass MCP tool annotations through to the model: title, readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The changelog calls them descriptive hints. The SDK does not enforce them. The entry says TypeScript only.

What to do with it

On a local TypeScript run, run.steer() can place text in the turn that is already going. Read the outcome before sending the same text again: complete_delivered means the turn has it, and revert_to_followup means it should go out with agent.send() after the run. Cloud runs, and detached local handles, resolve revert_to_followup. For background subagents on a local agent, keep the same run open through the follow-up turns: stream() or wait() in TypeScript, messages() or wait() in Python. The posts and the 1.0.31 entry give no timing or quality figure.