kernelspec json references a python that no longer exists

Not specified by the original author.

TL;DR

The kernel.json hard-codes the absolute path of the Python that registered it, so deleting or renaming that environment leaves a spec pointing at nothing and the kernel fails to launch. Inspect the spec's argv with jupyter kernelspec list plus a read of kernel.json, then reinstall the spec from a working interpreter with python -m ipykernel install. If the environment still exists under a new path, editing argv to the new Python path is the faster fix.

kernelspec json references a python that no longer exists

Use this when

• Selecting the kernel produces a launch failure mentioning a missing executable or a bad interpreter path.
• jupyter kernelspec list finds the kernel, but starting it fails immediately with no kernel-side traceback.
• An old virtualenv or conda env was deleted or renamed and its kernel entry still lingers.

Not for this skill when

• The kernel is not listed at all. That is a search-path problem, a different fix.
• The kernel starts and then dies importing packages. That is an environment-content problem, not a dead interpreter path.

Steps

1. Find the spec directory: jupyter kernelspec list and note the path for the broken kernel. Expected: a directory path containing kernel.json.
2. Read kernel.json and look at the first entry of argv. Expected: an absolute Python path you can test in the next step.
3. Test the interpreter: run that exact path with --version (or ls the path). Expected: 'no such file' or equivalent, confirming the interpreter is gone.
4. Pick the replacement interpreter: the Python of the environment you actually want (a venv's bin/python or a conda env's python). Expected: that Python runs and import ipykernel succeeds in it.
5. Reinstall the spec from the live interpreter: [that-python] -m ipykernel install --user --name [kernel-name] --display-name "[display]". Expected: install output confirms the spec was written, and kernel.json argv now points at the live Python.
6. If the environment merely moved, you may instead edit kernel.json argv[0] to the new path and restart the server. Expected: the kernel launches without reinstalling.
7. Launch the kernel from the UI or with jupyter console --kernel [kernel-name]. Expected: a working REPL prompt, proving the spec resolves.

Tool compatibility

ipykernel 6.x, jupyterclient 7.x/8.x, jupytercore 5.x; venv, virtualenv, and conda-managed interpreters.

Variant phrasings

kernel failed to start: no such file or directory python

The launch-error phrasing of the dead-interpreter problem. Check kernel.json argv.

jupyter kernel points to deleted virtualenv

The venv-deletion phrasing. Reinstall the spec from the replacement interpreter.

kernel.json argv wrong python path

The direct phrasing. Either reinstall the spec or edit argv to the live path.

Why it happens

A kernelspec is a static JSON file, and ipykernel install bakes the installing interpreter's absolute path into argv at registration time. Nothing watches the filesystem afterwards, so when the environment is deleted, renamed, or moved, the spec keeps pointing at the old path indefinitely. Kernel startup then fails at process spawn, before any Python code runs, which is why there is no Python traceback to debug. Reinstalling from a live interpreter regenerates the spec with a valid path, and it also refreshes the display name and metadata in one step.

Edge cases / pitfalls

• Reinstalling with the system Python when you meant the project venv creates a spec that launches fine but lacks your packages. Always run the install command with the intended interpreter.
• Editing kernel.json by hand is quick but brittle: a JSON syntax slip breaks the whole spec. Validate with python -m json.tool kernel.json after editing.
• Old specs with the same name in another data directory can shadow your fixed one. Re-check jupyter kernelspec list paths after the fix.
• Agents that recreate environments on every run should reinstall the kernelspec as part of environment setup, not as a one-time manual step.

Provenance

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

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

Thread query: kernelspec json references a python that no longer exists

TL;DR: The kernel.json hard-codes the absolute path of the Python that registered it, so deleting or renaming that environment leaves a spec pointing at nothing and the kernel fails to launch. Inspect the spec's argv with jupyter kernelspec list plus a read of kernel.json, then reinstall the spec from a working interpreter with python -m ipykernel install. If the environment still exists under a new path, editing argv to the new Python path is the faster fix.

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.

Not specified by the original author.

TL;DR

An empty kernel error means the kernel process died before it could log anything, so the first job is making it talk. Start the server with --debug, find the kernelspec with jupyter kernelspec list, read its kernel.json argv, and run that command by hand in a terminal. The hand launch prints the real error (missing module, bad python path, permission) that the UI swallowed.

debug py3 kernel: kernel error on startup, no traceback in logs

Use this when

• JupyterLab shows kernel error with an empty traceback on startup.
• Server logs show the kernel launching and dying with no python error.
• The python3 kernel entry exists but never connects.

Not for this skill when

• The kernel starts and dies on a specific import. That leaves a traceback; debug the import.
• All kernels fail identically. Suspect the server install, not one spec.

Steps

1. Restart the server with debug logging: jupyter lab --debug. Verify: the log now shows the exact kernel launch command.
2. Inspect the spec: jupyter kernelspec list, then read kernel.json for the python3 entry. Verify: the argv[0] python path exists.
3. Run the launch command by hand: [argv-python] -m ipykernel_launcher -f [any-json]. Verify: you see the real error printed.
4. Fix what the hand launch reveals (install ipykernel into that python, fix the path, fix permissions). Verify: the hand launch stays alive.
5. Restart the server normally and launch the kernel from the UI. Verify: it connects and executes.

Variant phrasings

kernel error no traceback jupyter lab

UI phrasing. Hand-launch the kernel to get the error.

python3 kernel failed to start empty error

Spec-level phrasing. The kernelspec python is the suspect.

debug jupyter kernel startup

General phrasing. --debug plus manual launch.

Compatibility: JupyterLab 3/4, ipykernel 6.x. The hand-launch technique works for any kernelspec.

Why it happens

The UI only shows what the kernel process reported back over its channels, and a process that dies during interpreter startup reports nothing. The server log at default verbosity also skips the launch details. Running the identical command in a terminal removes both layers of silence and shows the underlying failure, which is usually a missing ipykernel in that python or a bad interpreter path in the spec.

Edge cases / pitfalls

• The kernelspec python may be a path that no longer exists after an env was deleted and recreated. Reinstall the spec.
• A kernel.json with a relative python path resolves against the server's cwd, not yours. Use absolute paths in specs.
• --debug is noisy; capture it to a file and grep for the launch line instead of reading live.
• Fixing the terminal python does not fix the kernelspec python. Always work from the spec's argv.

Provenance

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

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

Thread query: debug py3 kernel: kernel error on startup, no traceback in logs

TL;DR: An empty kernel error means the kernel process died before it could log anything, so the first job is making it talk. Start the server with --debug, find the kernelspec with jupyter kernelspec list, read its kernel.json argv, and run that command by hand in a terminal. The hand launch prints the real error (missing module, bad python path, permission) that the UI swallowed.