Agent chat loses context when conversationState snapshot is skipped for unloaded user message bubble

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent chat can lose context mid-session. After an agent response completes, the next user message in the same visible chat can be handled like a fresh session, or like the agent never saw the immediately preceding work.

The visible UI still shows the prior messages directly above the input. The failure signature I found in renderer logs is:
[AgentResponseAdapter] Skipping conversationState snapshot for unloaded user message bubble

I found this warning across multiple normal agent chats and composer IDs.

Steps to Reproduce

  1. Use Cursor IDE Agent chat for a long-running session with many turns, enough that older message bubbles can be unloaded or virtualized.
  2. Let the agent finish a response.
  3. Send another message in the same visible chat/composer.
  4. In affected sessions, the agent behaves as if previous visible turns are missing.
  5. Check renderer.log for warnings like:
    [AgentResponseAdapter] Skipping conversationState snapshot for unloaded user message bubble {“composerId”:“…”,“messageId”:“…”}

Expected Behavior

If the chat UI still shows previous messages in the same composer, the next agent turn should include the corresponding conversation state/checkpoint, or Cursor should recover it from persisted message storage.

A visible chat should not silently continue from an empty or stale conversationState.

Operating System

Windows 10/11

Version Information

Cursor: 3.5.17 stable
VS Code base: 1.105.1
OS: Windows 10 Pro, build 26200, 64-bit
Install path: C:\Program Files\cursor

For AI issues: which model did you use?

Not model-specific. Observed in Cursor Agent chat/composer after long sessions.

For AI issues: add Request ID with privacy disabled

N/A. This appears to be a local conversation-state persistence/resume issue. Evidence is from renderer logs and local persisted composer/message storage.

Additional Information

Examples from renderer.log:

2026-05-24 22:26:20.190 [warning] [AgentResponseAdapter] Skipping conversationState snapshot for unloaded user message bubble {“composerId”:“d0d59b3e-9708-4095-93f2-6ccb13c1e776”,“messageId”:“26aea8f4-9eb6-43e5-94da-52281597b92c”}
2026-05-24 22:35:07.982 [warning] [AgentResponseAdapter] Skipping conversationState snapshot for unloaded user message bubble {“composerId”:“d0d59b3e-9708-4095-93f2-6ccb13c1e776”,“messageId”:“6c618ce8-c04b-4c8b-b6d9-983df9840844”}
2026-05-25 00:25:53.683 [warning] [AgentResponseAdapter] Skipping conversationState snapshot for unloaded user message bubble {“composerId”:“d0d59b3e-9708-4095-93f2-6ccb13c1e776”,“messageId”:“cc60742f-954f-4795-b516-16617ec660c6”}

I found 49 occurrences of this warning across several renderer logs.

Storage evidence from one affected composer:

  • composerData:d0d59b3e-9708-4095-93f2-6ccb13c1e776
  • fullConversationHeadersOnly has 1183 entries
  • conversationMap is 0 at rest
  • persisted bubbleId:: rows exist
  • affected bubble rows have conversationState equal to “~”, which decodes as an empty ConversationStateStructure

In several cases the warning messageId is a serverBubbleId, while the persisted row is keyed by a different local bubbleId. The header contains both IDs.

Suspected failure mode: userMessageAppended appears to check only the currently loaded in-memory conversationMap by the incoming messageId. If the bubble is unloaded/virtualized, or if the incoming ID is the serverBubbleId while storage is keyed by local bubbleId, the snapshot is skipped and the visible bubble keeps an empty/stale conversationState.

Suggested fix: resolve incoming messageId against fullConversationHeadersOnly using both bubbleId and serverBubbleId. If the full bubble is not in conversationMap, retrieve it from persisted message storage by local bubbleId, write the current composerDataHandle.data.conversationState to that bubble, persist it, and only warn if that recovery fails.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

great feedback @Sam8, I don’t have further analysis to do, let’s wait on the team to answer

6

Hey Sam, thanks for the detailed write-up, and respect for digging into renderer.log and storage.

One note on attribution: the warning [AgentResponseAdapter] Skipping conversationState snapshot... is an intentional safeguard. It was added specifically to prevent the renderer from crashing when it tries to write state into a bubble that was unloaded by virtualization. The per-bubble conversationState snapshot is used only for the resubmission flow, when you edit and resend an old message. For a normal sequential turn, a new message after the agent replies, the client snapshot is not used. In that path, the app uses server-managed conversation state, independent of whatever is on a specific UI bubble.

So the warning itself is not the cause of the symptom in the normal flow you described.

But the actual symptom, losing context in long sessions, is real and it is tracked separately. It is tied to virtualization plus summarization behavior when the context window fills up. To dig into your specific case:

  1. In the session where the agent forgot previous turns, please share the Request ID for the message where the agent replied without context. Privacy Mode needs to be off: Cursor Settings → Privacy Mode. To get the ID: chat menu in the top right > Copy Request ID.
  2. Roughly how many turns were in the session, and did you see a summarize or compaction indicator right before the context got lost?

With the Request ID, we can check what was actually sent to the model for that turn.