VS Code February events – Agent Sessions Day on Feb 19th
Dismiss this update
The Python Environments extension brings environment and package management into Visual Studio Code's UI. The extension provides a unified interface for creating environments, installing packages, and switching interpreters, regardless whether you're using venv, uv, conda, pyenv, poetry, or pipenv.
Core features:
The extension works alongside the Python extension and requires no setup to get started.
Most users don't need to configure anything. The extension automatically discovers your Python environments and uses them when running code.
If you have a basic setup, such as one environment for your whole workspace:
Need to create an environment? Open the Python sidebar, expand Environment Managers, and select the + button. The extension walks you through the different steps.
The following environment managers are discovered automatically:
| Manager | Search locations |
|---|---|
| venv | Workspace folders (configurable via workspaceSearchPaths) |
| System Python | PATH, /usr/bin, /usr/local/bin, Windows Registry, python.org installs |
| Conda | Runs conda info --envs to find configured environment directories |
| Pyenv | $PYENV_ROOT/versions or ~/.pyenv/versions |
| Poetry | Project .venv folders and ~/.cache/pypoetry/virtualenvs |
| Pipenv | ~/.local/share/virtualenvs (Linux/macOS) or %USERPROFILE%\.virtualenvs (Windows) |
Discovery runs automatically when the extension activates. The extension uses the Python Environment Tool (PET) Rust binary that scans your system for Python environments. PET finds environment managers by checking your PATH (for example, by looking for conda, pyenv, and poetry executables) and known installation locations, and then searches for environments managed by each of these environment managers.
To manually trigger a refresh:
Cmd+Shift+P or Ctrl+Shift+P)You can also click the refresh icon in the Environment Managers view header.

Select the refresh icon to rescan for environments.
Discovered environments appear in two places:

The Environment Managers view groups environments by type.
Don't have an environment yet? See the Python Projects section for information on how to create one with the extension.
By default, the extension searches your entire workspace for virtual environments using the glob pattern ./**/.venv. This finds any folder named .venv anywhere in your workspace.
To discover environments in custom locations, update the python-envs.workspaceSearchPaths setting:
This setting must be configured at the workspace or folder level, not user level.
{
"python-envs.workspaceSearchPaths": ["./**/.venv", "./envs/**", "./my-custom-env"]
}
Tips:
** for recursive searches (for example, ./**/env finds any folder named env at any depth)To quickly open search path settings:

Add custom glob patterns to search additional locations.
Global search paths: For environments outside your workspace (like a shared ~/envs folder), use python-envs.globalSearchPaths:
{
"python-envs.globalSearchPaths": ["/Users/yourname/envs", "/opt/shared-envs"]
}
This setting requires absolute paths and is configured at the user (global) level.
Legacy settings: If you previously used python.venvPath or python.venvFolders, these are automatically merged with the new search paths. Consider migrating to python-envs.globalSearchPaths for future compatibility.
To use a discovered environment:
The selected environment is used for running code, debugging, and language features like IntelliSense.
By default, the debugger uses your selected environment. To use a different interpreter for debugging, set the python property in your launch.json debug configuration.

Select the Python version in the Status Bar to switch environments. How the extension auto-selects: When you open a workspace without explicitly selecting an environment, the extension chooses one automatically in the following order:
.venv, venv)To override this priority order, set python-envs.defaultEnvManager to prefer a specific manager (for example, ms-python.python:conda), or configure Python Projects for per-folder control. The legacy setting is still supported as well.
| Symptom | Cause | Solution |
|---|---|---|
| Environment not listed | Location not in search paths | Add the path to workspaceSearchPaths or globalSearchPaths |
| Environment shows as "(broken)" | Missing pyvenv.cfg or invalid Python executable |
Recreate the environment or fix the broken files |
| Recently created environment missing | Discovery cache is stale | Run Refresh All Environment Managers |
| Conda environment not found | Conda not detected | Ensure conda is in your PATH or install Conda |
| Settings not taking effect | Wrong setting scope | Ensure workspaceSearchPaths is set at workspace level, not user level |
For advanced troubleshooting, run the Python Environment Tool (PET) directly to see raw discovery output:
pet find --verbose to list all discovered environments with detailed output
PET verbose output shows exactly what environments are discovered and why.
Advanced troubleshooting is useful for the following scenarios:
The extension provides two ways to create environments: Quick Create for speed, and Custom Create for control.
Quick Create
Select the + button in the Environment Managers view. The extension performs the following steps:
python-envs.defaultEnvManager).venv (or .venv-1, .venv-2 if one already exists)requirements.txt or pyproject.toml if foundThis is the fastest way to get a working environment.

