In Cursor 1.6.35 and up (currently on 1.6.45) the terminal commands in the agent DO NOT work, at all. There is no way to pop open the terminal, there is no way to cancel, abort, or otherwise get past them. This occurs 100% of the time. Terminal usage by the agent is fully and completely broken.
Steps to Reproduce
Issue a prompt that will invoke a terminal command.
Weep.
Expected Behavior
Terminal commands work.
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
@condor This is a SEVERE issue. The terminal went from very, very buggy, hangy, stalls all the time, to working pretty well with occasional hangs, to never working at all, period.
You guys really need to fix the terminal! It is so critical to modern software development. The request Id I’ve shared has privacy disabled.
FWIW, it seems that the issue was introduced after 1.6.27. I’ve gone back to 1.6.27, and it works. Maybe that will help you guys zero in on whatever caused this.
One coworker said he is on 1.6.45 and the terminals work ok for him. So I don’t know what the deal might be.
More info. Terminal doesn’t engage when on host. Terminal engages in remote. When I work on non Docker project no terminal command execution. When connected to container it works well.
Just a side note, 1.6.27 is not perfect. Ever since 1.6 came out, I have still had terminal stalls/hangs. It was better than 1.5, and on windows better than it was, well, I think ever since 1.0. There are still issues with it.
Terminal issues I think, are the most significant issue that has consistently plagued me with Cursor. Really hoping you guys can put some real focus on these bugs and get the terminal working reliably, as it is one of the most fundamental tools for the modern developer, outside of the code editor itself.
I did a complete uninstall and reinstall on Windows 10 Pro, including nuking all cursor content in C:\Users\Rick\AppData\Roaming\Cursor\User, and my agents came back to life.
I’m running the nightly build now, 1.8.0-pre.5.patch.0 (system setup) and my agent is able to run commands again.
However, this is the same version of Cursor that I was using earlier today that suddenly stopped working.
I have been preparing to do the same thing here. I think that something in all that Cursor data, ended up getting really screwed up during the 1.5.x phase, as that is when things REALLY started to go bad for me.
Its hard, because I am going to be losing EVERYTHING here, all my indexed documentation, all my chats (some of which are quite valuable to near upcoming work), extensions, all my config (which I felt I had finally sorted out.)
I am trying to figure out how to export as much necessary information as I can, before I do this, so I can restore, reinstall, or otherwise recover what I will be losing…
yeah, the problem here is that the terminal kills every command before it finishes. Before in 1.5 we had the oposity problem, the terminal never finished itself. Now it finishes everytime
That is a bit different than my experience. It seems the commands never start at all, or even that a terminal instance is ever created. At least, this is the case in 1.6.35 and up for me. In 1.6.27, the terminal instances are created, and will work for a while, but eventually every one of them will start commands that never actually execute (you can see them in the terminal instance but they do not execute, and you have to kill the terminal instance then instruct the agent to re-run the exact same command and continue from exactly where it left off.)
I haven’t run into a problem where commands run then get killed, though?
They ARE official Cursor downloads, linking directly to the Cursor servers - I just collect the links using the same downloads/update API called by the app.
So I am now back to having a problem that I thought was only occurring with 1.5.x: PTY Host disconnections. I have had the PTY host crash or fail or disconnect many times today. This initially presents as ANY and ALL terminals simply not responding. You don’t know what’s going on at first, the terminals just don’t seem to respond. Sometimes this state can last 30 seconds or so, then rarely the terminals will start working again. Most of the time, though, all terminal instances will go red in the terminal list, and then the yellow PTY Host button shows up in the status bar.
I do not seem to be having any issues with any other terminals I run on my system. Those I run in iTerm2 or Ghostty are fine. Never have any issues. This is purely a Cursor issue, with the integrated terminals.
Literally everything I try is just creating fake outputs via print() or console.log(“ “). no code is actually being created or executing. Ever prompt on every LLM returns fake implementations with a demo, simulation, example, stub etc. It’s really good at developing clever ways to produce anything but an actual working function or method or anything really. It uses code patterns as a way to obfuscate real functionality output
I have completely scrubbed cursor from my system. Ultra-nuked it. Not one scrap of any remnent left. Reinstalled by downloading the version listed on the Cursor site main download area (1.6.45). I am quite saddened to find that has not fixed anything for me. I had thought that maybe something had ended up stuck in all the stuff that Cursor stores in the Libraries/Application Support/Cursor area, as I’ve gone through a lot of versions and upgraded and downgraded a heck of a lot.
I nuked everything, all cursor/, Cursor/, .cursor/ etc. directories and any other related files. Clean install. Still broken. Terminal commands do not execute. It does not even appear that a terminal instance is ever created…and I don’t think that terminals are even hanging. I think it is that the agent cannot create terminal instances, and the agent itself is hanging.
I am also having problems with MCPs. Notably, the list_mcp_servers command always lists nothing. However, I can sometimes get the agent to list the tools it can call, and sometimes, but not always, it will list some of the tools from some MCPs, but then it usually cannot execute any of them (sometimes it will, though, strangely enough.) The two most used MCPs for me are the Supabase and Linear MCPs, but I have others that I use. The Linear MCP is almost always showing a red dot. Sometimes it works, most of the time it does not. I have to disable it for a minute, then reenable, and for a very, very short period of time I’ll be able to use it. Supabase, though, never seems usable. The agent keeps saying it can see a postgres mcp (I don’t have one), and it will sometimes try to execute mcp_Postgres_* commands, however they always fail of course. It cannot seem to see any of the mcp_supabase_* commands.
These issues are debilitating. They have decimated my ability to use Cursor, at least at the latest versions. I have not yet tried rolling back to 1.6.27…which was one of the two versions that worked somewhat ok for me. The other one is 1.4.6.
Just another update. FWIW. Terminals do again work, now that I am back on 1.6.27. Also FWIW, it seems that the two MCPs I have enabled right now, Linear and Supabase, also work. I did disable Linear at one point, and even though I was not seeing a warning about having too many MCP tools, somehow I wonder if disabling Linear MCP allowed Supabase to work.
When the agent tries to search for mcp servers via list_mcp_servers, that still always returns NOTHING. So the models have no way of discovering mcps. I think they only somehow happen to fall upon the correct tool names, such as mcp_supabase_list_tables…just because it has the word supabase in it. But any time the model explicitly looks for an mcp server, it always finds nothing, then it simply will not proceed with even trying.
So post 1.6.27, there seem to have been some regressions. The utter unusability of the terminal is very disturbing.