incorrectly saved pythonLocator setting on remote settings

[eleanorjboyd]

issue posted on: https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-python-envs&ssr=false#review-details from user Shunliang Zhang.

---

"I want to auto source the .venv in the root directory of my program. But it identify and source the wrong path. And I didn't find any method to correct the path. Finally found it in .vscode-server/data/User/globalStorage/ms-python.vscode-python-envs/pythonLocator. It works after delete the wrong path manually in the json."

[eleanorjboyd]

Triage Notes

What's happening: The native Python finder caches discovered environment paths in globalStorage/ms-python.vscode-python-envs/pythonLocator/. When a .venv path changes or becomes stale, the cached (wrong) path persists and gets used instead of re-discovering.

Relevant code:

• src/managers/common/nativePythonFinder.ts — getCacheDirectory() (line 1409) sets the cache path, and the native tool reads/writes cached results there via --cache-directory.

Workaround: We already have a user-facing command "Python Environments: Clear Cache" (python-envs.clearCache) in the command palette that calls clearCacheDirectory() and clears all manager caches. The user could have used this instead of manually editing the JSON.

Potential improvements:

1. Discoverability — The "Clear Cache" command exists but isn't obvious to users hitting this problem. Consider surfacing it in error scenarios or documenting it more prominently.
2. Cache invalidation — The cache could be smarter about detecting when a workspace .venv no longer exists at the cached path and automatically invalidating stale entries.
3. Cache staleness check — Add a file-existence check before using a cached .venv path.

[eleanorjboyd]

The caching and validation happens entirely inside the PET (Python Environment Tools) native binary — not in our TypeScript code. We pass --cache-directory to PET and trust whatever it returns. Our code at line 243 only checks that prefix, executable, and version are present — but does not verify the executable actually exists on disk.

cc @karthiknadig is this a change we can make on PET to fix this? So we do a check for an executable actually existing before returning it from cache?