Feature request: option to re-enable traditional virtual environment activation for terminal identifier

Issue Description

Recent updates to the Visual Studio Code Python extension (25 October) have changed how the activation of virtual environments is handled in the terminal. While the environments are indeed activated, the traditional visual indicator (e.g., (.venv)) is no longer displayed in the terminal prompt. This change, whilst addressing certain technical limitations, has impacted the user experience by removing a clear and immediate visual confirmation of the active environment.

Suggested feature

I propose introducing a setting in the Python extension that allows user to choose between the new implicit activation method, which uses the new VSCode API, and the traditional method of automatically running activate or .\venv-name\Scripts\Activate.ps1. While there are benefits to using this new VSCode API method, I personally much prefer seeing the name of the virtual environment in the terminal, as it provides a constant confirmation that your venv is activated and when it’s not. It also makes it much easier to work on different projects with different virtual environments simultaneously.

An option in the Python extension settings to return to the old activation method, if feasible, would be a very welcome addition, as it would restore the visual venv indicator in the terminal. Alternatively, if it would be possible to implement a different type of visual indicator displaying the name of the currently activated vend in the terminal, that would also be fantastic.

Rationale

The primary reason for this request is the clarity and assurance that comes with the visual indicator. Many developers, including myself, find it incredibly useful to have immediate visual feedback confirming which environment is active or whether one is active in the first place, especially when working with multiple projects or environments.

Additional context

From my understanding, based on the discussion in issue #11039 on the Python extension’s GitHub repository, this change was made to overcome certain technical challenges. Whilst the rationale is understandable, providing users with the flexibility to choose their preferred method could greatly enhance the user experience without compromising the extension’s functionality, provided this is a feasible and possible feature to implement to the extension.

Thank you for considering this feature request. The Python extension is a vital tool for every Python developer using VSCode, and enhancements like this could significantly improve the development workflow.

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.

From my end, it doesn't necessarily need to be the old activation method offered. Key is the visual indicator, e.g. (.venv). , which indeed I also miss.

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.

For powershell on windows, adding this to settings.json works as a workaround:
(assuming the venv dir is in the opened directory and called .venv, this is the default when creating a venv with Python: Create Environment... -> Venv)

"terminal.integrated.profiles.windows": {
        "PowerShell": {
          "source": "PowerShell",
          "icon": "terminal-powershell",
          "args": ["-NoExit", "-Command", "$venvPath = \".venv\\Scripts\\Activate.ps1\"; if (Test-Path $venvPath) {& $venvPath}"]
        },
        "Command Prompt": {
          "path": [
            "${env:windir}\\Sysnative\\cmd.exe",
            "${env:windir}\\System32\\cmd.exe"
          ],
          "args": [],
          "icon": "terminal-cmd"
        },
        "Git Bash": {
          "source": "Git Bash"
        }
      },

This is the default setting, except with added args for the profile "PowerShell".

With these args, a command is passed to the new powershell process.
The command checks if .venv\\Scripts\\Activate.ps1 exists and executes it if it does. Adjust the path as needed and note the escaped quotes.
-NoExit is needed so the new terminal doesn't just immediately exit after running the command.

Hope that helps 😄

Hi there! 👋
This are related to environment and terminal activation has been a big point of improvement in our new Python Environments extension. Check out this documentation to learn about the different settings and how you can control the behavior here

Let me know what you think and if this is what you are looking for or if you have bugs / feature suggestions related to the new design! Thanks

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

Navigation Menu

Repository navigation

Feature request: option to re-enable traditional virtual environment activation for terminal identifier #22611

Issue Description

Suggested feature

Rationale

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: option to re-enable traditional virtual environment activation for terminal identifier #22611

Description

Issue Description

Suggested feature

Rationale

Additional context

Activity

github-actions commented on Dec 11, 2023

ClaasRostock commented on Dec 23, 2023

brettcannon commented on Feb 8, 2024

suuppl commented on Jul 17, 2024

eleanorjboyd commented on Dec 8, 2025

github-actions commented on Jan 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions