When using Cursor as an external ACP agent inside JetBrains Rider AI Chat, after Rider restart (or Windows reboot) the same chat thread still shows the full conversation history in the Rider UI, but the agent behaves as a brand-new session: it has no prior turns, decisions, or context unless the user pastes them again.
In JetBrains Rider, open AI Chat with Cursor ACP agent.
Have a multi-turn conversation (several messages, decisions, code changes).
Restart Rider (or reboot Windows).
Reopen the same chat thread — UI still shows previous messages.
Send a follow-up like “continue” / “add what we agreed”.
Observe: agent acts as if it never saw the previous conversation.
Expected Behavior
After IDE restart, reopening the same thread should restore the ACP session (session/load) so prior user/agent messages are available to the model. If resume is unsupported, UI should clearly say agent context is not restored.
Operating System
Windows 10/11
Version Information
JetBrains Rider 2026.1.4 (Build #RD-261.26222.60, built on July 1, 2026)
Cursor ACP / agent plugin: v2026.07.09
OS: Windows 10 (build 19045)
Cursor IDE: not used (Rider only)
For AI issues: which model did you use?
Auto
Additional Information
Not an API quota issue. Not model forgetfulness within one live session.
Rider persists UI history; Cursor ACP agent does not get prior turns after restart.
Workaround (paste history / project logs) is unreliable and wastes tokens.
Please check: does Rider call session/load with correct sessionId, and does Cursor ACP replay history for JetBrains clients?
Hey, thanks for the detailed report. I’ll break down what’s going on.
That gap you’re referencing ACP: No conversation history is restored when loading an existing session was on Cursor’s side and was fixed in 2026.06.04. The ACP agent now replays the conversation history on session/load and restores the session context. Your plugin v2026.07.09 already includes that fix.
But your symptom is different from that bug. In that thread the UI stayed empty. In your case it’s the opposite. The UI shows the history, but the agent starts without context. That’s the typical signature of the client not calling session/load with the saved sessionId, and instead just re-rendering its own transcript and opening a new session via session/new. So the history you see is Rider’s local transcript, not a restored ACP session.
Restoring history and context is done by the client calling session/load. Here the client is the AI Assistant in JetBrains Rider which is a third-party JetBrains plugin, and on Cursor’s side we can’t affect its behavior, like whether it saves the sessionId and reuses it when you reopen the thread.
To confirm it’s client-side, try reproducing the same scenario in another ACP client, like Zed. Open a multi-turn session, restart, then send a follow-up. If context persists after restart there but not in Rider, that points to Rider’s handling of session/load, and it’s worth filing with JetBrains.
Let me know what you see when you test in another client.
same chat id: create → reuse (same process) → dispose → create again after restart
So this is Rider AI Assistant client behavior (local transcript re-rendered, ACP session not resumed). Filed with JetBrains YouTrack and attached the ACP logs zip.
Awesome, the ACP logs confirm everything. session/load count = 0 and the constant session/new is exactly the signature we talked about. So Rider is re-rendering its local transcript, but it isn’t summarizing the ACP session.
Thanks for taking the debugging all the way and opening a JetBrains YouTrack ticket with the logs attached. That’s the right move, the next steps are on their client side. On the Cursor side, session/load with history replay works, so once Rider starts calling it correctly with the saved sessionId, the context will restore properly.
If JetBrains has any questions about how our ACP agent behaves, send them here and we’ll help with the details.