Cursor Terminal - Shell Profile

Feedback
1

With the newer agent terminal integration, which I think first landed in 1.6 and was finally stabilized in 1.7.35 or something like that, the terminal instances no longer seem to apply the user’s default shell profile or resource file. This means that none of the user’s standard shell config is available within the agent terminals.

There are numerous consequences of this, but one of the most notable is things like shell integration and tool integration setup and activation scripts. Say Mise which we use for all of our projects. If I need to have the agent do anything in the terminal, that relies on mise, I have to have each and every chat set mise up, install, etc. Further, it seems like the new terminal integration frequently “churns” terminal instances…so when I have the agent doing terminal work that relies on these kinds of shell tools, they frequently stop working, because in teh background, transparent to the developer, the old terminal instance was just left behind, and a new terminal instance was created.

Is there a way to configure a terminal shell profile or resource file that the agent terminal instances will use? There are certain standard tools, scripts, clis, etc. that I really need our agent terminal instances to be able to use. Currently I’ve been resorting to creating custom commands, which set up each of these various things. However I have to run them frequently, they burn up tokens re-setting up STANDARD shell config that every single shell instance should have anyway, and its a rather tedious and frustrating experience in any case having to have the agent constantly re-run things that it shouldn’t have to worry about.

If there is no current way to set up a profile or resource file for the agent terminal…we could really use one. To simplify our lives, standardize the agentic terminal experience for each developer, and reduce token waste.

1 Like
2

So here’s the fix that works for me:

In settings.json:

  // Terminal configuration for agent terminals
  // Use wrapper script that sources workspace config
  "terminal.integrated.profiles.osx": {
    "zsh (with workspace config)": {
      "path": "${workspaceFolder}/.cursor/zsh-wrapper.sh"
    }
  },
  "terminal.integrated.defaultProfile.osx": "zsh (with workspace config)"

And the exciting zsh-wrapper.sh code:

#!/bin/zsh
# Wrapper script for zsh that sources workspace config

# Workspace-specific shell configuration
export CURSOR_WORKSPACE_CONFIG_LOADED="yes"

# Source your main .zshrc if it exists
if [ -f ~/.zshrc ]; then
    source ~/.zshrc
fi

# Add workspace-specific configurations below
# (Add your custom configs here)

# Start interactive zsh
exec zsh
1 Like
3

Thank you for that!! I’ll probably set up a separate rc file, as I have a lot of config set up in my personal .zshrc that I don’t think I want in the agent’s terminal. At least, though, I can set up all the standard stuff so I can stop wasting tokens running commands to set this stuff up over and over.

1 Like
4

And the latest update caused some more wierdness. It occurred to me there was a simpler fix. I just added this to settings.json to escape the sandbox and let the AI run in my normal shell. You can obviously customize the shell command as you desire to do something else:

  // Terminal configuration for agent terminals
  "terminal.integrated.profiles.osx": {
    "justzsh": {
      "path": "/bin/zsh"
    }
  },
  "terminal.integrated.defaultProfile.osx": "justzsh"
1 Like
5

Well, I cannot seem to get this to work for the agent. It only seems to affect the interactive terminal shells that I myself use…it does not seem to have any impact on the terminal instances that the agent itself creates. Those terminal instances do not pick up ANY baseline config from anywhere, as far as I can tell…which is a huge problem.

6

OK. That doesn’t jive with my experience. Here’s my example. In my .zshrc I override pytest with a local function:

image
image1270×1368 102 KB

7

I wonder why there are such inconsistencies. I’ve tried everything, and the terminal.integrated.*settings only seem to apply to the integrated termianls that attach to the IDE that I interact with myself.

Those settings, at least with Cursor 2.0.5x, have never had any impact on the agent terminals that appear in the agent chat. This apparently only applies to the new style terminal integration for the agent.

I did eventually try switching back to the Legacy Termainals. The legacy terminals, in fact, must be applying my normal .zshrc or something, because that seems to work, at least most of the time. It also brought back the classic Allow List, which I MUCH prefer over the new sandbox. I have noticed that sometimes the terminal just seems to lose all env config, and I have to kill and restart Cursor to get it back to working order…but it only works properly, if I use the Legacy Terminal Tool mode.

Note though, that editing the terminal.integrated.* settings STILL has no impact on the terminal instances the agent uses. Switching to Legacy Termainal Tool mode seemed to make my mise and brew and env variables etc. that are usually set by my .zshrc file, work…but, it does not seem as though those terminals are applying my actual .zshrc, so I don’t know HOW they are working…they just seem to. At least, for now…I guess time will tell if that remains to be true.

8

