Agent loses entire conversation when interrupted mid-work

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have not been able to reproduce this bug, but it has happened multiple times today and I believe it has something to do with the agent starting background processes that do not finish before the user clicks “stop”.

When the process ends, the chat is restarted anyways (has been a bug for a while), which is extremely annoying. But what is even MORE annoying, and breaking my long horizon experiments, is that the chat conversation seems to disappear entirely from the agents memory.

Previous “summaries” also disappear, and the agent loses all track of its goal. Also there is no agent transcripts for the session, proven by the fact that the agent cant find it. I think what happens is the session is never properly ended, and all the end triggered processes never run… but why does the summary disappear? And why does the summary then not reappear when the chat is resumed? Probably the summary is generated on cursors backend, and re-injected on every new agent turn.. but wait, does this mean you guys are keeping my data, even though I am on Legacy Data Retention Mode?

I think I fixed it by forking the conversation once, but I am not entirely sure. Now the fork did not seem to fix it, and I need the agent to read the plan, and all the recent changes to files to understand what its currently doing (and has been doing for over a days worth).

Sorry for this chaotic rant/bug report that does not contain a way to reproduce it.

Steps to Reproduce

Can’t

Expected Behavior

The agent is not supposed to lose all memory of its current long-running task, when I close cursor, and open it up again and write “continue”.

Operating System

Windows 10/11

Version Information

Version: 3.22.7 (user setup)
VS Code Extension API: 1.128.0
Commit: 37076c6c3f9e253c0fa2305197e45befd13a2260
Date: 2026-09-24T05:01:24.589Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

An open sourced model through a work gateway.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

@post4k — useful report. One isolation that would help a lot:

When the Goal / prior summaries vanish, is it immediate on Stop (chat restarts and the Goal text/ID is already gone), or only after the next wake / resummarization turn?

If you can catch one more occurrence, compare before vs after Stop:

  1. Goal text (or any Goal ID if shown)
  2. The latest committed summary / checkpoint the agent still “knows”
  3. Whether an agent-transcript path exists for that session

Hypothesis worth checking: Stop should record cancellation without replacing the last committed continuity state. If the backend summary is rewritten on cancel (instead of kept and re-injected), that would match “summaries disappear and the Goal never comes back,” even when you resume the same chat.

Forking helped you once — was the Goal still present in the fork source, or already blank before the fork?

A short before/after sequence (and build / request ID if you have one) would make this actionable for whoever owns session continuity.

7

Hey, thanks for the detailed report, and no need to apologize for the “messiness”. There’s more than enough here to dig in.

What you’re describing matches what I found. After closing and reopening Cursor, the chat UI still shows all your messages, but the saved history the agent actually uses comes back almost empty, so it basically starts over. Fork only helps a bit. It starts from an older saved checkpoint tied to an older message, and that checkpoint can be hours old. I shared this with the team.

On data retention, the conversation history and its summaries are stored locally on your machine as part of the chat. Summaries are generated during the request itself and returned to the client along with the conversation state. When privacy mode is on, we don’t keep a durable copy on our side, which is also why we can’t restore lost context from our end.

Until this is fixed, here’s what should protect a long-running task:

  1. Before closing Cursor, let the current run finish, or wait until there are no background commands still running, instead of clicking Stop and exiting right away.
  2. Keep the plan and a short progress log in a file in the repo, so a new chat can pick it up.
  3. If it happens again, open a new chat, add the old one via @ → Past Chats, attach the plan file, and ask the agent to continue from there.

If you’ve got a couple minutes, this would help confirm the trigger. Please use a throwaway chat, not your real task:

  1. Open a new Agent chat.
  2. Send: “Remember the word PINEAPPLE.” and wait for the reply.
  3. Send: “Run ping -n 300 127.0.0.1 in the background and wait for it to finish.”
  4. While the command is still running, click Stop.
  5. Close Cursor via File → Exit.
  6. Reopen Cursor and the same chat.
  7. Send: “What word did I ask you to remember?”

Does the agent remember the word? If not, immediately open Help → Toggle Developer Tools → Console and paste here any lines that include the words “conversationState” or “checkpoint”. Let me know how it goes.

9

Not a fix for the bug itself, but something that helps with long runs: have the agent keep a PROGRESS.md next to the plan and update it after every milestone, with the goal, what’s done, what was tried and failed, decisions made, and the next step. Add a rule: “after any restart or summary, read the plan and PROGRESS.md first.” Commit small checkpoints too, so git log doubles as history. Then a lost summary costs one file read instead of a day of rebuilding. The data retention question deserves a direct answer from staff.

11

Hey @Madhur_Mittal, great workaround. Keeping a PROGRESS.md next to the plan, plus a rule like “after a restart or summary, read the plan and PROGRESS.md first” really cuts the cost of losing context down to a single file read. I recommend it to anyone running long-horizon tasks.

@post4k, I’ll answer the data retention question directly since it matters:

  • In Privacy Mode Legacy Data Retention, the chat history and its summaries are stored locally on your machine as part of the chat.
  • Summaries are generated at request time and returned to the client together with the conversation state. That means the data passes through our side while we process the request, but in Privacy Mode we don’t keep a durable copy of the conversation.
  • That’s why we can’t restore lost context from our side. We simply don’t have it.

What you’re describing where the UI shows all messages but the model starts almost from scratch isn’t something in your setup. I passed it to the team, we’re tracking it, but I can’t share an ETA yet.

If you can spare a couple minutes to try the throwaway repro from my last message PINEAPPLE + background ping + Stop + restart, it would help confirm the trigger. If the agent forgets the word, open Help > Toggle Developer Tools > Console right away and send the lines that include conversationState or checkpoint. Let me know how it goes.

12

Thanks @deanrie.