Environment data
- Python Environments extension version: 1.20.1
- Python extension (
ms-python.python) version: 2026.4.0
- VS Code version (Help -> About):
1.108.0 (user setup)
- VS Code commit:
94e8ae2b28cb5cc932b86e1070569c4463565c37
- VS Code 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 and version: Windows_NT x64 10.0.19044
- Python version (& distribution if applicable, e.g. Anaconda): CPython 3.11.13
- Environment manager in use (
venv / conda / pyenv / poetry / pipenv / system / uv / other): uv
- Shell (bash / zsh / fish / pwsh / cmd / other):
pwsh
- Remote / container scenario (none / WSL / SSH Remote / Dev Container / Codespaces): none
- Workspace type (single folder / multi-root / mono-repo): single folder
- Is this a regression? If yes, last known working extension version: likely related to earlier
${workspaceFolder} resolution regressions, but I do not have a confirmed last known good version
Repro Steps
-
Create a Windows workspace with a local virtual environment, for example:
D:\Dev\AlexM\Workspace\Python\forum-crawler\
.vscode\
settings.json
.venv\
Scripts\
python.exe
pyproject.toml
uv.lock
-
Put the following in the workspace .vscode/settings.json:
{
"python.defaultInterpreterPath": "${workspaceFolder}\\.venv\\Scripts\\python.exe",
"python.terminal.activateEnvironment": true
}
-
Make sure the interpreter file actually exists at:
D:\Dev\AlexM\Workspace\Python\forum-crawler\.venv\Scripts\python.exe
-
Open the folder in VS Code and reload the window.
-
Observe that a startup warning appears saying that the default interpreter path could not be resolved.
-
Open Settings UI and search for python.defaultInterpreterPath.
-
Confirm that:
- the User tab shows the user-level value
- the Workspace tab shows the workspace override
- the Workspace tab displays the exact configured value:
${workspaceFolder}\.venv\Scripts\python.exe
-
Replace the workspace setting with the equivalent absolute path:
{
"python.defaultInterpreterPath": "D:\\Dev\\AlexM\\Workspace\\Python\\forum-crawler\\.venv\\Scripts\\python.exe",
"python.terminal.activateEnvironment": true
}
-
Reload the window again.
-
Observe that the warning disappears immediately.
Expected behavior
If python.defaultInterpreterPath is configured at workspace scope as:
"${workspaceFolder}\\.venv\\Scripts\\python.exe"
and the interpreter file exists, the path should resolve successfully and no warning should be shown.
The workspace-relative form should behave the same as the equivalent absolute path.
Actual behavior
On startup, VS Code shows a warning equivalent to:
Default interpreter path '${workspaceFolder}\.venv\Scripts\python.exe' could not be resolved:
Could not resolve interpreter path '${workspaceFolder}\.venv\Scripts\python.exe'
Important detail:
- the workspace setting is clearly present and visible in the Workspace settings UI
- the target interpreter file exists
- the error message still contains the literal
${workspaceFolder} token instead of an expanded absolute path
- replacing the exact same value with an absolute path removes the warning immediately
This makes it look like the workspace setting is being read correctly, but ${workspaceFolder} is not being expanded in at least one interpreter resolution path.
After reviewing the logs, there also seems to be a second symptom: in addition to the unexpanded variable case, at least one code path constructs a malformed interpreter path by duplicating the workspace folder name before .venv\Scripts\python.exe.
Logs
Excerpts from the "Python Environments" output:
2026-06-17T01:18:44.510+08:00 [info] Discovered env: D:\Dev\AlexM\Workspace\Python\forum-crawler\.venv\Scripts\python.exe
2026-06-17T01:18:45.757+08:00 [error] [pet] Failed to execute Python to resolve info "D:\Dev\AlexM\Workspace\Python\forum-crawler\forum-crawler\.venv\Scripts\python.exe": The system cannot find the path specified. (os error 3)
2026-06-17T01:18:45.758+08:00 [warning] [priorityChain] D:\Dev\AlexM\Workspace\Python\forum-crawler defaultInterpreterPath '${workspaceFolder}\forum-crawler\.venv\Scripts\python.exe' unresolvable, falling back to auto-discovery
2026-06-17T01:18:45.830+08:00 [info] Resolved Python Environment C:\Users\AlexM\AppData\Roaming\uv\python\cpython-3.11.13-windows-x86_64-none\python.exe
2026-06-17T01:18:45.850+08:00 [info] [interpreterSelection] forum-crawler: forum-crawler (3.11.13) (source: autoDiscovery)
2026-06-17T01:18:45.873+08:00 [error] [pet] Failed to execute Python to resolve info "C:\Users\AlexM\AppData\Local\Programs\VSCode\${workspaceFolder}\forum-crawler\.venv\Scripts\python.exe": The system cannot find the path specified. (os error 3)
2026-06-17T01:18:45.874+08:00 [warning] [priorityChain:global] defaultInterpreterPath '${workspaceFolder}\forum-crawler\.venv\Scripts\python.exe' unresolvable, falling back to auto-discovery
Excerpts from the "Python" output:
2026-06-17T01:18:39.801+08:00 [info] Python interpreter path: .\.venv\Scripts\python.exe
2026-06-17T01:18:44.835+08:00 [warning] Identifier for virt-virtualenv failed to identify D:\Dev\AlexM\Workspace\Python\forum-crawler\forum-crawler\.venv\Scripts\python.exe [Error: ENOENT: no such file or directory, scandir 'D:\Dev\AlexM\Workspace\Python\forum-crawler\forum-crawler\.venv\Scripts']
2026-06-17T01:18:44.896+08:00 [info] > .\forum-crawler\.venv\Scripts\python.exe -I C:\Users\AlexM\.vscode\extensions\ms-python.python-2026.4.0-win32-x64\python_files\get_output_via_markers.py C:\Users\AlexM\.vscode\extensions\ms-python.python-2026.4.0-win32-x64\python_files\interpreterInfo.py
2026-06-17T01:18:45.000+08:00 [error] Command failed: D:\Dev\AlexM\Workspace\Python\forum-crawler\forum-crawler\.venv\Scripts\python.exe ...
2026-06-17T01:18:45.054+08:00 [info] > .\.venv\Scripts\python.exe -I C:\Users\AlexM\.vscode\extensions\ms-python.python-2026.4.0-win32-x64\python_files\get_output_via_markers.py C:\Users\AlexM\.vscode\extensions\ms-python.python-2026.4.0-win32-x64\python_files\interpreterInfo.py
These logs suggest two closely related problems:
1. `${workspaceFolder}` is not expanded in at least one resolution path.
2. Another path appears to incorrectly append the workspace folder name again, producing `...\forum-crawler\forum-crawler\.venv\Scripts\python.exe` instead of `...\forum-crawler\.venv\Scripts\python.exe`.
Despite the warning, the correct interpreter is still discovered and selected later through auto-discovery.
Additional context
-
This does not appear to be a missing-Python or missing-interpreter problem. The interpreter exists and is executable.
-
This also does not appear to be a case where workspace settings are ignored. The Workspace settings UI shows the workspace override correctly.
-
The most important signal is that the warning message still contains the literal ${workspaceFolder} token. That suggests the setting is read, but variable expansion fails in at least one path.
-
The logs add another important signal: the extension first discovers the correct local interpreter, but later tries to resolve a malformed path with a duplicated workspace segment, e.g. ...\forum-crawler\forum-crawler\.venv\Scripts\python.exe.
-
In other words, this no longer looks like only a warning-message bug. It looks like an actual path composition / resolution bug, followed by fallback to auto-discovery.
-
Current workaround:
{
"python.defaultInterpreterPath": "D:\\Dev\\AlexM\\Workspace\\Python\\forum-crawler\\.venv\\Scripts\\python.exe"
}
This works, but it defeats the portability benefits of ${workspaceFolder} in checked-in workspace settings.
-
This seems related to earlier ${workspaceFolder} / defaultInterpreterPath issues, but I am filing this as a fresh report because the behavior is still reproducible and the previous discussion was closed.
-
VS Code About information used for this report:
- Version:
1.108.0 (user setup)
- 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:
Windows_NT x64 10.0.19044
Environment data
ms-python.python) version: 2026.4.01.108.0 (user setup)94e8ae2b28cb5cc932b86e1070569c4463565c372026-01-08T13:53:10.781Z39.2.712953945142.0.7444.23522.21.114.2.231.21-electron.0venv/conda/pyenv/poetry/pipenv/system/uv/ other):uvpwsh${workspaceFolder}resolution regressions, but I do not have a confirmed last known good versionRepro Steps
Create a Windows workspace with a local virtual environment, for example:
Put the following in the workspace
.vscode/settings.json:{ "python.defaultInterpreterPath": "${workspaceFolder}\\.venv\\Scripts\\python.exe", "python.terminal.activateEnvironment": true }Make sure the interpreter file actually exists at:
Open the folder in VS Code and reload the window.
Observe that a startup warning appears saying that the default interpreter path could not be resolved.
Open Settings UI and search for
python.defaultInterpreterPath.Confirm that:
Replace the workspace setting with the equivalent absolute path:
{ "python.defaultInterpreterPath": "D:\\Dev\\AlexM\\Workspace\\Python\\forum-crawler\\.venv\\Scripts\\python.exe", "python.terminal.activateEnvironment": true }Reload the window again.
Observe that the warning disappears immediately.
Expected behavior
If
python.defaultInterpreterPathis configured at workspace scope as:"${workspaceFolder}\\.venv\\Scripts\\python.exe"and the interpreter file exists, the path should resolve successfully and no warning should be shown.
The workspace-relative form should behave the same as the equivalent absolute path.
Actual behavior
On startup, VS Code shows a warning equivalent to:
Important detail:
${workspaceFolder}token instead of an expanded absolute pathThis makes it look like the workspace setting is being read correctly, but
${workspaceFolder}is not being expanded in at least one interpreter resolution path.After reviewing the logs, there also seems to be a second symptom: in addition to the unexpanded variable case, at least one code path constructs a malformed interpreter path by duplicating the workspace folder name before
.venv\Scripts\python.exe.Logs
Additional context
This does not appear to be a missing-Python or missing-interpreter problem. The interpreter exists and is executable.
This also does not appear to be a case where workspace settings are ignored. The Workspace settings UI shows the workspace override correctly.
The most important signal is that the warning message still contains the literal
${workspaceFolder}token. That suggests the setting is read, but variable expansion fails in at least one path.The logs add another important signal: the extension first discovers the correct local interpreter, but later tries to resolve a malformed path with a duplicated workspace segment, e.g.
...\forum-crawler\forum-crawler\.venv\Scripts\python.exe.In other words, this no longer looks like only a warning-message bug. It looks like an actual path composition / resolution bug, followed by fallback to auto-discovery.
Current workaround:
{ "python.defaultInterpreterPath": "D:\\Dev\\AlexM\\Workspace\\Python\\forum-crawler\\.venv\\Scripts\\python.exe" }This works, but it defeats the portability benefits of
${workspaceFolder}in checked-in workspace settings.This seems related to earlier
${workspaceFolder}/defaultInterpreterPathissues, but I am filing this as a fresh report because the behavior is still reproducible and the previous discussion was closed.VS Code About information used for this report:
1.108.0 (user setup)94e8ae2b28cb5cc932b86e1070569c4463565c372026-01-08T13:53:10.781Z39.2.712953945142.0.7444.23522.21.114.2.231.21-electron.0Windows_NT x64 10.0.19044