Repository navigation
Terminal no longer auto-activating #25291
Description
Activity
- addedfeature-requestRequest for new features or functionalityRequest for new features or functionality
on Jul 16, 2025 - pinned this issue
on Jul 16, 2025 - addedtriage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team
on Jul 16, 2025 You may now see that when you open a new terminal, it does not auto-activate the python environment in this terminal.
For me it at least sets VIRTUAL_ENV, but for starters the environment is not prepended to PATH.
And I'm not talking about Insiders but 1.102.1.
Reacted by robertHowlettHow can I activate an environment when running tasks? I use tasks for building, and these tasks run Python. This used to happen, but as of #25284 it no longer does. I followed the instructions in this issue but it still doesn't work.
- marked Terminal python launch command not working ? or not stable ? #25293 as a duplicate of this issue
on Jul 18, 2025 eleanorjboyd commented
on Jul 18, 2025 MemberAuthorMore actionsJoseph Thomson (@hpesoj) did you add
"python-envs.terminal.autoActivationType": "shellStartup"? cc Anthony Kim (@anthonykim1)- marked Venv not being added to PATH vscode-python-debugger#754 as a duplicate of this issue
on Jul 18, 2025 - marked .env file no longer being applied #25294 as a duplicate of this issue
on Jul 18, 2025 - unmarked .env file no longer being applied #25294 as a duplicate of this issue
on Jul 18, 2025 Joseph Thomson (@hpesoj) You would just need to make sure your environment is activated.
Did setting auto activation to shell startup work? It would prompt to modify your shell init scripts.Also would help to know which shell you are using Joseph Thomson (@hpesoj)
- addedinfo-neededIssue requires more information from posterIssue requires more information from poster
on Jul 18, 2025 @cpita-mutt Python extension will no longer set/prepend PATH as result of removing terminal env var experiment.
This does not work for R environments. A common and very nice workflow before was managing R installations with different conda environments. Now, when conda environment is selected with python: select interpreter, on opening R console, conda activate <selected_env> is run, which fails because we are in R. Suggested solutions in this issue did not work. Specifying "python.useEnvironmentsExtension": true and "python-envs.terminal.autoActivationType": "shellStartup" leads to the same.
Also, for bash, when specifying "python-envs.terminal.autoActivationType": "shellStartup",
terminal output:
. /usr/etc/profile.d/conda.sh && conda activate epiatl-downstr
bash: /usr/etc/profile.d/conda.sh: No such file or directoryMy conda.sh is not in this location and I am not sure where to specify its location. I would be grateful for any tips.
eleanorjboyd commented
on Jul 25, 2025 MemberAuthorMore actionsAnthony Kim (@anthonykim1) can you take a look at that first part? For the second one, I opened this issue here to work / communicate on it: microsoft/vscode-python-environments#647
- removedinfo-neededIssue requires more information from posterIssue requires more information from poster
on Jul 25, 2025 Interactive Window: Using conda environment with terminal.shellStartup causes errors when entering variables manually
Description
When running code in VSCode's Interactive Window with a Conda environment and a custom terminal.shellStartup setting, I encountered inconsistent behavior:
Clicking the "Run" button (e.g. Run Cell or Run Selection/Line in Interactive Window) works fine, and the code executes normally.
Typing variables manually and pressing Enter inside the Interactive Window causes an error, even though the same environment is being used.
This makes the Interactive Window behave differently depending on whether code is executed via "Run" or typed directly.
Actual Behavior
Run via button: ✅ works correctly.
Run via manual input: ❌ throws an error.
My working environment: - VSCode version 1.105.1 - Python Extension version 2025.16.0, without Python Environment Extension installed - Windows 10 22H2, Ubuntu 20.04.6 LTSI want to share a related issue and its solution:
When using a workspace, the terminal opened with hotkeys (
CTRL+`orCTRL+J) not automatically activating proper venv (Either Python venv or Conda env), but right click and selectOpen in Integrated Terminalseems working properly.Issue and Experiment
For example, suppose the workspace contains three folders: Folder A, Folder B, Folder C.
If my Python project is in Folder C, and I only set the specific venv for Folder C, while Folder A set the default (e.g., the system Python), then when opening a terminal with hotkeys in Folder C or any other folder, the system default Python environment of Folder A will be activated by default, not the venv of Folder C.
Conversely, if I set Folder A to use the specific venv and set Folder C to use the system default Python, then when opening a terminal with hotkeys in Folder C or any other folder, the specific venv will be activated.
Solution
If you have opened a workspace containing multiple folders, and want a specific venv to be automatically activated when opening a terminal with hotkeys, ensure that the Python interpreter for THE FISRT folder in the workspace is set to that specific venv.
You can open a Python file and set the Python interpreter in the bottom-right corner for each folder in workspace. Do not try to set venv with
Select at workspace level. That seems not working.Eleanor Boyd (@eleanorjboyd) Coming back to this after a while as I've just been putting up with it being broken.
I put this in my user settings:
"python.useEnvironmentsExtension": true, "python-envs.terminal.autoActivationType": "shellStartup",I have a task defined in tasks.json:
{ "label": "which python", "type": "shell", "command": "./which.sh", },And the Shell script:
#!/usr/bin/env sh which pythonAnd the output of the task is:
* Executing task: ./which.sh /usr/bin/python * Terminal will be reused by tasks, press any key to close it.The output is the same whether the task type is "shell" or "process".
I have a .venv directory in the root directory that is correctly activated when launching a terminal:
source /<redacted>/.venv/bin/activate (.venv)<redacted>$ source /<redacted>/.venv/bin/activate (.venv) <redacted>$ which python /<redacted>/.venv/bin/python (.venv)<redacted>$I would like the virtual environment to activate when running the task, preferably even if I directly run a Python script from the task (which worked fine previously).
Reacted by soghoyan and Anıl Zeybek- removedtriage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team
on Mar 13, 2026
You may now see that when you open a new terminal, it does not auto-activate the python environment in this terminal.
This issue includes information and resolution to this problem:
We have decided to turn off the experiment "pythonTerminalEnvVarActivation" on VS Code Insiders. (It is still enabled for users on VS Code stable in the interim) This experiment was created a while back to implement auto-terminal activation, but proved to be buggy and highlighted that this approach is difficult to get right for every user. We are now moving over fully to the Python Environments extension as our long-term solution to all environment related tasks. This new extension will work hand in hand with the Python extension to provide a very much improved experience. Learn more about our roll out of this extension by default to Python users here.
With this in mind, these are the steps to get back environment auto-activation upon opening a terminal:
"python.useEnvironmentsExtension": true,to your USER settings (there is a chance this setting will show as "unknown" but it works)A. Do nothing which keeps
"python-envs.terminal.autoActivationType"to its default valuecommandand the activation command will be run in each terminal on openB. Add
"python-envs.terminal.autoActivationType": "shellStartup"to your settings (user or workspace) which will inject the activation script into your shell script for a more automatic activation. Shell startup is only supported for zsh, fsh, pwsh, bash, and cmd.Thank you everyone for your patience and feedback!