You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Python writes source .../.venv/bin/activate to existing terminals #23893
Have an remote SSH connection to a workspace where there's a Python .venv. Write some command you might want to run later in a terminal, but don't send it.
Disconnect and reconnect to the remote.
⚠️ Python will automatically write source <path>/.venv/bin/activate to all existing terminals and submit it, resulting in the command being executed
This is a really sharp edge, I had this mess up a notable chunk of work on a remote machine because my unsent command was a destructive action 😞
I've had a very similar problem, even with Terminal: Activate Env In Current Terminal disabled (with Terminal: Activate Environment enabled) but for window reloads or crash recovery.
It's not the exact problem described above, but it basically matches the title of this issue. It doesn't execute commands that one has written to the terminal but not sent/executed, but the extension sends something to the terminal akin to pressing Ctrl-C, and before sending the source command (after reloads or crash recovery). This becomes a problem if one has long-running tasks in the terminal. Right now, these tasks typically survive the initial reload, but end up being killed by the Ctrl-C (or whatever it is) before the source command, unless one is quick enough to reload without extensions before this happens.
Perhaps long-running tasks are able to survive crashes or reloads without being "intended functionality", but since they can survive, a similar switch to the one above, one that disables sending these source commands to existing terminals on reloads and/or crash recoveries, could be useful. If this was the intended behavior for the Activate Env In Current Terminal switch, it doesn't seem to work properly in this case.
My project contains 3 services, one of them is python-based. It usually runs on uv run command, which does not even need venv to run (not directly at least). If I accidentally open python files in the project, every running tasks in the terminal got killed, which is quite annoying.
May be, rather than activating venv by default, wouldn't it better to activate it only if the user uses it? It's kinda annoying having it terminates and mess up every single terminals on the vscode.
Activity
karthiknadig commentedon Jul 31, 2024
There is a setting to disable activation in existing terminals.

connor4312 commentedon Aug 1, 2024
Ah, good to know, I'll flip that off to avoid this.
I think we should still never write the 'activate' command to existing, interacted-with terminals to avoid others hitting this.
oskarr commentedon Mar 26, 2026
I've had a very similar problem, even with Terminal: Activate Env In Current Terminal disabled (with Terminal: Activate Environment enabled) but for window reloads or crash recovery.
It's not the exact problem described above, but it basically matches the title of this issue. It doesn't execute commands that one has written to the terminal but not sent/executed, but the extension sends something to the terminal akin to pressing Ctrl-C, and before sending the
sourcecommand (after reloads or crash recovery). This becomes a problem if one has long-running tasks in the terminal. Right now, these tasks typically survive the initial reload, but end up being killed by the Ctrl-C (or whatever it is) before thesourcecommand, unless one is quick enough to reload without extensions before this happens.Perhaps long-running tasks are able to survive crashes or reloads without being "intended functionality", but since they can survive, a similar switch to the one above, one that disables sending these source commands to existing terminals on reloads and/or crash recoveries, could be useful. If this was the intended behavior for the Activate Env In Current Terminal switch, it doesn't seem to work properly in this case.
MacOS 15.7.2, VS Code 1.112.0, ms-python.vscode-python-envs 1.24.0, ms-python.python 2026.4.0, zsh 5.9.
wutipong commentedon Apr 28, 2026
My project contains 3 services, one of them is python-based. It usually runs on
uv runcommand, which does not even need venv to run (not directly at least). If I accidentally open python files in the project, every running tasks in the terminal got killed, which is quite annoying.May be, rather than activating venv by default, wouldn't it better to activate it only if the user uses it? It's kinda annoying having it terminates and mess up every single terminals on the vscode.