Chat Loading Issue After Long Session Reopened

Describe the Bug

When I have a long chat session in the Cursor editor and it gets closed (intentionally or unintentionally), reopening the session and submitting a new request causes the chat to remain stuck in a “loading” state. No response is ever received, and the editor becomes unresponsive in that session.

This issue has occurred multiple times, disrupting my workflow and requiring a restart or workaround to continue. It seems specific to sessions that were long or had extensive history before being closed.

Steps to Reproduce

1.	Start a long chat session in the Cursor editor, involving multiple requests and responses.
2.	Close the chat session (either intentionally or due to an external cause, like a crash or timeout).
3.	Reopen the same chat session.
4.	Submit a new request in the reopened session.
5.	Observe the chat getting stuck in a “loading” state without any response.

This issue has been consistently reproducible for me under these conditions.

Expected Behavior

When reopening a previously closed chat session in the Cursor editor:
1. The session should load properly with all prior history intact.
2. Submitting a new request in the reopened session should be processed promptly, with a response generated as expected.
3. The editor should remain fully functional and responsive, allowing continued interaction without requiring a restart or workaround.

This behavior ensures a seamless user experience, even after closing and reopening long chat sessions.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 0.43.6
VSCode Version: 1.93.1
Commit: a846435528b4b760494a836f96f0739889253530
Date: 2024-12-06T05:11:55.168Z
Electron: 30.5.1
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.5.0

Additional Information

•	This issue has occurred multiple times, particularly with long chat sessions containing extensive history.
•	No error messages are displayed in the editor during the “loading” state; the request simply does not progress.

Does this stop you from using Cursor

No - Cursor works, but with this issue