Recent changes to terminal have completely broken using mise!

[jrista (Jon)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Recent updates to cursor, seem to have introduced a ton of problems into the terminal. I do not use the sandbox terminal nor do I use the yolo terminal modes. I use the LEGACY terminal! I have been for months. The LEGACY terminal has apparently been changed recently, and it no longer functions properly. It has no resource setup, and now it no longer even supports mise which is one of our standard sources for CLI tooling. Everything worked fine a few days ago, since the latest update the terminal is completely hosed. Between frequent hangs and stalls, to no longer even supporting mise (even though I am explicitly having the agent apply the necessary eval "$(mise activate zsh)" && mise install to ensure it is activated, nothing works.

I have ZERO interest in you guys holding my hand and protecting me from myself with regards to the terminal. I have utterly REJECTED the sandbox terminal, I want nothing to do with it, because it simply does not let me do what I need to do. I was told months ago to use the LEGACY TERMINAL mode in Cursor, so I have been. This has been working FINE until the version that installed yesterday, now its completely hosed. Why are you guys screwing with something that worked perfectly fine? This is extremely frustrating, as it has completely halted my ability to work with Cursor here. This is FUNDAMENTALLY BREAKING!

One of the issues, as far as I can tell by opening the agent terminal instances, is that you guys are apparently constantly starting new terminal instances, every few commands! So it often takes me half a dozen commands to get the terminal set up in the first place (i.e. getting mise activated and installed, then maybe activating and installing other zsh functions, plugins, etc. if I need them). However since you guys are ditching terminal instances every few commands now, by the time I actually get to running the ACTUAL commands I need, a brand new terminal instance is being used, and NONE of the previous setup is valid anymore!

Here is an example of this exact thing happening:

(Well, I had to hop on a meeting, and in the time since that started and now, it seems terminal instances were cleaned up, and I can no longer access them). In the sequence of commands above, there was one terminal instance used from the pwd up through the docker-composecommand. When lsof was run after, that was apparently the first command in a new terminal instance, and all the previous commands run up through that point ,which set up mise and all that, which established the environment it was established in a terminal instance the agent was no longer using.

You guys do not support applying any kind of rc file (i.e. .zshrc) to the agent terminals, so there is ZERO standardized environment setup for agent terminals. This was an issue that was introduced way back in 1.7 or so, when the new terminal design was first introduced. I’ve worked around it by creating custom commands that set up the terminal properly each time, which is extremely wasteful of both time and tokens. However even those commands are broken now, because of the recent changes to terminals, and as far as I can tell, this CONSTANT recycling of terminal instances.

Please stop experimenting with the terminal by shipping changes to users before they are vetted. I pay at least $200 per month for this product, so I can be highly productive on a day to day basis at my job. I am not paying you guys to be a beta tester of half-baked, broken features.

Steps to Reproduce

Install mise.
Instruct the agent to activate and install mise in its own terminal instance.
Instruct the agent to install other terminal tools (severa, 3-4 more.)
Instruct the agent to perform other terminal work that involves these tools.
Weep when the agent arbitrarily and repeatedly instantiates new terminal instances, losing all the environmental setup you just put all that effort into, preventing the commands you REALLY NEED TO RUN from working.

Expected Behavior

Stop constantly cycling terminal instances! Environment is critical for many terminal sessions, and constantly nuking terminal instances kills the environment (especially when no rc file is applied to set it up again!), which are often non-trivial to set up.

Support some kind of proper resource config file so that BASELINE ENVIRONMENT SETUP can be STANDARDIZED and automated for every single terminal instance the agent DOES start.

Operating System

MacOS

Version Information

Version: 2.3.41
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.0.0

For AI issues: which model did you use?

Sonnet or Opus

For AI issues: add Request ID with privacy disabled

Request IDs: 38076054-d325-4f6f-b738-498fcb036ad0

(According to my company policies, I CANNOT disable privacy! This is the best I can do! As a side report, being asked to disable privacy all the time for request ids, seems to entirely defeat the purpose of having privacy enabled in the first place, and it often goes against company policies with regards to privacy modes for LLMs and other AI powered tooling.)

Additional Information

This has completely broken my use of the agent, which always involves terminal commands, most of which rely on mise to be installed and activated (which no longer seems to work.)

Does this stop you from using Cursor

Yes - Cursor is unusable

[jrista (Jon)]

I am still trying to get the agent to run my custom commands successfully. I reverted through cursor versions back to 2.3.35, which was released on the 13th (all the others were released on the 16th, according to the github repo I’m getting the official download links from). All the versions seem to be experiencing the same issues.

When running assume (which ultimately delegates to the granted command to support locally signing into AWS from the terminal), it sets environment variables. Until today, I could have the agent run assume, which would authenticate me against the specified AWS account/environment. Then I could have the agent run other commands, independently (i.e. not with command chaining via &&) in separate terminal command execution calls, and they were able to find the environment variables with my AWS credentials and session, and they would run just fine. Same thing for other terminal commands that set environment variables.

FWIW, these are NON-INTERACTIVE terminals that the agent creates. These are NOT my interactive terminals that apply my full .zshrc file.

Well, now, if I export an environment variable in one command execution, its not set in the next. If I export it in one command execution, and chain an echo in the same command line, then the variable does exist.

The agent’s assumption concurs with mine: It appears as though now, the agent must be starting an independent terminal session for EVERY SINGLE COMMAND. Thereby killing any sense of “environment” which used to work just fine in the agent. In the past, the terminal session and any environment setup would persist for the entire chat. That changed around 1.6 or so, and there seemed to be periodic (but sufficiently laggy) session cycling, which caused some problems, but was not egregious.

Now, it appears that every single command, is run in a separate terminal instance/session. This completely DESTROYS the ability to run any commands that rely on having variables/environment variables, or any other environment/terminal setup, that must persist from one command to the next.

What I am now being forced to do, which is absolutely ludicrous, is run chained commands that have 7, 8, 10, even more commands chained together, so that they all have access to the required variables and environment variables! This is insane! Further, if I am having the agent run a sequence of commands that requires using information discovered by prior commands, EACH and EVERY command, is now an insane mess of countless chained commands…effectively setting up the terminal environment/session EVERY SINGLE COMMAND!

This is a totally non-viable situation. What in the world is going on with terminals all of a sudden?

[deanrie]

Hey, thanks for the detailed report and the screenshot. It clearly shows the issue. Mise activates successfully, but after a couple of assume commands it becomes “not found”. The environment is clearly getting lost between calls.

I’ve passed this to the team. For now, the workaround is to chain everything into a single command:

eval "$(mise activate zsh)" && mise install && assume up-dev && <the rest>

I get that this is inconvenient when you have lots of commands that depend on each other. Rolling back to 2.3.34 like you found is also an option until it’s fixed.

Let me know if anything changes.

[jrista (Jon)]

I am trying to stay on 2.3.34. There is a real problem here, because 2.4 apparently makes all aagent chats incompatible with older versions. However, I keep getting force updated every time I close Cursor, which means every time that happens, I have to start my chats over. I don’t know why changes are being made to the chat…data…that is braking backwards compatibility.

Given the nature of Cursor here, where it is a very….volatile product…breaking backwards compatibility greatly increases the risk of using Cursor now. The real bummer here is it seems that if you run Cursor 2.4.x, it screws with all of your chats, no matter what, and since updates are forced and automatic, this problem is progressively eating all my chats given I need to stay on 2.3.34 right now…

In 2.3.34, it works how I’ve been used to, so I am not having to chain commands together, the terminal session and environment work properly. So I’m ok, so long as Cursor does not update on me. Which makes the real issue, the forced automatic updates. Would be really nice if you guys could give us a switch to turn that off, and a button to update IF and WHEN we choose to when set to manual.