Uhg. FWIW: I’m running 2.0.60 on a Mac M4

image
image1702×318 14 KB

9

@deanrie @andrewh @condor

Hey guys. There really is a problem here with the terminals not using a profile. I am constantly running into issues where the agent terminal instances do not have access to common, standard tools. Even something as basic as pnpm, which IS available, but only when the right env setup has been run (i.e. setting PATHs, running things like mise activate zsh, etc.) , thse commands don’t run in the agent terminals by default. Each time I start a new chat, I run into the issue of my basic, standard commands not being available.

This causes problems, waste of tokens, and increased cost. There is a HUGE waste of tokens, as now I have to set up my environment every new chat. Worse than that, though, the agent/models will frequently try other things first…I have switched entirely to pnpm in our projects, and no longer use npm, however despite a plethora of rules that tries to deny the agent the ability to use npm and force the use of pnpm, the agent will almost always first try using npm, npx, etc. I then have to interject, tell it never to use npm, and tell it to set up the environment AGAIN, so that it can use the tools mandated by my rules.

You guys are costing your users a lot of money now, by forcing SO MUCH mundane, standard junk that should just be taken care of by standard mechanisms that we’ve had for, heck, generations (literally) now, like a shell profile or RC file. It is not good to be pushing so much into the agent, as it is very wasteful of both time and money (tokens).

We really need a way to configure an RC file or profile for agent terminal instances. Ideally, this would be configurable differently and separately from the profile/rc config for interactive terminals users actually use (in which case, they should use our standard rc files, in my case ~/.zshrc). I need certain env setup that EVERY terminal the agent starts gets, but I don’t need (or even want) it to be as heavy and extensive as my interactive terminal env setup.

10

Here is an example of the issue with not having a proper shell profile for agent terminals. As you can see, I’m at my wits end with the issue. We stopped using npm in our projects, but the agent keeps using it, because when it tries to run pnpm the first time, it fails in a way that it seems like pnpm is not installed. I have to tell the agent to stop using npm and use pnpm on a continual basis. I even have rules, that explicitly DENY the agent the right to use npm and make it MANDATORY that it use pnpm and even explain how to set up the environment so pnpm works, but the rules don’t seem to be followed (not automatically at least, despite being always apply), I STILL have to do this, every time the agent tried to run pnpm:

Screenshot 2025-11-12 at 11.01.16 AM
Screenshot 2025-11-12 at 11.01.16 AM963×509 50.3 KB

Once I finally get to this point and “yell” at the darn model, it will finally go through the process of trying, failing, then activating mise and installing mise packages and then finally running pnpm properly. The really insane thing is, it literally HAS to install mise packages each time. They do install, they are not already installed, for some reason, which totally baffles me. Because I installed them, and they ARE installed. I’m using the legacy terminal (at least, I think I am….sometimes its hard to tell if I’m legacy or sandbox now…), so I don’t know why the mise packages have to be constantly reinstalled in the agent terminal instances only.

Part of the problem seems to be that, the agent apparently can create (or perhaps…”gets” might be a better term) a new terminal instance, at any time. It seems somewhat arbitrary, but after I start getting one terminal instance’s environment set up, suddenly all the setup work I did to get my commands working vanishes, and I have to set up again. I started opening the terminal instances, and there does come a point with each where new commands are no longer run in the last-opened terminal instance, and if I open the terminal instance from the most recent command, it is indeed different than the previous.

So there is some kind of terminal instance cycling, that makes this issue so much worse: I set up the environment, one little bit at a time, so that the agent can use all the CLI tools I need it to be able to use, then the terminal instance I’ve finally set up is tossed, and I have to start all over again.

This is a really infuriating problem. We really need a way to configure a profile/resource file for the agent terminal instances. This kind of setup of low level environment config, should occurs automatically every single time a new terminal instance is created.

11

Its a never-ending war :confounded_face:

Screenshot 2025-11-12 at 12.43.47 PM
Screenshot 2025-11-12 at 12.43.47 PM903×654 62.8 KB

12

This continues to be a serious problem. The agent, since the redesigned terminals were introduced, has SEVERE problems running commands. There is no environment anymore…or rather, it is an empty environment. Necessary platform, path, config, custom command, alias, etc. setups simply do not exist anymore. Its a blank slate that only supports the most vanilla of terminal usage. The agent now has to BURN tokens trying to figure out why commands it suspects (or has been told via rules) should work, do not. This is extremely frustrating. We really need a custom agent terminal resource/profile script.

1 Like
13

I’m running into this as well. Is there clear documentation on how the sandbox terminal spawns a new session? Are there any configuration options to specify which terminal entry point should be used?

1 Like