Repository navigation
Conda/Miniforge environments not detected as Jupyter kernels in VSCode (2025.x extension versions) #25554
Description
Conda/Miniforge environments not detected as Jupyter kernels in VSCode (2025.x extension versions)
Environment Data
- VS Code Version: 1.105.1
- OS Version: macOS (Darwin arm64)
- Python Extension Version: 2025.17.2025101701 (broken), rolled back to 2024.16.0 (working)
- Jupyter Extension Version: 2025.9.1 (broken), rolled back to 2024.9.1 (working)
- Python Environment Manager Extension Version: 1.11.13001538
- Python Distribution: Miniforge3
- Python Version: 3.x (multiple environments)
Expected Behavior
When opening a Jupyter notebook in VSCode and selecting a kernel, all conda environments with ipykernel installed should appear in the kernel selection menu, as they did in previous versions of the extensions.
Actual Behavior
With Python extension v2025.x and Jupyter extension v2025.x, conda environments are not detected as available kernels. Only system Python interpreters appear in the kernel selection menu, despite having multiple conda environments properly configured with ipykernel installed.
Error Logs
The Jupyter output panel shows the following errors:
20:23:57.148 [warn] No interpreter with path ~/miniforge3/bin/python found in Python API, will convert Uri path to string as Id ~/miniforge3/bin/python
20:23:57.149 [warn] No interpreter with path ~/miniforge3/envs/ncil/bin/python found in Python API, will convert Uri path to string as Id ~/miniforge3/envs/ncil/bin/python
20:24:00.398 [warn] Failed to get Python interpreter details from Python Extension API for ~/miniforge3/envs/ncil/bin/python Error: Failed to run "conda info --envs --json":
/bin/sh: ~/miniforge3/bin: is a directory
20:24:00.400 [warn] Kernel Spec for 'Python (ncil)' (~/Library/Jupyter/kernels/ncil/kernel.json) hidden, as we cannot find a matching interpreter argv = '~/miniforge3/envs/ncil/bin/python'. To resolve this, please change '~/miniforge3/envs/ncil/bin/python' to point to the fully qualified Python executable.
Steps to Reproduce
- Install Miniforge3 on macOS (ARM64)
- Create conda environments with
ipykernelinstalled:conda create -n test_env python=3.10 conda activate test_env conda install ipykernel
- Register the kernel (though this shouldn't be necessary with
nb_conda_kernels):python -m ipykernel install --user --name test_env --display-name "Python (test_env)" - Open VSCode with latest Python (2025.x) and Jupyter (2025.x) extensions
- Open a Jupyter notebook
- Attempt to select kernel - conda environments will not appear
Attempted Solutions That Failed
-
Updated settings.json with full paths (no tildes):
{ "python.condaPath": "/Users/username/miniforge3/bin/conda", "python.defaultInterpreterPath": "/Users/username/miniforge3/bin/python", "jupyter.kernels.trusted": ["/Users/username/miniforge3/envs/*/bin/python"] } -
Manually registered kernels using
ipykernel installwith full paths -
Verified kernel.json files contain full paths without tildes:
{ "argv": [ "/Users/username/miniforge3/envs/ncil/bin/python", "-m", "ipykernel_launcher", "-f", "{connection_file}" ] } -
Installed
nb_conda_kernelsin base environment (should auto-detect all conda envs) -
Cleared all VSCode caches:
rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage/ rm -rf ~/Library/Application\ Support/Code/User/globalStorage/ms-python.python/ rm -rf ~/Library/Application\ Support/Code/User/globalStorage/ms-toolsai.jupyter/
Root Cause Analysis
The issue appears to be related to tilde (~) path expansion. Despite having full paths in all configuration files, the VSCode extensions internally attempt to use paths with tildes (as seen in the error logs), which fail to resolve properly. The error message shows the extension is looking for ~/miniforge3/bin/python instead of /Users/username/miniforge3/bin/python.
The extensions seem to be caching these tilde paths internally and not properly expanding them, even when all user-facing configuration uses full absolute paths.
Solution/Workaround
Rolling back to earlier versions resolves the issue completely:
- Rollback Jupyter extension to v2024.9.1
- Rollback Python extension to v2024.16.0
- Reload VSCode
After rollback, all conda environments immediately appear in the kernel selection menu without any additional configuration needed.
Impact
This bug severely impacts data science workflows for users who:
- Use conda/mamba/miniforge for environment management
- Work with Jupyter notebooks in VSCode
- Have upgraded to the latest extension versions
This is a regression from previous versions where conda environment detection worked automatically and reliably.
Suggested Fix
- Fix tilde path expansion in the interpreter detection logic
- Ensure the extensions properly expand
~to the user's home directory before attempting to access files - Add test coverage for conda environments with paths containing tildes
- Consider reverting whatever change was made between v2024.16.0 (Python) / v2024.9.1 (Jupyter) and the 2025.x versions that broke this functionality
Related Issues
This may be related to other reported issues with interpreter detection on macOS, particularly for conda/miniforge installations.
Additional Context
- The issue affects Miniforge3 installations on macOS ARM64 (Apple Silicon)
nb_conda_kernelspackage is installed but not being recognized by the 2025.x extensions- The same setup works perfectly with the September/October 2024 versions of the extensions
- This appears to be a regression introduced in the 2025.x versions
Reproducibility
This issue is 100% reproducible on the affected setup and is immediately resolved by rolling back to the specified earlier versions.
Activity
DonJayamanne commentedon Nov 1, 2025
Please can you verify that all you need to do is roll back python extension(s)
The Jupyter extension doesn’t find Python envs, I want to isolate the issue to being a problem with Python extension(s),
I am fairly certain that’s the case, but would like a confirmation
aaronjnewman commentedon Nov 1, 2025
Confirmed. I updated the Jupyter extension to the current
2025.9.1 version, while leaving the Python extension at 2024.16.0, and VS Code was still able to find all my kernels including Conda environments. Updating the Python extension to
2025.17.2025101701 breaks this functionality and only lists system Python environments.
eleanorjboyd commentedon Nov 6, 2025
Not able to repro myself but Ill keep investigating:
if you see this in the meantime and could run
Python: Run Python Environment Tool (PET) in Terminal...and selectfindthat would be useful to see what our locator binary is returninganother item to try is if you put the following in your settings, does it work?
python.useEnvironmentsExtension: false?aaronjnewman commentedon Nov 6, 2025
Thanks for looking into this. To test, I did the following:
I tried adding
python.useEnvironmentsExtension: falseto settings.json but this had no effect on the issue.Output of
/Users/aaron/.vscode/extensions/ms-python.vscode-python-envs-1.11.13081013-darwin-arm64/python-env-tools/bin/pet" find --verboseiseleanorjboyd commentedon Nov 6, 2025
great info- I can see these paths which you want to use are located!
The question now is why is the search to find the path not successful. I think your hypothesis is a great one and will investigate it on my end. For the range of versions which have this change, you said it worked on Python extension
v2024.16.0but not onv2025.17.xcould you try maybev2024.18.0or other versions in between and see if that makes a difference?Meanwhile I will work on my end to find where that path is getting surfaced but am facing some difficulties since I can't reproduce the problem on my end.
aaronjnewman commentedon Nov 6, 2025
Version 2024.22.2 of the Python extension found my conda environments successfully. Version 2025.0.0 did not. So the issue seems to have arisen with 2025.0.0
HOWEVER, it occurred to me that since you can't reproduce this, it may have stemmed form my miniforge/conda installation.
So I downloaded and installed the latest version of miniforge and re-created my conda envs with that. Now the Python extension in VS Code finds my conda environments. So it appears that the issue was an incompatibility between older versions of miniforge/conda and newer versions of the extension.
Sorry to bother you with this, but perhaps this issue will be helpful to anyone else who encounters this issue.
aaronjnewman commentedon Nov 17, 2025
Actually, the issue has recurred. I didn't change anything in my conda configuration, other than adding a second conda environment. So perhaps the problem only occurs when there is more than one conda environment available.
So, same issue as above - conda envs are not seen, in versions:
But envs are detected properly in version 2024.22.2 and earlier
kirillbobylev commentedon Nov 28, 2025
same here, downgraded python to 2024.16.0 and fixed it. 2024.22.2 didnt worked
dmnq-f commentedon Dec 12, 2025
Can confirm this on a Windows installation without conda (using uv, but also one official Python package present via Windows store). Completely broke Python debugging and invocation functionality (even with defaultInterpreterPath set manually).
Yes, same here. 2024.16.0 is the last version that gets me a working Python extension.
And no,
python.useEnvironmentsExtensiondid not help.LeiZhang-116-4 commentedon Dec 26, 2025
One downside of rolling back to Python extension v2024.16.0 is that the latest Pylance becomes incompatible as well. In practice, that forces a choice between (1) a working Python/Jupyter environment setup and (2) up-to-date IntelliSense/type hints. That’s not a viable long-term workaround.
I hope there is either a fix for the regression, or provide a supported configuration/workaround for users in this situation? I’ve tried setting
python.useEnvironmentsExtension: true, but it didn’t help.hamogu commentedon Jul 25, 2026
Same problem, currently with Python extension version 2026.5.2026070801
As in the original issue, the problem appeared after an update. I haven't tried rolling back. My workaround is to give the full path to the interpreter for every notebook I'm using.
Select a kernel -> select another kernel -> Python environments -> Create Python environments -> Enter Interpreter path.
That's 5 mouse clicks to get there and then a few more to navigate the GUI to the python interpreter in the appropriate environment directory. Possible, but not comfortable. I'm using Jupiter notebooks mostly through Jupyter directly in by browser again instead of using VSCode.
jtomfarrar commentedon Jul 28, 2026
I've been having the same issue for a couple of months. I rolled back to Python extension v2026.2.0 (from 5 months ago) and had the same problem. I rolled back to Python extension v2024.16.0 (a two-year old version!), and all environments are properly discovered. (I was previously giving the full path to the environment, but that is too cumbersome.)
0x10jalencas commentedon Aug 3, 2026
I'm writing to confirm this on Windows w/ Miniconda (not Miniforge), different OS/env-manager combo than what's been reported so far, so may help narrow down whether this is conda-specific or broader.
Versions: VS Code 1.101.2, Jupyter Extension 2025.7.0, Python Extension 2026.4.0, Python Environment Extension 1.2.0, Pylance 2025.10.2
Logs (similar to OP):
Confirmed the kernel.json (as to the OP) already contained the fully-qualified path (w/ no tilde). Editing it to be explicit had no effect, ruling out the config-side tilde.
New workaround (that works for me): fully disabling the "Python Environment" extension (not just setting
python.useEnvironmentsExtension: false, which per other comments here doesn't help) immediately surfaced the conda env in the kernel picker again, with no version rollback needed. Might be worth testing as an alternative to the 2024.16.0 downgrade, since it avoids losing current Pylance compatibility.ninjit commentedon Sep 23, 2026
Thank you 0x10jalencas!
I can confirm that disabling the "Python Environment" extension fixed this issue for me too
jtomfarrar commentedon Sep 24, 2026
The workaround from 0x10jalencas (disable the "Python Environments" extension) seems much better, and I confirm it seems to resolve the issue for me too!
(When I disabled the "Python Environments" extension, I noticed that it requires version 2024.23 or later of the Python extension, so I speculate that rolling back to v2024.16.0 of the Python extension only worked because it had the effect of disabling the Python Environments extension.)