Was having the same issue with latest version last week. I downgraded to 1.6.x (don’t remember exactly), and terminal commands were working again. I used that version for a couple days then decide to install latest to see if it had been fixed. Commands worked on latest for about a half a day then stopped working again.
Does anyone know if we are any closer to a fix on this? This makes Cursor radically less useful.
Same problem.
Version: 1.7.12
VSCode Version: 1.99.3
Commit: b3f1951240d5016648330fab51192dc03e8d7050
Date: 2025-09-28T00:58:08.696Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0
I have the same problem on whatever latest 1.6. The same fix works too: drag 1.6 to the 
, install 1.5, and everything is fine again. I’m on a Mac M2, os 15.6.1.
Similarly, I’d note that the “run command” feature of Cursor is the whole differentiator for the product; and congratulations, quite a differentiator it is, but without it there’s no real value-add for Cursor. So this is something that should be fixed quickly.
This is one of the (of not THE) single most debilitating and severe issues Cursor has right now. Its been at an absolute minimum two weeks here, if not longer, since these issues were first surfaced (latest version that works for me was 1.6.27, every version after that has this PERSISTENT issue with ZERO terminals invoked by the agent working at all).
You guys are now pushing nightly builds for 1.8.x!!! ALL 1.7.x builds have this issue. Many of the 1.6.x builds have it. MOST of the 1.5.x builds have DIFFERENT terminal issues, as do most of the builds in 1.4 and 1.3, across all platforms. Terminal issues on Windows, which have always been more severe, span all the way back to 1.0 and prior!!
There has not been much communication on this issue. I have seen some blatant misunderstanding ofthe issue by Cursor team members (read a post earlier where a team member was saying that the agent was “just showing the user a command the user could run” which is ABSOLUTELY NOT the case! The panel that appears in the agent, looks different than a normal RUNNING terminal, because it appears the terminal instance IS NOT STARTING, so there are none of the regular ui/buttons surrounding the terminal panel that is normally expected, however it IS INDEED a real, normal terminal panel…its just bugged!)
This issue is clearly affecting many, many people. In addition to my own thread, there are also these threads:
There was an even earlier thread, documenting the frequent terminal stalls, hangs, freezing, etc. that I myself also participated in, starting months ago:
There are also many threads of similar but tangential issues with the termainal hanging in other circumstances (such as after a command DOES run, and completes, usually successfully, the agent does not proceed…I experience this a LOT, even with 1.6.27):
Guys, this is KILLING your product. I am simply unable to move beyond 1.6.27, because terminals beyond that version, are simply dead. They do not work, at all, period, in any way. That is WORSE than what we had before, where terminals sometimes failed to run or the agent sometimes failed to recognize command completion. The problem is now 100% persistent, and has been permanent since 1.6.27. Even the nightly 1.8.x builds, STILL have this issue.
This is 100% utterly debilitating. This utterly blocks all usage of the agent, for anyone doing any serious work with it. I will not be able to move beyond 1.6.27, until this issue is fixed, and you guys seem to be moving on to 1.8.x now….while this game-ending, full-stop issue is NOT FIXED.
The terminal is so critically fundamental to my work, I honestly could care less about any other new features, other QoL improvements, other bug fixes. The only thing I care about when it comes to Cursor: DOES THE TERMINAL WORK? Literally, this is the single driving question I have every day now: Is the terminal GOING TO WORK? Even in 1.6.27, the agent cannot seem to recognize that commands have completed, at least 25-30% of the time. There seems to come a point where every existing terminal instance, becomes unusable, and the agent can no longer execute commands with it. Eventually it starts creating more and more and more terminal instances, and after a while of that, you can have a couple dozen terminal instances (with old instances hanging around, using up memory, and causing other problems.) After a while, the terminal issues mount, and you start getting PTY Host issues, and then ALL your terminal instances, started by the agent or by you, begin having problems, hang crash or disconnect, and the problems just get worse.
IMHHO, there is NOTHING more important right now, than the Cursor dev team, dogpiling on THIS ISSUE, and fixing it once and for all. UTTERLY. DEBILITATING. PRODUCT KILLING. PROJECT ENDING. This issue defines Cursor right now.
Why does the terminal interaction work in containers?
Why does codex have no problem with terminal on host machine?
Because of terminal I have to connect to container, even it’s slower to work on remote.
I thought that might be some access rights issues, but it wasn’t. Could it be that I use fish instead of bash? But it worked before in fish.
@jrista we hear you. I sent the issue again to the team!
I’m curious, as I seem to have received this a lot recently. What exactly causes the PTY Host connection issue? When this occurs, usually, at first, the terminal instances will start to slog…they don’t seem entirely “dead” yet, but they take a LONG time to do anything, and system resource usage spikes. I am currently on an M4 (non-pro), and as I’m learning, these things are actually REALLY handicapped versions of an M4 Mac. So any resource spikes, really take down the whole system.
When these PTY Host connection issues start occurring, my entire system is affected. Eventually whatever is going on, results in the connection between cursor and every single terminal instance to fail. In the terminal list in the integrated terminal area of Cursor/VSCode, a red broken connection icon appears next to all of them. A yellow button labeled PTY Host appears in the status bar. I have to click that, to try and reconnect all the terminals.
I don’t recall seeing that PTY Host button, nor do I ever recall having this issue, before 1.5.x. Whatever this PTY Host connection issue is, though, it has system-wide implications, at least on a normal M4 (which is supposedly, supposed to be still, a very very powerful CPU.) I am just curious what changed here, in 1.5.x or thereabouts, with terminal pty connections, that has caused this resource-sucking, all-consuming issue to hang the entire system, WHEN the connection issues occur. There were terminal failures prior to 1.5, for sure, but I never recall them having such a dramatic and all-encompassing effect, like they do now. It even seems to hang my other terminals (i.e. in iTerm 2 or Ghostty), until the connection has indeed fully failed within Cursor. Once Cursor is disconnected from PTY, then the perf issues vanish, and I can reconnect, and things will be fine….for a while, before the issue occurs again.
Exact thing affecting me, when tokens and requests are so precious the amount wasted due to Cursor bugs recently is crazy. I’m on M4 Mac FYI.
Can it be that you are having the issue mostly on Remote SSH? We are trying to narrow down the causes as some of the cases we aren’t able to reproduce.
I don’t use remote SSH, it’s any type of local terminal command. Get the skip / run button, click run, does not look like it even tries to do anything. The skip / run button disappears and that’s it, can’t pop out a terminal or see what it’s running because it just does nothing apart from remove the buttons from what I can see. Running Mac OS.
Version: 1.7.17 (Universal)
VSCode Version: 1.99.3
Commit: 34881053400013f38e2354f1479c88c9067039a0
Date: 2025-09-29T03:10:26.099Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0
This would be all local terminals. I work locally, and very rarely use ssh. When I do, it is usually just to run commands manually on a server or docker. I have not coded or had the agent operate remotely through SSH though. Its all just local terminals.
FWIW, I use zsh, with ohmyzsh (bunch of shortcut aliases and theming). I am not sure if ohmyzsh has any impact now that you guys do not seem to be applying the .zshrc file. However I don’t know if somehow zsh itself has an impact here.
Otherwise, all local terminal usage.
Terminal is broken. MCP is broken. Anyone tried upgrading to 1.7x?
For me the terminal finally started working 
on
Version: 1.7.17
VSCode Version: 1.99.3
Commit: 34881053400013f38e2354f1479c88c9067039a0
Date: 2025-09-29T03:10:26.099Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0
Thanks god I am not only one facing this, because I am going crazy. After few days update, my Terminal stopped working. Agents can’t run any commands.
I am on Ultra plan, and the only reason I am on Ultra plan is because I am using Cursor as my Devops guy to go inside servers, do cleaning, updates, etc.
After the ■■■■ update, the Cursor can’t do anything anymore. It became totally useless for me.
If you don’t provide us any update on this not gonna cancel my plan but I will ask for refund.
The OP guy here is giving his soul to make this work, and none of the Cursor team is even care to respond here.
Yeah, you might be all on the fancy MacOS, but there people still using Windows here.
@condor
My original post on Reddit from few days ago:
Did Cursor just limited terminal / PowerShell agents with their latest update?
limit
For months, I was using Cursor as a DevOps agent to clean and fix my server. It was using PowerShell, login via SSH, and I was only needed to type my SSH passphrase.
Everything worked before I went to sleep, and when I woke up, there was update coming from Cursor, I installed and can’t do things which was able to do before.
Like maybe I am tripping, but I dont remember those messages before. Especially the one in terminal that says “Agents terminals are read only”.
Can anyone confirm?
I’m having the same issues — the agent runs a command but gets no response, then starts modifying the previous command and runs it again.
This started happening with version 1.7.
Maybe this will be a clue: I’m working through Remote Explorer, but I think the problem is global.
Version: 1.7.23
VSCode Version: 1.99.3
Commit: 5069385c5a69db511722405ab5aeadc01579afd0
Date: 2025-09-30T02:52:09.100Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin x64 24.6.0
P.S.
I tested this same issue on the latest nightly build — the problem is not fixed.
Not working for me for about 2 weeks. Stuck shell commands when I upgraded to 1.6.
I contacted support and they said the issue was being investigated. That was over a week ago, still no answer.
I had to downgrade to 1.15.11. Now it works, but not as well as on earlier versions.
The terminal integration got worse over the past month or so. The first symptom of things going bad was the following error message being displayed for evey single shell command being executed: **_encode:25: command not found: -e
**
Later versions stopped showing the shell command output, until finally the commands stopped working altogether.
It seems like a major shift on the shell integration design is taking place here. Whatever it is, please go back to the old design from around 1 month ago.
This issue does not seem to affect everyone, but it affects lots of people. I use a MBP M3 with ZSH. I tried to switch to bash, but it had no effect. As stated by others, this bug should be high priority, because it cripples the tool and causes the user to waste tokens on broken chats. There should be a way to refund us for tokens wasted due to Cursor bugs.
The old design had plenty of issues as well. Which is why it was all redesigned in the first place. Version 1.6.27 works for me. It still has the problem of periodic/occasional terminal hangs (which usually requires forcing a new terminal instance to be created, by closing the old one after popping it out from the agent), so it is not perfect. But in my experience, it is better than 1.5.x anything.
Overall, 1.6 did seem to bring a generally more stable terminal experience, until AFTER 1.6.27, when the current issue began with 100% of terminal commands run by the agent failing.
So, cursor auto-updated itself AGAIN (there REALLY, REALLY needs to be an option to TURN THAT OFF! This product is NOT ready for evergreen status!), to 1.7.17. Terminal issue is STILL present. Exact same behavior as all versions SINCE 1.6.27: Terminal panel added to agent, but no terminal instance started, no icon to pop terminal instance out shown in upper right corner of panel, no buttons shown in lower right of panel, no terminal output logged.
There terminal instances are not starting, in any version post 1.6.27. That now includes up through 1.7.17.
I was able to disable auto update using this configuration option:
“update.mode”: “none”
It only works after restarting cursor, so you may still get it updated once after setting this option.