Repository navigation
Workspace virtual environment interpreter cannot be used for files outside workspace #1099
Description
Version
Extension: 1.16.0
vscode:
Version: 1.108.0
Commit: 94e8ae2b28cb5cc932b86e1070569c4463565c37
Date: 2026-01-08T13:53:10.781Z
Electron: 39.2.7
ElectronBuildId: 12953945
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Linux x64 6.14.0-37-generic (Ubuntu 24.04)
Description
When opening a Python file outside of the current workspace folder, VS Code assigns it the system/default Python interpreter, even though a workspace-specific virtual environment is already selected and remains correctly applied to all files within the workspace. The workspace interpreter cannot be selected for the external file due to a conflicting state message.
Uninstalling the python extension fixed the problem.
Steps to Reproduce
- Open VS Code with a workspace folder.
- Select a workspace-specific Python virtual environment.
- Verify that Python files inside the workspace use the selected interpreter.
- Open a Python file located outside the workspace folder tree.
- Observe that the external file is assigned the system/default Python interpreter.
- Attempt to select the workspace virtual environment for the external file.
Actual Behavior
- Python files inside the workspace continue to use the correct interpreter.
- The Python file outside the workspace uses the system/default interpreter.
- Attempting to select the workspace virtual environment for the external file results in the message:
"<workspace-venv> (<python version>)" is already selected as the environment for: "<workspace>"
- As a result, the external file cannot be associated with the workspace virtual environment, even though it is not currently using it.
Expected Behavior
External Python files should be able to explicitly use the active workspace interpreter.
Reacted by br-muller and J Tan
Activity
[-]Conflict between workspace venv and new file in different folder[/-][+]Workspace virtual environment interpreter cannot be used for files outside workspace[/+]Add GitHub issue templates (Bug Report, Feature Request, Question) (#…
Add GitHub issue templates (Bug Report, Feature Request, Question) (m…
eleanorjboyd commentedon May 1, 2026
Thanks for the detailed report. Two questions to confirm we're on the same page on latest:
1.28.xor1.29.xpre-release? We've made several changes to per-resource environment selection since1.16.0.If still reproducing, please attach the
Python Environmentsoutput channel at debug level when you trigger the picker for the external file.rabyj commentedon May 1, 2026
I can't reproduce the original behavior in 1.28.x.
Instead, the python seems stuck to the workspace venv python. Whatever virtual environment I try to select via the bar, what's displayed doesn't change, even if internally it says it changed something. I didn't research if this was a known bug already, since it seems out of scope for this issue.
I'm going to share the startup and venv selection logs for completeness, but I'm closing this issue.
Startup log
Note: $HOME path was replaced for partial anonymization.
venv selection (via lower-right icon)
Here, I alternated between global/system python and default workspace venv.
eleanorjboyd commentedon May 1, 2026
do you have any settings in user or workspace that say "python-envs.defaultEnvManager": "ms-python.python:venv"
rabyj commentedon May 1, 2026
Yes that exact setting seems to be set for both.