Two bugs involving default LLMs and chat migrations

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A couple things: 1. I can tell that the default LLM for a new chat tries to go to my last used setting but them always switched to CG High. This needs to stop. I have to change the model at the beginning of every single chat and it’s obnoxious.
2. I am having issues with having copied and moved my projects to another drive. So since I’ve added rules that they need to be on the C drive instead, the beginning of every chat spends tokens reminding itself that it needs to be on the C drive. ALSO, (and here’s the real bug) after this chat migration toast message comes up in the bottom right, the chat restarts in the same project but then skips the prompt it was just executing on and then automatically starts the chat that I have queued. This is an obvious bug.

Steps to Reproduce

For #1. Start a new chat.
For #2. Have a chat migrate while having other prompts queued.

Expected Behavior

For #1. Start new chats on my default or last used LLM.
for #2. Keep the chat going after migrating.

Operating System

Windows 10/11

Version Information

Version: 3.20.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
Date: 2026-09-12T03:16:10.634Z
Layout: Agent Window
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.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

8

Hey there, thanks for the report! Two separate things:

1. New chats switching to Cursor Grok 4.6 High. Turn it off in Cursor Settings → Agents → Conversation → Default Model → Last Used. New chats will then keep your last-used model. It’s per machine, so set it on each computer.

2. Chat “migrating” and jumping to your queued prompt. That isn’t intended behavior. The agent re-roots to C: mid-task because of your project rule, and a queued message ends up running instead of the interrupted one. We’ve let the team know and it’s an issue we’re tracking. Best workaround for now: open the project directly from its C: copy (Open Folder), so it never needs to move, which also stops the “must be on C:” token waste each chat.

Let me know if #1 sorts out for you.

9

Thanks Mohit.

#1 is fixed.

Re: #2, this WAS open from a project on C but for some reason needed reroute back from D persists. If I go to “Edit workspace” it even says C, with no other folders accepted. It is a strange issue.