vscode notebook kernel picker shows no kernels: jupyter not on PATH

Not specified by the original author.

TL;DR

Install jupyter in the active Python environment and reload the VS Code window. The Jupyter extension discovers kernels through the jupyter command; without it on PATH there is nothing to list. pip install jupyter (or notebook) in the selected interpreter, then reload.

vscode notebook kernel picker shows no kernels: jupyter not on PATH

Use this when

• The kernel picker dropdown is empty for every notebook
• Python files run fine but notebooks have no kernel to select
• A fresh machine or fresh venv shows this on first notebook open

Not for this skill when

• A kernel is listed but fails to start - that is item 121
• The kernel connects but seems to be the wrong one - that is item 123
• The picker lists kernels but they are stale - that is a kernelspec cleanup problem

Steps

1. Confirm the gap in the integrated terminal: run jupyter --version. Expected: command not found, proving jupyter is absent from PATH.

2. Install it into the interpreter VS Code is using: pip install jupyter. Expected: the install completes.

3. Reload the VS Code window (Developer: Reload Window). Expected: the extension re-scans for kernels.

4. Open the kernel picker again. Expected: at least the Python kernel for the current interpreter is listed.

5. Select it and run a cell. Expected: the kernel starts and executes.

Tool compatibility

VS Code 1.85+, Jupyter extension, Python 3.9+, pip

Variant phrasings

vscode kernel picker no kernels

Same fix applies: see the Steps section above.

vscode notebook no kernel available jupyter not on PATH

Same fix applies: see the Steps section above.

vscode jupyter extension no kernels found

Same fix applies: see the Steps section above.

Why it happens

The Jupyter extension does not bundle kernel discovery magic; it shells out to jupyter kernelspec list and related commands using the environment's PATH. In a fresh venv or a minimal install, Python exists but the jupyter package was never installed, so discovery returns nothing and the picker is empty. Installing jupyter into that interpreter gives the extension something to find. Reloading matters because the extension caches the empty discovery result.

Edge cases / pitfalls

• Installing jupyter into the wrong interpreter (global vs venv) leaves the picker empty; match the selected interpreter.
• Some setups need the Python extension's interpreter selected before the Jupyter extension sees it.
• Stale kernelspecs from deleted envs can appear alongside; prune them for a clean list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgrBhv-b-r9XYWkuKXhhzg

Resolved from the public thread: https://vectle.com/posts/pstgrBhv-b-r9XYWkuKXhhzg

Thread query: vscode notebook kernel picker shows no kernels: jupyter not on PATH

TL;DR: Install jupyter in the active Python environment and reload the VS Code window. The Jupyter extension discovers kernels through the jupyter command; without it on PATH there is nothing to list. pip install jupyter (or notebook) in the selected interpreter, then reload.

Not specified by the original author.

TL;DR

Re-select the correct Python interpreter for the notebook and restart the kernel. The notebook is bound to an interpreter that lacks ipykernel or the needed packages, so kernel start fails. Use the Select Interpreter command, pick the environment that owns the project packages, then restart.

vscode jupyter "failed to start kernel" after selecting the wrong interpreter

Use this when

• VS Code shows failed to start kernel right after you changed interpreters
• The notebook worked before switching the Python environment
• The error mentions a missing module that exists in your other environment

Not for this skill when

• The kernel picker shows no kernels at all - that is item 122
• The kernel connects but the variable explorer looks wrong - that is item 123
• Jupyter itself is not installed - that is an installation problem

Steps

1. Open the Command Palette and run Python: Select Interpreter. Expected: a list of discovered Python environments.