Quick Create builds an environment with sensible defaults.
Custom Create
For more control, run Python: Create Environment from the Command Palette and walk through the prompts:
requirements.txt, pyproject.toml, or environment.yml
Custom Create lets you configure each step.
Using uv for faster creation
If uv is installed, the extension uses it automatically for venv creation and package installation, which is significantly faster than standard tools. Configure this with:
{
"python-envs.alwaysUseUv": true
}
When alwaysUseUv is enabled (the default), uv manages all virtual environments. Set it to false to only use uv for environments explicitly created by uv.
Supported managers
| Manager | Quick Create | Custom Create |
|---|---|---|
| venv | ✅ | ✅ |
| conda | ✅ | ✅ |
| pyenv | — | — |
| poetry | — | — |
| pipenv | — | — |
Only venv and conda support creating environments from VS Code. Other managers (pyenv, poetry, pipenv) discover existing environments but don't create new ones through the extension. Use their respective CLI tools to create environments, and then the extension will discover them automatically.
To delete an environment:
Deleting an environment removes the environment folder from disk. Any projects that use this environment will require that you select a new one.
A Python project is any file or folder you want to associate with a specific environment. By default, your entire workspace uses one environment. Projects let you assign different environments to different folders. This is essential for mono-repos, microservices, or testing across Python versions.
| Scenario | Without projects | With projects |
|---|---|---|
| Mono-repo with backend + ML service | Both share one interpreter | Each gets its own environment |
| Testing Python 3.10 vs 3.12 | Manually switch interpreters | Assign different versions to different folders |
| Shared workspace with teammates | Everyone configures manually | Settings sync via .vscode/settings.json |
If you only have one environment for your whole workspace, you don't need to set up projects explicitly. Select an interpreter and you're done.
Workspace
├── Python Project: backend/
│ └── Environment: .venv (Python 3.12)
│ └── Manager: venv
│
├── Python Project: frontend-utils/
│ └── Environment: .venv (Python 3.10)
│ └── Manager: venv
│
└── Python Project: ml-pipeline/
└── Environment: ml-env (Python 3.11)
└── Manager: conda
What uses project assignments?
Pylance and Jupyter currently use a single interpreter per workspace, not per-project environments. See Known Limitations.
To treat a folder or file as a separate project:
Alternatively, select + in the Python Projects view and choose either of these options:
pyproject.toml or setup.pyWhen you add a project, its folder is automatically added to the environment search path. Environments inside project folders (for example, my-project/.venv) are discovered automatically without the need to update workspaceSearchPaths.

Add existing folders or auto-discover projects.
Once a folder is a project, assign its environment:
The selected environment is used whenever you run or debug files in that project.

Click the environment to change it.
When you assign an environment to a project, the extension writes to your workspace settings (.vscode/settings.json):
{
"python-envs.pythonProjects": [
{
"path": "backend",
"envManager": "ms-python.python:venv"
},
{
"path": "ml-service",
"envManager": "ms-python.python:conda"
}
]
}
Notice that settings store the environment manager, not hardcoded interpreter paths. The extension remembers which specific environment you selected separately, and resolves it at runtime. This design makes settings shareable:
/Users/yourname/.venv.venv, it still worksSharing with teammates:
.vscode/settings.json to your repoThe environment folders (like .venv) still need to be created on each machine. Only the configuration is shared, not the environment itself.
Right-click a project in the Python Projects view and select Remove Python Project. This removes the mapping. It does not delete any files.
To scaffold a new project with the right structure, run Python Envs: Create New Project from Template from the Command Palette. Choose between:
pyproject.toml, package directory, and tests.py file with inline dependency metadata (PEP 723)See the full Python Projects guide for details on template structure.
For detailed guidance on templates, multi-root workspaces, common scenarios, and troubleshooting, see the full Python Projects guide.
Install and uninstall Python packages directly from VS Code without opening a terminal.
Or run Python Envs: Manage Packages from the Command Palette.

