[CRITICAL] Intermittent Bug: Agent Conversation Data Loss Without Warning

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I encountered a critical data loss bug in Cursor. While it appears to be intermittent, the impact is severe—all unsaved instructions are permanently destroyed.

Problem Summary
Under certain conditions, a newly created Agent conversation spontaneously closes without any warning, and the entire conversation—along with all typed but unsubmitted instructions—is permanently deleted. There is no draft state, no recovery mechanism, and no way to retrieve the lost work.

Steps to Reproduce

  1. Open Cursor
  2. Create a new Agent conversation (Cmd/Ctrl+I)
  3. Start typing detailed instructions in the input field
  4. Without submitting the message, open a documentation file or switch focus to another panel/document
  5. [Bug Occurs] The Agent conversation panel unexpectedly closes
  6. Check the conversation list—the new conversation is completely gone with no draft state

Expected Behavior

  • The conversation should remain open regardless of focus changes, or
  • Unsaved typing should be automatically saved as a draft, or
  • A save/discard warning should appear before the conversation closes

Operating System

MacOS

Version Information

Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

UPDATE: Important Finding About This Issue

I discovered something significant that changes how we should understand this bug.

What Happened

After the initial conversation disappeared, I created a second Agent conversation and:

Typed instructions in it

Started the conversation

Clicked Stop before completion

Closed that conversation

Then: The original “lost” conversation reappeared as an Agent conversation window. It was still treated as a new conversation and did not return to the conversation list, but all of the instructions I had previously entered were still there.

What This Suggests

This appears to be a conversation state management issue rather than actual data loss. The conversations may be entering an unintended hidden state rather than being deleted.

Areas That May Need Review

Conversation visibility — Conversations disappearing from the list without being deleted

State transitions — Recovery happening unexpectedly when other conversations are created/closed

UI feedback — No indication that conversations exist but are hidden

Persistence logic — Unclear conditions that cause conversations to reappear

Potential Impact

Users experience concern over lost work (though data may be retained)

Recovery is unpredictable and accidental

The underlying behavior needs clarification from the team

I’d appreciate the development team’s insight into whether this is expected behavior or an unintended state transition.

This bug has persisted since version 3.x and remains unresolved, particularly within the agent window. If you click “Stop” immediately after sending a message, there is a chance the entire conversation will simply vanish. Additionally, if you encounter the occasional “cyber” block associated with Claude or GPT models while using the tool, a sent message might be “crashed” back into the input field. If you have already engaged in a multi-turn conversation, having a previously sent message reappear in the input field causes severe confusion in the agent’s context for subsequent exchanges.

Hey there!

It’s tied to the Preview / Markdown toggle on a .md file. If your cursor is still in the Agent input when you click Preview, the chat tab gets replaced instead of the markdown file. Nothing is deleted, which matches your conversation coming back later with the typed text intact.

Workaround: click inside the .md file first, then click Preview.

We’ve let the team know and this is an issue we’re tracking. I’ll post here when there’s an update.

@jojolionss - the Stop-button behavior you’re describing looks like something separate. Could you open a new thread for it with your version and exact steps so it gets tracked properly?