Error resuming chat after long background Shell finishes (Request ID 57b6008d-8c6b-4cce-86ac-59caf380ce4c)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Error resuming chat after a long background Shell finishes. Toast: “A background task finished, but the chat couldn’t resume. Try again in a moment.” The Shell/watch itself succeeds (exit 0); only parent-chat reattach fails. Started happening frequently once we use long CI watches (~15–20 min) with notify_on_output.

Steps to Reproduce

  1. In Agent chat, start a long background Shell (block_until_ms: 0) that runs 10–20+ minutes (e.g. gh pr checks --watch / CI babysit watch).
  2. Arm notify_on_output so Cursor wakes when the Shell prints a completion sentinel.
  3. Leave the chat idle while it runs.
  4. When the Shell finishes, Cursor shows “Error resuming chat” instead of continuing the agent turn.
  5. Clicking Resume or sending a new message works; work was not lost.

Expected Behavior

When the background Shell completes, the parent Agent chat should resume automatically on the wake notification and continue the turn (same as short background jobs).

Screenshots / Screen Recordings

image-eca97924-65b3-4743-b4a5-c8fc46aa7751.png
image-eca97924-65b3-4743-b4a5-c8fc46aa7751.png619×117 9.85 KB

Operating System

MacOS

Version Information

Cursor IDE 3.12.17 (arm64)

For AI issues: which model did you use?

Grok 4.5 (parent Agent session). Background work was Shell (CI watch), not a model subagent.

For AI issues: add Request ID with privacy disabled

57b6008d-8c6b-4cce-86ac-59caf380ce4c

Additional Information

Not a project/CI failure — GitHub checks and the watch complete correctly. Correlates with heavy use of long background Shell + notify wakes for merge-queue babysitting. Related to other “Failed to resume after background task completed” reports; our toast is the generic reattach failure (no “model name is not valid” message).

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hey there!
This is a known rough edge we’ve seen reported before. 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. Your work is saved - the turn just needs a nudge to pick back up.

To recover when you see it:

  1. Click Resume on the toast, or send any new message in the same chat - either one re-delivers the completion and continues the turn. If Resume doesn’t seem to respond on the first click, sending a message will reliably resume it.
  2. For very long idle stretches, a fresh chat per task tends to make the reattach more reliable.

I’ve flagged your report (with the request ID) to the team so it’s tracked alongside the other reports of this behavior. Since the work itself isn’t lost it shouldn’t block you, but if you ever see it actually drop the completed work, reply here - that’d be a different issue worth digging into.