Hmm, the bugs with prompt editing are even more complex:
Just updated to 1.6.27, and this code now works with gpt5 and sonnet4, but gemini-2.5-pro still doesnât work.
@andrewh has anyone else reported something similar?
Every time I switch between two running chats, it automatically scrolls to the top, this is incredibly frustrating and seriously inefficient. I couldâve easily opened a few more chats, finished my subscriptions faster, and even switched to a new account in no time.
After dealing with the issue not being able to run any commands any more in the agent terminal and the agent still taking these errors as successful command runs, I read about the terminal change in the changelog now.
To me it feels like a huge step back for it to be read only, so you got zero control. Also thereâs no formatting applied any more, no colors etc. Was this intended? Until this is fixed, I will have to go back to 1.5 now.
I cant get Grok 4 to do anything - it will run 1 command and then end the conversation. This was working ok in the last release?
Changlog looks up to date - NICE! 
Lots of syntax errors in commands like mongosh commands, did you removed the âmaybe MCPâ for commands?
@condor I feel I need to back up the sentiment here. Not being able to interact with the new terminals when you pop them open, is a step back from what we had before.
The models are quite dumb, and will frequently run commands that run inside of an interactive pager like less meaning they get stuck. Previously, I would interact with the terminal to quit out of the pager in such instances. This happens, despite having rules that tell the model to make sure they are disabling any pagers, and I even have examples for certain kinds of commands like git, pgsql, etc.
There are other times when being able to interact with the terminal is useful.
Iâll also second that the loss of all formatting and terminal config, is a bummer. Everything is basically a big white wall of text in the terminal now, which can make it a challenge to find specific things that were easier to find before.
The new terminal is much more STABLE, which is very welcome. It seems more reliable than the old. So there are improvements that have resolved some of the worse issues from the near past.
One thing I did find about one phase of the old terminal. When a command was stopped, because it was risky or not in the allow list. We received a reject button. I know, that you can simply hit stop, and get the same behavior, but, it was actually nice and convenient to have âRejectâ as an option at a stopped command.
Yes we got several comments about readonly terminals and usability, so team is aware already.
@condor I think I saw previous mention of this. Loading prior chats is broken. Just bringing up the list of prior chats causes Cursor to hang for a long, long time. If it unhangs, often it does not, then selecting a prior chat from the list, results in cursor hanging indefinitely âloading chat.â This is not just the AgentâŚits the entire IDE. Has to be force killed and restarted.
Which version are you running right now? Does it happen only in that project or also in a new project?
We had such an issue before but improved performance a lot in last few versions, though may be a regression in recent update. Team got the report as well.
Can someone address the change in the behavior of the cursor/code shell command? Instead of opening a file or folder in the app (as still documented here), it now behaves as basically an alias for cursor-agent.
Itâs been reported a few times:
- this topic using a 1.6.0-dev build
- this topic using 1.6.3, and posts go up through 1.6.26
- this post seems to confirm it in 1.6.27 (which might be missing a patch entry in the changelog)
I wrote about it briefly here, but to summarize, this seems like an odd change that was intentional but undocumented, and effects range from general confusion, to breaking peopleâs scripts, to possibly making the product unacceptable for security reasons.
If this change was actually already documented somewhere, could someone point us to it? I havenât been able to find it, and thereâs been no explanation as to what was changed, or why. At this point itâs becoming less about the technical change and more a matter of trust.
Iâve reached out to you several times, but it really feels like no one is listening. I donât get this type of error when using the extensionâfor example, when a decline occurs. I only encounter this error when using the course, regardless of whether Iâm using my own API key or the auto model.
It would be helpful if you could implement a function in the program that attempts the request a certain number of times before displaying this error. Constantly having to click âcontinueâ is very frustrating, especially during peak hours when the server is under heavy load. This error message keeps popping up repeatedly, and I donât experience this issue with other encodersâonly with Cursor.
Most probably your internet is â â â â . Have never seen this.
@condor Well, with a bit of sadness, I have to report I am still experiencing terminal stalls. It is not as frequent as it was before, but, it still does occur, and many times a day it seems.
Terminals stalling has been a long standing problem. I first started using Cursor in mid spring, and Iâve had this issue since early on. I think it may have been around v1.0 that I first noticed it on Windows, and in 1.2 the issue became SEVERE. Debilitatingly severe, to the point I simply couldnât use cursor on windows 11 + WSL2.
The stalling problem moved to mac in 1.4, big time in 1.5. I had hoped it was resolved with 1.6, but I am still encountering it. Less frequently, but still too often (I mean, ZERO stalls would be the expectation, however its still often enough that I have to semi-babysit all my chats to make sure they are still running.)
Anecdotally, it seems that part of the issue may be when a terminal has been running âtoo longâ then stalls begin to occur. However that is just an anecdotal analysis, and I donât know for sure what causes it. I have not noticed that any particular kind of command stalls more often than any other.
âEven if itâs an online course, what theyâre absolutely sure about is that other programs donât offer thisâonly the course does. For example, HU has a feature that allows retrying in case the internet fails. A course shouldnât lack that option.â
Yes we are already working on it @Lawrence_S
@jrista yes terminal is in progress and will be fixed.
If I may take a wild guess, was the change around the cursor shell command because the team wants cursor to eventually be the ârealâ command for Cursor CLI instead of cursor-agent? Perhaps with some regret for having âwastedâ it as a convenience command by following VSCodeâs example, which it wasnât an issue for them because they donât have a CLI component by the same name. And maybe the team was attempting to do a silent but seamless migration, but unfortunately things were overlooked and there wasnât a plan about how to communicate the changes if needed, and it was just another thing on the pile of things that needed fixing.
I guess it doesnât really matter now, so maybe just for future reference, hereâs a suggestion for a migration plan for something like this. Iâm sure Iâm getting some stuff wrong, and names are all whatever, kinda going off of vibes here.
0. Original state (v1.5 in this case)
-
cursor .opens the IDE -
cursor-agentruns Cursor CLI -
cursor-agent editor .opens the IDE (or whatever the Cursor CLI equivalent ofcursor .is)
1. Deprecation warning, opt-in behavior change (v1.6)
-
changelog update about the flag, instructions, timeline, etc
-
cursor .no behavior change, prints deprecation warning telling people to useOPT_IN=1 cursor editororcursor-ide -
OPT_IN=1 cursoralias forcursor-agent, so people can start switching whenever theyâre ready -
OPT_IN=1 cursor editor .drop-in replacement for old behavior -
cursor-agentno behavior change -
cursor-ide .alternative drop-in replacement for old behavior, same old script without needing Cursor CLI
2. Switch from opt-in to default (some later version, whateverâs appropriate)
-
changelog update about the switch, hopefully most people are ready
-
cursornow runs Cursor CLI, prints message about usingcursor editororcursor-idefor anyone who missed it, can remove eventually -
OPT_IN=1 cursorno behavior change, for people who already switched, no need to check flag now -
OPT_IN=1 cursor editor .no behavior change, for people who already switched, no need to check flag now -
cursor-agentno behavior change, but now an alias forcursor, prints a deprecation warning if planning to deprecate eventually -
cursor-ide .no behavior change, this is the convenience shell command now
The main benefits are:
- transparency, let people know what changes are coming, and why
- less disruption, since people have time to test and update their scripts, habits, etc
- less complexity for the team, since the thereâs no need for the single Cursor CLI command to be overloaded with both the old and new behaviors, which needs brittle checks for paths vs prompt arguments
- no extra script download and install for people who donât use Cursor CLI, or just canât have that happen, plus the old convenience script is much faster
Overall maybe there just needed to be a bit more planning around this, and definitely more communication and transparency. Life happens and things break, we all know that, but itâs much harder to accept when thereâs no heads up and no explanations are given.
Or I could also be way off on everything lol.