Cursor Agent terminal defaults to bash regardless of default terminal set

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

with a recent update, Cursor agent now defaults to bash terminal ( I use ZSH) as well does not share normal terminal scopes when running it’s terminal commands. Besides the fact that the terminal is read only, whatever this change was it is causing ALL kinds of trouble for me. Best example is up until last update, the Cursor agent would be able to use: kubectl commands without any issue. once i authenticate in any terminal window with AWS the Cursor terminal would be able to run kubectl commands without any issue, now it says “user is not authenticated” this is adding literally hours upon my develop time

Steps to Reproduce

set default terminal to Zsh then instruct Cursor agent to run any type of termional commands and note it defaults to using bash. Then use aws configure sso and run kubectl commands in any terminal (MacOS) without any issues then instruct Cursor Agent to run kubectl commands and note the authentication issue.

Expected Behavior

Cursor agent should use default terminal (zsh) set in Cursor settings and should be able to run any kubectl commands without auth errors.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.6.35 (Universal)
VSCode Version: 1.99.3
Commit: b753cece5c67c47cb5637199a5a5de2b7100c180
Date: 2025-09-19T17:39:38.846Z
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

For AI issues: which model did you use?

claude-4-sonnet

Does this stop you from using Cursor

No - Cursor works, but with this issue

2

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi everyone,

I’ve noticed a recent change in how the Cursor Agent executes terminal commands. It seems that the Agent no longer uses an interactive shell, which means it doesn’t load my .zshrc file.

Even when I explicitly configure VS Code to use an interactive shell, the Agent seems to ignore it. Here’s what I have in my settings.json:

"terminal.integrated.defaultProfile.osx": "zsh",
"terminal.integrated.profiles.osx": {
    "zsh": {
        "path": "/bin/zsh",
        "args": ["-i"]
    }
},
"terminal.integrated.automationProfile.osx": {
    "path": "/bin/zsh",
    "args": ["-i"]
}

As a result, aliases, environment variables, and tools configured in .zshrc are unavailable when the Agent runs commands.

Is there a new recommended way to configure the Agent to use an interactive shell or ensure it loads .zshrc properly?

Thanks in advance!

Steps to Reproduce

Try to run a command defined in .zshrc via agent

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.6.23 (Universal)
VSCode Version: 1.99.3
Commit: 9b5f3f4f2368631e3455d37672ca61b6dce85430
Date: 2025-09-15T21:49:07.231Z
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

Does this stop you from using Cursor

Yes - Cursor is unusable

3

Hey, thanks for the report. We’ll look into it.

1 Like
5

I am also suffering from this problem in the newest Cursor (Version: 1.6.45). None of the settings I change for terminal profile can force it to stop using /opt/homebew/bin/bash (my MacOS user’s default shell).

I wouldn’t have a problem with this, but something that’s unique to Cursor’s invocation of bash causes my cd command to completely break, making it impossible for the Agent to change directories. This has something to do with Autoenv, because I get this error message when the AI tries to cd, unless I take the setup for Autoenv out of my .bash_profile file:

--: line 76: __autoenv_has_builtin: unbound variable

Autoenv works just fine in my actual terminal, and even in the Cursor integrated terminal. It only breaks for the AI agent.

I asked the agent what terminal it uses, and it mentioned “I use the run_terminal_cmd tool which runs commands in your system’s shell.” So I’m guessing that maybe `run_terminal_cmd` got broken in a recent version?

6

Any news on when this will be fixed?

Just checking if there’s any update or timeline for a solution. Would be great to know if it’s planned for an upcoming release.

7

I had some luck changing Cursor settings as follows:

"terminal.integrated.profiles.osx": {
    "bash": {
      "path": "bash",
      "args": [
        "-l",
        "-c",
        "source ~/.profile 2>/dev/null; source ~/.bashrc 2>/dev/null; exec bash -l"
      ],
      "icon": "terminal-bash"
    }
}
8

This unfortunately did not work for me. I still get the same problem of the cd command being completely broken, as if my autoenv setup is corrupt somehow.

9

Hey folks, we’ve made some changes to how the agent terminal works in recent releases. As you’ve noticed, the agent terminal is no longer interactive, however it does source all shell profiles that an interactive terminal typically would. We’ve found that disabling interactivity significantly improves the stability of the terminal tool and results in fewer situations where Agent is blocked. We always use the shell specified by the SHELL environment variable on your system, and the terminal.integrated.* settings only impact the cursor integrated terminal (ctrl+`), not the agent terminal.

@coredumperror the issue you’re encountering with unbound variables was fixed in yesterday’s release (1.7.40). Please let me know if you’re still encountering the issue.

10

Thanks for the update! I don’t see that error any more when the agent tries to use cd… but now I see a new error that makes cd equally broken. >_<

I told the Agent to cd into a folder and run ls, just for a simple test. Here’s what I got:

$ cd /Users/coredumperror/dev/palomar_rms/palomar_rms/registration && ls
--: line 74: chdir: command not found

No idea what file it’s even complaining about, now. The error doesn’t appear to depend on there being a .autoenv file in the folder it’s cd’ing into, as it will fail with the same error even if I remove my .autoenv file.

11

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.