Repository navigation
Identical, meaningless suffixes for same-name global interpreters in Environment Managers #1893
Description
Problem: When environments in the Environment Managers view share a name, the view adds a suffix to tell them apart (#1196). For global interpreters, that suffix is a path segment that doesn't identify the interpreter: the user name, AppData, bin, usr or opt. Interpreters in the same folder always get the same suffix, so they still can't be told apart.
Environment: Windows 11, VS Code 1.140.0, Python Environments main @ 52f6ace with PET main; uv 0.12.17 with ~/.local/bin on PATH.
Before: three Global entries all read Python 3.13.15 kanadig (the Windows user name). They are uv's python.exe, python3.exe and python3.13.exe launchers in C:\Users\kanadig\.local\bin:
Suffixes the view computes for other global interpreters:
| Interpreter | Suffix |
|---|---|
C:\Users\<user>\.local\bin\python.exe |
<user> |
C:\Users\<user>\.local\bin\python3.13.exe |
<user> |
C:\Users\<user>\AppData\Local\Python\pythoncore-3.14-64\python.exe |
AppData |
C:\Users\<user>\AppData\Local\Python\pythoncore-3.14t-64\python3.14t.exe |
AppData |
/usr/bin/python3.13 |
bin |
/usr/bin/python3.13t |
bin |
/usr/local/bin/python3.13 |
usr |
/opt/homebrew/bin/python3.13 |
opt |
Same-name global interpreters are common. The uv launchers above show up today (the duplicate discovery itself is tracked in microsoft/python-environment-tools#567). Regular and free-threaded builds share a version: Fedora's regular /usr/bin/python and free-threaded /usr/bin/python3.13t would both read Python 3.13.13 bin once microsoft/python-environment-tools#569 is fixed.
Cause: computeDisambiguationSuffixes uses getEnvironmentParentDirName for every environment. That helper assumes a venv layout (<project>/<venv>/bin|Scripts/python → <project>). For an interpreter that sits directly in a bin or install folder, it climbs past the folder that identifies it.
Suggested fix: Use the part of the path that differs within the group: the executable's folder for environments that aren't venvs, and the executable name when the folders are the same (python3.13 vs python3.13t). Keep the project folder name for venvs.
Steps to verify fix:
- On Windows with uv's
~/.local/binonPATH, or on Linux withpython3.13andpython3.13-freethreadinginstalled, open the Environment Managers view and expand Global. - Verify that same-name interpreters have different suffixes that identify them (for example the executable names).
- Verify no suffix is the user name,
AppData,bin,usroropt. - Verify two
.venv (3.12)environments in different projects still show their project folder names. - Verify environments with unique names have no suffix.
Found by Copilot

Activity
Copilot commentedon Oct 13, 2026
The agent encountered an error and was unable to start working on this issue: Please try again later, or contact support if the problem persists. (Request id: 2EF2:1AA88D:2DCC17:3C4D1C:6ACE487F)