@condor Maybe this will help: when the agent tries to run a command, the following errors appear in Developer Tools.
I tested the same thing on version 1.6.27 — those errors didn’t occur, and the console worked as expected.
I’m using this as well FYI
On MacOS, I was forced to downgrade to 1.6.35, which also required nuking ~/Library/Application Support/Cursor and ~/.cursor to actually downgrade. Deleting the .app and downloading an older one is insufficient.
No setting would convince the terminal to run in zsh, but that wasn’t really the issue. The issue was a necessary shell startup script to set env vars and activate a virtualenv before running commands, and as of an update or two ago it appears to unset all env vars but not defined functions, so things like autoenv and direnv fail miserably.
There appears to be a massive, several-thousand-line startup script run every time a terminal is opened. This is jank made manifest.
Please can we have more of an explanation of where we are at with this? we are paying customers… I’m having to do multiple times more requests as anytime it tries to run a command I’m having to copy and paste it and run it manually and then attach the terminal output so the agent can continue. It’s such a major headache as I’m probably having to do this 50-100 times a day now. What’s worrying is a prior reply someone alluded to it not being able to be replicated which seems insane the amount of reports coming in and different posts.
Have you tried going back to 1.6.27? The terminals in that work for me, work better than they did in 1.5.x, are generally more reliable for more of the time than 1.4.x. You might lack other features of newer versions, but, IMO, having a working terminal is better than any of the other new features as of yet.
latest build on mac apple silicon zsh - after update to latest Версия: 1.7.28 (Universal) stop responding!
how to revert version?
how did you find that?
Mine has started working today on 1.7.28 even without selecting the “Legacy Terminal Tool” option 
thanks!
I was upgraded to 1.7.28 today. So far, terminals seem to be working. I have not had even one hang or stall on me, in any way, at any time. So maybe this, is the golden moment for the terminal integration!
Will keep an eye on things, but, at the moment 1.7.28 is working well for me.
Thanks for your reports, they’re really helpful. Please let me know if the issue comes back.
Issue still exists. It’s very simple.
Every command that is made in the terminal, agent hangs on it.
If I open the terminal where the command runs and press carriage return, agent stops hanging and continues. This needs to be done with every command.
facing same issue 1.7.28 request id
446127bb-2e14-4866-8480-460bdd84dd43
Enabling this option on 1.7.28, the terminal is working again.
I’m using zsh with oh-my-zsh.
Version: 1.7.28 (user setup)
VSCode Version: 1.99.3
Commit: adb0f9e3e4f184bba7f3fa6dbfd72ad0ebb8cfd0
Date: 2025-10-01T02:45:21.769Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100
Using Zsh causes this issue.
It’s a simple as that, and whilst it should be fixed, the best solution right now is to use Bash instead.
I moved to Bash during 1.4 and now can just get on with coding again.
It’s irritating because I want to use Zsh, but I’ve had to make my peace with it, that if I want to use Cursor, I’ll need to make do with Bash.
Cursor devs seem accutely aware of the issue, but for some reason Agent terminals and Zsh don’t play nicely together.
So, let’s just consider this a known, irritating, limitation of Cursor for now: if you want to use Cursor with (the new) Agent terminals, you can’t use Zsh.
Edit: I’ve read further and seen the ‘legacy’ terminal toggle for unsupported shells (presumably Zsh) has fixed it for some
Well, since I have upgraded to 1.7.28, and I am now on the below version, I have not had any issues with the terminal. It has been stable and reliable since .28 as far as I can tell. NOW, FWIW, I did go through a complete removal and scrub of all cursor related data, then a clean reinstall. It may well be that there WAS INDEED some bad data stuck in old cursor data that was partially related to the terminal issues. It wasn’t long after I did that, that 1.7.28 was released and I upgraded.
It is possible that if you are still having terminal issues, a removal and scrub of all cursor data then reinstall, might be warranted. FWIW, for the first time since I started using Cursor, 1.7.28 was truly the FIRST time the terminal seemed stable and reliable. I started using cursor before version 1.0, and I had terminal issues back then, and one way or another, there have been terminal issues until 1.7.28.
I am currently on 1.7.33, and things are still stable. I have finally, FINALLY, been able to wholly rely on the agent to get things done, and I think I’ve had two hangs which as far as I could tell, were more likely due to outstanding model connection issues. Otherwise, Cursor is finally a tool I can truly leverage and rely on to perform my daily work, which is quite intense right now and absolutely requires leveraging the agent. There are still some issues with built-in tooling like @Docs, @Git, and numerous others that still seem to be broken, but with the terminal working there are a variety of workarounds that work reliably now.
Version: 1.7.33
VSCode Version: 1.99.3
Commit: a84f941711ad680a635c8a3456002833186c4840
Date: 2025-10-03T03:28:06.574Z
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.5.0
Had a lot of heavy terminal usage by the agent today. It appears there are still stalls. They are not nearly as common as before, but the terminal instances still do hang. When I have had 7, 8, 9 terminal calls in a row, it seems more likely to occur on the next. I am not sure why that occurs, and it would be nice to have perfect reliability in the agent/terminal integration, but at least it is a much rarer occurrence now.