After my Mac was in idle sleep for a few hours and then woken, an open Agent chat showed the generic banner “An unexpected error occurred. Request ID: 899e7a6c-6316-492c-af9b-220c0a77c5d7”. After the error the conversation had silently rolled back to an earlier state: a whole stretch of completed work (several assistant messages + tool calls) was gone from the in-context conversation — even though that work had actually completed and was persisted on disk.
I cross-checked the live in-context conversation against Cursor’s own persisted bubble store (state.vscdb) and the working tree:
Ground truth (work that really happened + persisted): the session had completed a full implementation phase — ~5 source files modified, 2 new source modules, a new test file + 4 fixtures, and a passing test run. All present on disk and in Cursor’s persisted bubble store, with the tool-call bubbles marked completed.
Live context after the error (decoded conversationState protobuf: 47 turns, 0 summary blobs): the newest in-context work was an earlier phase; none of the implementation phase was present. The context window had been reverted from “implementation complete” back to the earlier phase.
Re-serialization fingerprint: the earlier phase’s tool-call bubbles are re-persisted under ~14 distinct createdAt clusters; within each cluster several multi-second shell commands share a sub-5 ms timestamp — i.e. batch re-writes of the bubble store, not real re-executions. The final re-write landed during the sleep window. The conversation store was repeatedly re-serialized and the live context ended up pointing at a stale snapshot.
Possibly related: a report on the same version (3.9.16), same day shows this exact banner with stack RetriableError: [internal] Blob not found in runAgentLoop / streamFromAgentBackend (forum topic 164453). “Blob not found” is consistent with the conversation referencing content blobs/turns that no longer resolve.
Impact
Lost work/visibility: completed assistant messages and tool-call results vanished from the conversation the model can see.
Unsafe replay risk: because the in-context state says the work isn’t done, continuing/retrying the session would re-run already-completed tool calls (re-create files, re-run commands). I avoided this only by not letting it retry the prompt — a user who clicks Try again would get duplicate / potentially destructive re-execution.
Opaque error: the only signal is a generic “unexpected error” + Request ID; nothing indicates the conversation silently rolled back.
Speculative root cause: on resume after idle sleep, the client reconciles the session to a stale conversationState snapshot (referencing turns/blobs that predate the latest persisted state, or that can’t be fetched → “Blob not found”) instead of loading the latest persisted bubble state, then surfaces the generic error and continues from the stale point.
Steps to Reproduce
Open an Agent chat and run several turns that include tool calls / file edits, so there is substantial completed work.
Leave the chat open and let the machine go into idle sleep for a few hours.
Wake the machine and return to the chat.
Observe the banner “An unexpected error occurred. Request ID: …”.
Notice the last completed message(s)/tool-call results are missing and the agent’s understanding has reverted to an earlier point in the session.
(Do not click Try again on real work — continuing replays already-completed actions.)
Expected Behavior
On resume, reconnect to the latest persisted conversation state; never silently roll back to an older snapshot.
No lost messages or tool-call results.
Never auto-replay already-completed tool calls; if state can’t be loaded, fail loudly and recover to the latest persisted state rather than an older one.
Transient / “Blob not found” errors should be retried against the current state, not by rolling the conversation backward.
Exactly as you found, everything was persisted to disk and to Cursor’s local chat store. The rollback only affected what the current chat had loaded back into context after the wake, not the actual files or the work itself.
The error banner came from the in-flight request being cut off when your Mac went to sleep mid-turn. The important part for getting unblocked: start a new chat to continue, rather than clicking Try again on the affected one. You’re right that retrying that chat risks re-running tool calls that already completed, so a fresh chat is the safe way forward. You can paste a quick recap of where things stood.
On the bigger issue - the conversation reconciling to an earlier state after the stream drops, and the replay risk if you retry - this is an area we’re already looking into, and the detail you included (especially your comparison of the on-disk state versus what the chat had in context) is really useful. I’ve passed your report to the team and will update here as I hear more.
If you’re up for it and still have the session’s logs: could you grab Cmd+Shift+P → Developer: Open Logs Folder from around when this happened and share the Window + Extension Host logs? That’ll help us pin down exactly where the context got reverted. No need to click Try again on that chat - please don’t, given the replay risk you flagged.
Thanks @mohitjain — and noted, I have not clicked “Try again” on that chat.
Good news on the logs: the Cursor process has been running continuously since before the incident, so the logs are intact. I dug into the Window logs and found the full trace for that Request ID. The renderer log has since rotated, but cursor.requestTraces.log still has the complete span timeline, and it lines up exactly with your “in-flight request cut off when the Mac slept mid-turn” reading (plus a blob-resolution angle).
Distilled timeline for requestId=899e7a6c-6316-492c-af9b-220c0a77c5d7 (times UTC; my machine is UTC+3):
12:15:00.582Z — abortChatAndWaitForFinish (the prior in-flight turn gets aborted on submit).
13:21:50Z — rpc.run … error=true durationMs=4010255 (~66 min hung, then errored).
13:37:47Z, 13:43:41Z, 13:48:05Z, 14:03:41Z, 14:26:11Z, 14:56:24Z, 15:06:28Z, 15:26:34Z — more rpc.run … error=true spans, durations from ~4 min up to ~22 min (streaming RPCs repeatedly failing across the sleep window).
14:39:21Z and 15:10:19Z — bursts of ComposerBlobStore.getBlob.slow (slow blob resolution — consistent with the “Blob not found” family in the related report).
16:41:32.256Z — the whole agent.request / submitChatMaybeAbortCurrent span completes after ~4h26m (durationMs=15991761).
23:26:04Z — StreamExecutorResource.execute spans finally tear down, with durations up to ~10.7h (durationMs=38399813).
So the turn’s request stayed open for ~4.5h while the machine was asleep, the streaming RPCs errored out repeatedly, blob fetches went slow, and the stream executors weren’t reaped until ~11h after submit. That matches the context reverting to the last cleanly-loaded snapshot once the stream dropped.
I can share the raw logs too — the relevant ones are the Window log’s cursor.requestTraces.log (~57k lines) and the Extension Host logs for that window. They’re large and contain workspace content, so I’d rather not paste them publicly. Happy to send them via DM or a support channel — just point me where. Let me know if the timeline above is enough to start, or if you want the full files.
Thanks for digging into the Window logs, and for leaving Try again alone on that chat.
The distilled timeline is enough for us to keep going. It matches the picture we had on that request: the turn stayed open for hours across sleep, streaming RPCs failed repeatedly in that window, and teardown only finished much later. Noted on the getBlob.slow bursts as an extra data point.
If you still want to send the full files (cursor.requestTraces.log from Window + Extension Host for that window), email them to [email protected] with a link to this thread in the body. Please don’t paste them here, since they include workspace content. We’ll attach them internally.
No need to change anything on your end beyond starting a fresh chat if you haven’t already.