Repository navigation
[Bug]: Cursor thread never recovers after a restart during a run ("already has active run") #24498
Description
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 — packages/provider-cursor
Steps to reproduce
- Start a Cursor turn that runs for a while, e.g. ask it to run
sleep 90. - While it is running, stop and restart the T3 server process.
- The server comes back and resumes the parked turn on its own ("T3 Code restarted and resumed this turn").
- Every send to that thread now fails with "The provider could not start this turn", and retrying never helps.
Expected behavior
The resumed turn recovers: the abandoned run is cancelled and the turn continues. At worst it fails once and a retry works.
Actual behavior
Every attempt fails with:
CursorAgentSdkRunnerError: Cursor Agent SDK run.start failed.
[cause]: UnknownAgentError: Agent agent-… already has active run
T3 has recovery for exactly this (isActiveRunConflict in CursorAgentSdk.ts), but it reads one page of runs:
const latestRun = yield* Effect.tryPromise({
try: () => Agent.listRuns(agent.agentId, { ...runOptions, limit: 1 }),@cursor/sdk returns runs oldest first, so limit: 1 is the first turn of the conversation — finished — not the run still marked running. find(status === "running") returns undefined, the original error is rethrown, and nothing is cancelled. The provider log shows run.start with no run.cancel and no later events.
The SDK's local store blocks the agent: agents.status = RUNNING, agents.active_run_id = run-…, and that run row is still RUNNING. The SDK can expire that with local: { force: true }, but the resume path never sends it, and nothing else clears it. Retrying therefore cannot recover the thread.
Impact
Blocks work completely for the affected thread. Restarting T3 again does not help, because the stale run survives in the store.
Version or commit
main @ d53873b. Also present on v0.1.2 and v0.1.3-nightly.20261024.3617. @cursor/sdk 1.0.35.
Environment
Linux x64 and desktop app, Node 22, provider cursor (Auto and grok-4.7). Reproduced twice on the same host: once by accident during a release restart, once deliberately with the steps above.
Workaround
Cancel the orphan through the SDK, then send again:
require("@cursor/sdk").Agent.cancelRun("<run-id>", { runtime: "local", cwd: "<thread cwd>" })The partial output of the killed run is still in its checkpoint. Restarting T3 is not a workaround.
I am sending a small fix that references this issue. It pages the run list and cancels the abandoned run, which keeps the recovery's existing shape; local: { force: true } would be shorter, so say if you would rather have that one.
Activity
AnshShah3009 commentedon Nov 4, 2026
Additional occurrence on 2026-11-04 (Linux desktop, T3 Code
0.1.8-nightly.20261104.4179, Cursor provider / Grok 4.7). This appears related to the same stale-active-run condition, but the trigger here was a series of retries and subagent resumes; the logs do not show a T3 server restart for this incident.What happened
After a previous parent run was cancelled at 14:32:33.738Z, resume attempts for the parent and its Cursor subagents followed. The parent had two failed starts, then a later retry started:
Diagnosis from logs
The server trace records
CursorAdapterV2.startTurnfailures for ordinals 189 and 191. Both areProviderAdapterTurnStartErrorwrapping:At 14:32:45.045Z and 14:32:45.345Z, two subagent Cursor starts failed with the same
UnknownAgentError(on their own redacted agent IDs). This indicates multiple Cursor sessions had an active-run conflict during the resume burst; it was not limited to the parent thread.The parent retry later succeeded, so this incident was transient and differs from the permanent-after-restart case in the original report. The trace does not identify which earlier SDK runs still occupied each agent, why those active states persisted after cancellation, or whether the subagent retries caused the parent conflict. A Cursor provider status check at 14:33:02.912Z returned success; the failure itself came from the SDK rejecting
run.start, not an authentication error.Reproduction status and relation to this issue
This is a log-confirmed occurrence of the same
already has active runfailure, but without an observed T3 restart and with recovery succeeding on a later retry. It suggests the active-run recovery may also need to handle cancellation/resume races or bursts across parent and child threads. I could not reproduce it deterministically.Issue #24498 and open PR #24540 already cover recovery from Cursor's stale active-run state after a restart. Please confirm whether this additional trigger belongs in that fix or needs separate handling.
Environment
0.1.8-nightly.20261104.4179@cursor/sdkversions were not recorded in the relevant trace