What will happen first, AGI or Cursor successfully invoking your project’s correct environment?
I think I use a very standard Python project setup. I have a virtualenv under .venv/in the project root dir. I have a straightforward uvbased project.
In the editor settings (F1), choosing Python: Select Interpreter to the local venv has no effect on agent. Okay, but that could’ve been nice if agent got the memo.
I have a AGENTS.md explaining my straightforward setup and telling that the local env interpreter need to be used to run any code
agent will still often try plain python run/some/sample/code.py using OS level default Python interpreter
then, agent will usually opt for source /repo/root/.venv/bin/activate && python /repo/root/sample/code.py . But this fails in the Cursor shell, it’s apparently not standard bash or zsh. Because the python command fails on a ModuleNotFoundError. This command will work in a shell inside Cursor if I start it manually, but I guess then I get my proper zsh shell loaded which is a bit ddifferent from the read-only Cursor shell?
even when the above command fails, agent will often assume it succeeded. Does it even look at the output?
I am now in my AGENTS.md telling:
When testing code, use the project specific virtualenv found under .venv
The project uses uv and pyproject.toml to manage dependencies
If you get an import error, do not try to install missing dependencies, rather just stop and tell why you can’t proceed
This will not work:
cd /repo/root && python run_server.py
This will also not work in your agent terminal (venv won’t be activated)
cd /repo/root && source .venv/bin/activate && python run_server.py
But this will work:
cd /repo/root && uv run run_server.py
Please use uv run to run code.
With this, combined with explicitly telling in each prompt, I hope the agent will do the Right Thing moving forward.
This seemingly stupid little detail is why current CLI coding agents seem to work better that Cursor on my end now. Because many tokens are wasted on cursor agent trying to run code before it gives up and makes a change without being able to test it.
Am I missing something or do other people experience these issues too?
I have the same problem. I would expect the configured virtualenv to automatically load in the agent shell so it can run commands. Workarounds like asking the model to activate the virtualenv before running the command works sometimes, but not always.
“python.terminal.activateEnvironment”: true is being ignored in the new agent terminal, meaning that the agents terminal is generally unable to work with python as it has a different environment than the terminal the user will get in the Cursor IDE.
This is a regression, it had worked pre-2.0
Only tested in Cursor on WSL.
Steps to Reproduce
Choose a python environment in the IDE, confirm that when you launch a new terminal you are automatically in your chosen venv.
Now create an agent and ask it to run ‘which python’ in the terminal.
Note that it will not be the correct python.
Expected Behavior
The cursor agent should be in the same python venv as the normal terminal and respect “python.terminal.activateEnvironment”: true from the vs code settings as it did prior to 2.0
Operating System
Windows 10/11
Linux
Current Cursor Version (Menu → About Cursor → Copy)
Below is the ai diagnosis of the behavior I am seeing in the chat agent. The agent thinks I don’t have packages installed. The diagnosis is that it is running my default python/environment. I am using anaconda 3 and have their anaconda-ml-ai environment set up that does include the packages that are needed for the ai code I am running. I have my terminal in cursor setup to run conda activate anaconda-ml-ai, so all of my code that I run in the ide is in the right environment. Are others experiencing this behavior and what is the best solution? I could set my global machine environment path to point to anaconda-ml-ai instead of the base anaconda. Any other thoughts?
What happened on my end:
When I use the run_terminal_cmd tool, it runs commands in your system’s default shell environment, not necessarily the environment that Cursor is configured to use. Even though your .vscode/settings.json is correctly configured, the terminal commands I ran were using the base conda environment by default.
The real issue:
The run_terminal_cmd tool doesn’t automatically respect Cursor’s Python interpreter settings. It uses whatever environment is active in your system’s default shell.
I can confirm that "python.terminal.activateEnvironment": true is ignored by cursors terminal in the agent, despite it working fine in the IDE terminals. This makes it difficult to use the agent for python work.