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
Support profile-specific terminal.activateEnvInCurrentTerminal settings #20562
I am using the Python extension in a workspace whose settings define a terminal.integrated.profiles.linux entry that launches a specialized shell. That shell doesn't understand the source /path/to/folder/.venv/bin/activate command which the Python extension sends to each new shell created using this profile.
I suggest adding a terminal.activateEnvInCurrentTerminal.profiles setting under which I could set the following to disable this:
Extension version: 2023.1.10091012
VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:59:02.252Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.15.79.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.79.1-microsoft-standard-WSL2
Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.
Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.
We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.
Sorry for spamming people who subscribed to this issue with email notifications.
After some digging in the repo, I've found a workaround that effectively does the same thing the OP asked, given that this issue hasn't been fixed for almost 2.5 years.
It seems that "Activate Environments in Terminal Using Environment Variables" was implemented later in the year that this issue was opened, and this would activate the virtual environment without running the source command, which is exactly what the OP asked for.
This feature is currently in experimental and must be enabled explicitly by adding this line to the user configuration (originally found in this comment):
However, I think the original solution proposed by the OP would still hold, if for example, people want to completely disable any form of virtual environment activation for some of their terminal profiles, but I think most people would find the workaround good enough for their use cases.
Activity
karthiknadig commentedon Jan 25, 2023
Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.
brettcannon commentedon Mar 23, 2023
Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.
We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.
mikelei8291 commentedon May 25, 2025
Sorry for spamming people who subscribed to this issue with email notifications.
After some digging in the repo, I've found a workaround that effectively does the same thing the OP asked, given that this issue hasn't been fixed for almost 2.5 years.
It seems that "Activate Environments in Terminal Using Environment Variables" was implemented later in the year that this issue was opened, and this would activate the virtual environment without running the
sourcecommand, which is exactly what the OP asked for.This feature is currently in experimental and must be enabled explicitly by adding this line to the user configuration (originally found in this comment):
However, I think the original solution proposed by the OP would still hold, if for example, people want to completely disable any form of virtual environment activation for some of their terminal profiles, but I think most people would find the workaround good enough for their use cases.