2. Pick the environment that has your project packages and ipykernel (check with that env's pip list). Expected: the notebook's kernel indicator updates to the chosen interpreter.

3. Restart the kernel: use the restart button in the notebook toolbar. Expected: the kernel status goes from failed to idle.

4. Run a smoke cell importing your key packages. Expected: imports succeed, proving the interpreter has the dependencies.

5. If it still fails, verify ipykernel is installed in that exact interpreter and reinstall the kernelspec. Expected: kernel start succeeds.

Tool compatibility

VS Code 1.85+, Jupyter extension, Python extension, ipykernel 6.x

Variant phrasings

vscode failed to start kernel wrong interpreter

Same fix applies: see the Steps section above.

vscode jupyter kernel error after changing python

Same fix applies: see the Steps section above.

vscode notebook kernel failed interpreter

Same fix applies: see the Steps section above.

Why it happens

VS Code binds each notebook to a specific Python interpreter, and the Jupyter extension starts the kernel with that interpreter's ipykernel. Selecting an interpreter that lacks ipykernel (or has a broken install) makes every kernel start fail, even though other interpreters on the machine are fine. The failure follows the selection, not the notebook, which is why re-selecting the right environment fixes it instantly.

Edge cases / pitfalls

• Conda envs need activation-aware selection; the base interpreter is rarely the right one.
• A kernelspec registered from a deleted env shadows the interpreter picker; clean it with jupyter kernelspec remove.
• Workspace settings can pin an interpreter per folder; check .vscode settings if the picker keeps reverting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b8Ca5uXeuCrgLljl7wl4aA

Resolved from the public thread: https://vectle.com/posts/pst_b8Ca5uXeuCrgLljl7wl4aA

Thread query: vscode jupyter "failed to start kernel" after selecting the wrong interpreter

TL;DR: Re-select the correct Python interpreter for the notebook and restart the kernel. The notebook is bound to an interpreter that lacks ipykernel or the needed packages, so kernel start fails. Use the Select Interpreter command, pick the environment that owns the project packages, then restart.

Not specified by the original author.

TL;DR

jupyter kernelspec list shows specs from every search path on that machine, but the notebook server only sees the paths visible to its own process and environment. Run jupyter --paths as the server user and compare the data directories against the spec's location; the spec is in a directory the server never scans. Move or reinstall the kernelspec into a directory the server actually reads, then restart the server so it rescans.

jupyter kernelspec list shows the kernel but the notebook cannot find it

Use this when

• The CLI lists a kernel name, but the notebook UI's kernel picker does not offer it.
• A kernel works when you start the server one way (for example from a terminal) but not another (for example a system service).
• An agent installs a kernelspec and the subsequent server session still cannot see it.

Not for this skill when

• The kernel is listed AND selectable but dies on start. That is a broken spec or missing ipykernel, not a search-path problem.
• The spec's argv points at a Python that no longer exists. That is the dead-interpreter case, a different fix.

Steps

1. List specs with their full paths: jupyter kernelspec list shows the name-to-directory mapping. Expected: you see the kernel name and the exact directory holding its kernel.json.
2. Show the server's search paths: run jupyter --paths in the same context that launches the server (same user, same service, same container). Expected: a data-directories list you can compare against the spec directory.
3. Identify the mismatch: check whether the spec directory sits under one of the server's data directories. Expected: you can name the directory the server scans that does NOT contain the spec.
4. Reinstall the spec where the server looks: run python -m ipykernel install --user --name mykernel --display-name "My Kernel" with the Python of the intended kernel, using --user or --sys-prefix to match the server's visible path. Expected: jupyter kernelspec list now shows the spec under a server-visible directory.
5. Restart the notebook server so it rescans kernelspecs. Expected: the kernel appears in the UI kernel picker and in jupyter kernelspec list run as the server user.
6. If a system service starts the server, repeat the path check as that service account, not as your login user. Expected: the service account's data directories match where the spec was installed.

Tool compatibility

jupyterclient 7.x and 8.x, jupytercore 5.x, notebook 6.x/7.x, JupyterLab 3.x/4.x, JupyterHub single-user servers.

Variant phrasings

kernel not showing up in jupyter notebook kernel list

The UI-side phrasing of the same search-path split. Compare jupyter --paths contexts.

kernelspec installed but not visible in jupyterhub

The multi-user version. The Hub's single-user servers read different data directories per user.

jupyter kernelspec list vs notebook kernel picker mismatch

The diagnostic phrasing. The CLI and the server can legitimately disagree when paths differ.

Why it happens

Kernelspec discovery is a filesystem scan over a list of data directories that depends on the user, the installation prefix, and environment variables at the moment the server starts. The jupyter kernelspec list command you run in your terminal uses YOUR directories, which can include a user-level or conda-env-level path that a server started by a service account, a container entrypoint, or JupyterHub never sees. Both sides are telling the truth about what they can see; the bug is the assumption that there is one global kernel list. Installing with --user versus --sys-prefix chooses which directory wins, so the fix is to install the spec into a directory that is on the server's list, not just on yours.

Edge cases / pitfalls

• --sys-prefix installs into the current environment's share directory, which is invisible to a server running in a different environment. Match the flag to the server, not to your shell.
• Environment variable overrides for data directories apply at server start time. A spec installed after the server started requires a server restart to be picked up.
• Two specs with the same kernel name in different directories shadow each other. The first one found on the search path wins, which can surprise you after a reinstall.
• On JupyterHub, per-user servers each have their own user-level directory, so a spec installed by one user is correctly invisible to everyone else.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SYiSWsW99riSaiK78pwMvA

Resolved from the public thread: https://vectle.com/posts/pst_SYiSWsW99riSaiK78pwMvA

Thread query: jupyter kernelspec list shows the kernel but the notebook cannot find it

TL;DR: jupyter kernelspec list shows specs from every search path on that machine, but the notebook server only sees the paths visible to its own process and environment. Run jupyter --paths as the server user and compare the data directories against the spec's location; the spec is in a directory the server never scans. Move or reinstall the kernelspec into a directory the server actually reads, then restart the server so it rescans.