Error messages

A background task finished, but the chat couldn't resume. Try again in a moment.

A background task finished, but the chat couldn't resume. Try again in a moment.

Cursor's agent can start work that keeps running after its turn ends: a long shell command in the background, or subagents in Multitask mode. When that work finishes, the chat is supposed to wake up and carry on. Sometimes it shows this card instead:

Error resuming chat
A background task finished, but the chat couldn't resume. Try again in a moment.

The card has two buttons, Copy ID and Resume. In the forum threads we read, reports go from version 3.12.17 in July 2026 to 3.17.21 in late August, and as of September 25, 2026 Cursor hasn't given a date for a fix. Nobody has reported it on a newer build yet, but that's thin evidence it's gone (Cursor has shipped several releases since and hasn't said it's fixed).

What went wrong

The task itself usually went fine. It's the wake-up that broke, which a Cursor staffer described on July 22 as "a known rough edge": when a background task finishes "after the chat has been sitting idle for a while, the automatic 'wake' that should resume your turn can hit a transient hiccup, and right now that surfaces as the 'Error resuming chat' toast instead of quietly retrying." Another staff reply in August ruled out "a usage or rate limit failure", so switching models or plans won't help.

Getting the chat going again

• Click Resume. If nothing happens on the first click, send any message in the same chat, which staff say "will reliably resume it."
• The card can come back several times if subagents finish back to back. Each Resume picks up everything that has built up so far.
• For tasks that leave the chat idle for a long time, staff suggest a fresh chat per task, which "tends to make the reattach more reliable."

Is the work lost?

Subagent results survive, which is what most of us would worry about first. Staff said on August 26 that results from a finished background Task "are saved" and that Resume delivers them into the chat.

Local shell commands fare worse, which we didn't expect. A user on Cursor 3.14.27 ran a careful test in August (timings for every run, request IDs where there were any): fresh chats, each starting a background sleep command, left idle. All four chats failed to resume. In three of them the command itself was killed roughly 80 to 100 seconds after the agent's turn ended, long before it'd have finished. In the fourth the command completed and the UI said "Finished", but the agent never woke and no card appeared at all.

Cursor staff confirmed both the silent version and the killed processes, which is why we wouldn't trust a local job to finish on its own. "Work is saved" only holds for work outside the shell (CI running on GitHub, say, or output already written to a file), because "a local background process may not survive once the owning turn ends." The workaround they endorsed is to run anything that has to outlive the turn as a fully detached process that writes to a log file, then read the log on your next message.

When it comes with "Agent Execution Timed Out"

If Copy ID gives you ConnectError: [deadline_exceeded] Agent Execution Timed Out, there's likely a second problem stacked on top. Cursor staff said in August 2026 that this error "means the local Cursor component that runs agent requests (the extension host) stopped responding on your machine." The extension host is a separate background process, inherited from VS Code, that Cursor also uses to run agent requests. For that one, quit Cursor fully and reopen it (Reload Window alone won't do it). If it won't stay away, staff pointed at antivirus real-time scanning and suggested adding Cursor's install folder and %USERPROFILE%\.cursor to its exclusions. When you report it, staff ask for your Cursor version and whether you're working locally or over Remote-SSH or WSL.