Project structure telemetry overrides defaultInterpreterPath to latest system python version

[clarker0]

Environment data

• Python Environments extension version: 1.28.0
• Python extension (ms-python.python) version: 2026.4.0
• VS Code version (Help → About): 1.117.0
• OS and version: any
• Python version (& distribution if applicable, e.g. Anaconda): multiple versions installed (see repro steps)
• Environment manager in use (venv / conda / pyenv / poetry / pipenv / system / uv / other): system (implicit via legacy configuration)
• Shell (bash / zsh / fish / pwsh / cmd / other): any
• Remote / container scenario (none / WSL / SSH Remote / Dev Container / Codespaces): any
• Workspace type (single folder / multi-root / mono-repo): any
• Is this a regression? If yes, last known working extension version: has been a bug for a long time, 1.16.0 I think? took a while to track it down!

Repro Steps

I have three python interpreters installed at /usr/bin/python3.11, /usr/bin/python3.13 and /usr/bin/python3.14.

For this VS Code workspace I have python.defaultInterpreterPath set to /usr/bin/python3.11, and no explicit settings for python-envs.

On extension startup, the correct Python version 3.11 is selected but sometime later (async) it will revert to the latest installed system version 3.14.

Expected behavior

The Python Environments extension should use the default system interpreter for all folders in the workspace if only python.defaultInterpreterPath is set. (in my case Python 3.11)

Logs

2026-04-28 09:49:57.685 [info] [interpreterSelection] Applying initial environment selection for 1 workspace folder(s)
2026-04-28 09:49:57.685 [info] [pet] Telemetry:  {"event":"RefreshPerformance","data":{"refreshPerformance":{"total":43,"breakdown":{"GlobalVirtualEnvs":0,"Locators":21,"Path":43,"Workspaces":2},"locators":{"Conda":21,"Homebrew":0,"LinuxGlobal":10,"PipEnv":0,"Pixi":0,"Poetry":0,"PyEnv":0,"Uv":0,"Venv":0,"VirtualEnv":0,"VirtualEnvWrapper":0}}}}
2026-04-28 09:49:57.685 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.685 [info] Extension for manager ms-python.python:venv is not active: Activating...
2026-04-28 09:49:57.685 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.698 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.706 [info] Refreshing pyenv environments
2026-04-28 09:49:57.725 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.727 [info] Pipenv not found via settings, cache, or PATH
2026-04-28 09:49:57.728 [info] Refreshing pipenv environments
2026-04-28 09:49:57.729 [info] Pipenv not found via settings, cache, or PATH
2026-04-28 09:49:57.729 [info] Found 0 pipenv environments
2026-04-28 09:49:57.731 [info] Pipenv not found via settings, cache, or PATH
2026-04-28 09:49:57.744 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.746 [info] Refreshing poetry environments
2026-04-28 09:49:57.746 [info] Poetry executable not found
2026-04-28 09:49:57.763 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.777 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.779 [info] [SYS_SET] scope=/workarea/test_repo/test_package, project=/workarea/test_repo/test_package, normalizedKey=/workarea/test_repo/test_package, env=defaultInterpreterPath:/usr/bin/python3.11
2026-04-28 09:49:57.964 [info] [interpreterSelection] test_package: defaultInterpreterPath: 3.11.15.final.0 (source: defaultInterpreterPath)
2026-04-28 09:49:57.966 [info] Python API: Changed environment from undefined to defaultInterpreterPath: 3.11.15.final.0 for: /workarea/test_repo/test_package
2026-04-28 09:49:57.967 [info] Internal: Changed environment from undefined to defaultInterpreterPath: 3.11.15.final.0 for: /workarea/test_repo/test_package
2026-04-28 09:49:57.977 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.987 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:57.997 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:58.006 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:58.016 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:58.026 [info] Resolved Python Environment /usr/bin/python3.11
2026-04-28 09:49:58.201 [info] [interpreterSelection] global: defaultInterpreterPath: 3.11.15.final.0 (source: defaultInterpreterPath)
2026-04-28 09:49:58.222 [info] Environment discovery complete: 3 environments found (Global: 3)
2026-04-28 09:49:58.223 [info] Python API: Changed environment from undefined to defaultInterpreterPath: 3.11.15.final.0 for: global
2026-04-28 09:49:58.223 [info] Internal: Changed environment from undefined to defaultInterpreterPath: 3.11.15.final.0 for: global
2026-04-28 09:49:58.224 [info] Python API: Changed environment from defaultInterpreterPath: 3.11.15.final.0 to Python 3.14.4 for: /workarea/test_repo/test_package
2026-04-28 09:49:58.224 [info] Internal: Changed environment from defaultInterpreterPath: 3.11.15.final.0 to Python 3.14.4 for: /workarea/test_repo/test_package
... sometime later ...
2026-04-28 09:50:03.045 [info] Python API: Changed environment from defaultInterpreterPath: 3.11.15.final.0 to Python 3.14.4 for: global
2026-04-28 09:50:03.045 [info] Internal: Changed environment from defaultInterpreterPath: 3.11.15.final.0 to Python 3.14.4 for: global

Additional context

The startup flow doc is correct, when picking a manager we are using priority P3 in this case, selecting the right environment in applyInitialEnvironmentSelection() and not calling get().

However a few lines later in extension.ts we call sendProjectStructureTelemetry(...) which triggers the get() on the environment managers, uses the fast path logic and updates to the latest Python version (it does this to count the available number of interpreters but has a side effect now since get() was never called initially).

I think the best fix is to make the environment managers' get() safe to call in applyInitialEnvironmentSelection() otherwise this is likely to come back when a later feature ever needs to call get() again for any reason. I'm happy to contribute a suggested fix for this if it's helpful. Or let me know if you want to fix it a different way!

Thanks

[eleanorjboyd]

fantastic find! required some reworking so the getter method didn't update the cache unexpectedly. Ill wrap up the PR and let you know when you can try it on insiders!