Search and install packages directly from VS Code.
Installing from a requirements file: You can also install packages from requirements.txt, pyproject.toml, or environment.yml. When prompted, select the file, and the extension installs all listed dependencies.
The extension automatically uses the appropriate package manager based on your environment:
| Environment | Package Manager |
|---|---|
| venv | pip |
| conda | conda |
| pyenv | pip |
| poetry | pip |
| pipenv | pip |
| system | pip |
To override the default, set python-envs.defaultPackageManager.
If uv is installed and python-envs.alwaysUseUv is enabled (the default), package installation in venv environments uses uv pip instead of regular pip, which is significantly faster for large dependency trees.
This section covers all extension settings, how interpreter selection works, and legacy settings migration.
When you open a workspace, the extension determines which environment to use by checking these sources in order:
| Priority | Source | When it applies |
|---|---|---|
| 1 | pythonProjects[] |
If you've configured a project for this path |
| 2 | defaultEnvManager |
Only if you've explicitly set this (not the default value) |
| 3 | python.defaultInterpreterPath |
Legacy setting, if configured |
| 4 | Auto-discovery | Finds workspace-local .venv, then global interpreters |
Key principle: User-configured settings always win over defaults. If you haven't explicitly set defaultEnvManager (it has the built-in default), the extension skips it and checks the next priority.
Caching: The extension caches resolved environments for performance, but your explicit settings always take precedence over cached values. You never need to worry about stale cache overriding your choices.
For more details on interpreter selection behavior, see the Interpreter Selection Quick Reference.
The extension only writes to settings when you make an explicit change:
| Action | Writes to settings? |
|---|---|
| Open workspace (first time) | ❌ No |
| Extension auto-selects an environment | ❌ No |
| You manually select an environment | ✅ Yes, updates pythonProjects |
| You create a new environment | ✅ Yes, may update pythonProjects |
| You change settings in UI | ✅ Yes |
This ensures that opening a workspace does not add auto-generated entries to your settings.json.
| Setting | Default | Description |
|---|---|---|
python-envs.defaultEnvManager |
ms-python.python:venv |
Default environment manager for creating environments. Options: ms-python.python:venv, ms-python.python:conda |
python-envs.defaultPackageManager |
ms-python.python:pip |
Default package manager. Usually determined by the environment manager. |
python-envs.pythonProjects |
[] |
Array of project configurations. Managed via UI, rarely edited manually. |
python-envs.workspaceSearchPaths |
["./**/.venv"] |
Glob patterns to search for environments in your workspace. Must be set at workspace level. |
python-envs.globalSearchPaths |
[] |
Absolute paths to search for environments globally (for example, ~/envs). |
python-envs.alwaysUseUv |
true |
Use uv for venv creation and package installation when available. |
When you open a terminal in VS Code, the extension automatically activates your selected Python environment so that python, pip, and related commands use the correct interpreter.
| Setting | Default | Description |
|---|---|---|
python-envs.terminal.autoActivationType |
command |
Determines how environments are activated in terminals. See below. |
python-envs.terminal.showActivateButton |
false |
(Experimental) Show activate/deactivate button in terminal. |
python.terminal.useEnvFile |
false |
When true, injects variables from .env files into terminals. |
python.envFile |
${workspaceFolder}/.env |
Path to the .env file to use when useEnvFile is enabled. |
Terminal activation types:
| Value | Behavior | Best for |
|---|---|---|
shellStartup |
Activates via shell startup scripts. The environment is active immediately when the terminal opens | Copilot terminal commands, cleaner experience |
command |
Runs the activation command visibly in the terminal after it opens | Compatibility with all shells |
off |
No automatic activation | Manual control |
Use shellStartup if you use Copilot to run terminal commands. It ensures that the environment is active before the first command executes. This will become the default in a future release.
After changing autoActivationType, restart your terminals for the change to take effect. To undo shellStartup changes, run Python Envs: Revert Shell Startup Script Changes.
Opening a terminal for a specific environment:
You can open a new terminal with any environment activated:

Open a terminal with any environment activated.
For detailed troubleshooting and how activation works under the hood, see Terminal Auto-Activation Explained.
To inject environment variables from a .env file into your terminals:
.env file in your workspace root or specify a custom path with python.envFilepython.terminal.useEnvFile to true# .env
API_KEY=your-secret-key
DATABASE_URL=postgres://localhost/mydb
Variables are injected when terminals are created. This is useful for development credentials that shouldn't be committed to source control.
These settings from the Python extension are still supported but have newer equivalents:
| Legacy setting | New equivalent | Notes |
|---|---|---|
python.venvPath |
python-envs.globalSearchPaths |
Automatically merged. Consider migrating. |
python.venvFolders |
python-envs.globalSearchPaths |
Automatically merged. Consider migrating. |
python.terminal.activateEnvironment |
python-envs.terminal.autoActivationType |
Set to off to disable. New setting takes precedence. |
python.defaultInterpreterPath |
— | Still supported. Used as fallback in priority chain. |
python.condaPath |
— | Still supported. Specifies custom conda executable location. |
Settings behave differently depending on where they're configured:
| Setting | User | Workspace | Folder |
|---|---|---|---|
defaultEnvManager |
✅ | ✅ | ❌ |
defaultPackageManager |
✅ | ✅ | ❌ |
pythonProjects |
❌ | ✅ | ✅ |
workspaceSearchPaths |
❌ | ✅ | ✅ |
globalSearchPaths |
✅ | ❌ | ❌ |
alwaysUseUv |
✅ | ❌ | ❌ |
terminal.autoActivationType |
✅ | ❌ | ❌ |
Key insight: workspaceSearchPaths must be set at workspace or folder level (not user level) because it's relative to workspace folders.
The Python Environments extension is designed to be extensible. Any environment or package manager can build an extension that plugs into the Python sidebar, appearing alongside the built-in managers. This means the ecosystem can grow to support new tools without waiting for updates to this extension.
Community members are building extensions for additional environment managers like the Pixi Extension.
Pylance does not support multiple Python projects with different interpreters in the same workspace. Even if you configure separate environments for different folders using Python Projects, Pylance uses a single interpreter for the entire workspace—typically the one associated with the workspace root. To use different interpreters for different folders, add them as workspace folders in a multi-root workspace (File > Add Folder to Workspace), since Pylance runs independently per workspace folder.
Jupyter notebooks do not use the Python Environments API for environment discovery. Instead, they rely on the older Python extension API. This means notebook kernel selection may show a different set of environments than the Environment Managers view.