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/bin on PATH, or on Linux with python3.13 and python3.13-freethreading installed, 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, usr or opt.
- 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
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,usroropt. 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 PETmain; uv 0.12.17 with~/.local/binonPATH.Before: three Global entries all read Python 3.13.15 kanadig (the Windows user name). They are uv's
python.exe,python3.exeandpython3.13.exelaunchers inC:\Users\kanadig\.local\bin:Suffixes the view computes for other global interpreters:
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.exeAppDataC:\Users\<user>\AppData\Local\Python\pythoncore-3.14t-64\python3.14t.exeAppData/usr/bin/python3.13bin/usr/bin/python3.13tbin/usr/local/bin/python3.13usr/opt/homebrew/bin/python3.13optSame-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/pythonand free-threaded/usr/bin/python3.13twould both read Python 3.13.13 bin once microsoft/python-environment-tools#569 is fixed.Cause:
computeDisambiguationSuffixesusesgetEnvironmentParentDirNamefor every environment. That helper assumes a venv layout (<project>/<venv>/bin|Scripts/python→<project>). For an interpreter that sits directly in abinor 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.13vspython3.13t). Keep the project folder name for venvs.Steps to verify fix:
~/.local/binonPATH, or on Linux withpython3.13andpython3.13-freethreadinginstalled, open the Environment Managers view and expand Global.AppData,bin,usroropt..venv (3.12)environments in different projects still show their project folder names.Found by Copilot