What to Do When JupyterLab 4.6 Can't Find a Python Kernel in 2026?

Symptom → JupyterLab opens, but the Python kernel you need is missing. Fastest fix → confirm which Python environment runs the Jupyter server, then install and register ipykernel in the target environment.

This applies when the kernel list is empty, a project environment is missing, or a Notebook still runs a different Python after an environment change. Don’t reinstall JupyterLab until you know which layer is failing.

Students can use the checks below when JupyterLab shows no kernel or omits a project environment.
Graduate researchers can verify whether an existing Notebook still uses the intended interpreter.
Lab support staff can use the fault categories and acceptance checks to document a repair.

JupyterLab 4.6 can't find a Python kernel: identify the failing layer

JupyterLab’s interface, the Python environment that starts its server, and the Python environment that executes a Notebook are related, but they are not interchangeable. Opening the interface proves that a Jupyter server is reachable. It does not prove that the server can see a particular kernel or that a Notebook has selected it.

JupyterLab uses kernels to run Notebook code. A kernelspec tells Jupyter how to start a kernel; its argv entry points to the executable that should launch it. The JupyterLab documentation on documents and kernels explains the relationship between documents and kernels. The Jupyter Client kernelspec documentation describes how kernel specifications are used to start kernels.

Before making changes, record the information that narrows down the fault:

• How was JupyterLab started: from a terminal, an app, a notebook launcher, or a remote server?
• Which Python environment was active when the server started?
• Is the kernel list empty, or is only one project environment absent?
• Does the Notebook open but run code under the wrong interpreter?
• Did the project environment move, get renamed, or get removed?

The official stable documentation identifies JupyterLab 4.6.5 as the stable release as of November 4, 2026. Since versions and commands can change, check the JupyterLab changelog when reproducing this procedure against a later release. This article addresses the 4.6 series; it does not assume that a missing kernel is a general JupyterLab defect.

Classify the symptom before changing environments

JupyterLab opens, but there is no Python option in the kernel list. What should you check first?

Start with the kernels that the running Jupyter service can discover. In a terminal connected to the same host and launch context as the service, run:

jupyter kernelspec list

This lists the kernelspecs visible to that Jupyter command. It does not prove that every Python installation on the computer is registered. Nor does running python in a terminal prove that JupyterLab has discovered that interpreter. The Jupyter Client kernel documentation describes kernelspec discovery and the information used to launch kernels.

If the list contains no usable Python kernel, investigate whether the service can see any registered Python kernel. If it contains other kernels but not the project environment, focus on that environment’s installation and registration. This distinction prevents a narrow registration problem from turning into a broad reinstall.

The service’s launch context matters. A Jupyter server started from one environment may not have the same executable search path or user-level kernelspec visibility as a server launched from another. If a browser connects to a server on a different machine, commands run in a local terminal may be inspecting the wrong host. The Jupyter Server documentation explains how server configuration affects how a server runs; consult its configuration guide when the launch context is unclear.

For a useful baseline, note the output of these commands in the same terminal used to start JupyterLab:

which python
python --version
which jupyter
jupyter kernelspec list

On macOS shells, which can help show which executable the current shell resolves. Treat it as a clue about that shell, not as proof of which interpreter an already-running service or Notebook uses. If JupyterLab was started by a separate launcher or on another host, check the actual service environment instead.

The virtual environment has ipykernel, but JupyterLab still cannot see it. Why?

The package may be installed in a different Python environment from the one you intend to use, or it may be installed but not registered as a kernel visible to the Jupyter service. Installing a package and registering a kernelspec are separate checks. The IPython documentation gives the supported kernel installation commands.

First activate the intended environment, then ask that environment’s Python to run pip. This avoids relying on whichever standalone pip happens to resolve in the shell:

python -m pip show ipykernel

If the package is absent in this environment, install it there:

python -m pip install ipykernel

Then register the environment as a kernel:

python -m ipykernel install --user --name project-env --display-name "Python (project-env)"

Replace project-env with a stable identifier for the project. The display name can be descriptive, such as Python (analysis), but it is only a label in the interface. It does not prove which Python executable the kernel uses. The IPython kernel installation guide documents the registration options and the distinction between the kernel name and display name.

After registration, check the list again:

jupyter kernelspec list

If the project kernel appears, select it in the Notebook. If it does not, verify that the registration command ran under the intended Python and that the Jupyter service can see the user-level kernelspec. If the service runs under another account, in a managed launcher, or on a remote host, the registration location may not be visible to that service. Avoid copying a kernelspec between environments without checking its executable path.

Repair stale registrations and confirm the Notebook interpreter

A kernel can appear in the menu and still fail to start. A common thing to check is whether the kernelspec points to an executable that exists. Environments can be moved, renamed, or deleted while an old kernelspec remains. The menu entry may still show its display name, even if its launch path is no longer valid.

Use jupyter kernelspec list to locate the relevant specification. Inspect the kernel.json file in that kernelspec directory and check the executable in its argv entry. Compare that path with the Python executable in the intended environment. The kernelspec format is described in the Jupyter Client documentation.

If the executable path is stale, register the kernel again from the active project environment using the ipykernel install command above. Do not edit a shared or managed kernelspec unless you understand which users and services depend on it. If the registration was created under another account, confirm the intended user and service context before deleting or replacing it.

How can you confirm that a selected kernel is running the intended Python?

Run this small diagnostic in a Notebook cell:

import sys
print(sys.executable)
print(sys.version)

The printed executable should correspond to the Python environment intended for the project. A kernel named Python (project-env) is not enough evidence by itself. The Notebook’s actual sys.executable is a better check of which interpreter is executing its code.

Then check the project’s important dependencies from inside that same Notebook. For example:

import importlib.util

for package in ["numpy", "pandas"]:
    print(package, importlib.util.find_spec(package))

Replace the example packages with dependencies the research workflow actually needs. A result of None means that this Python process did not find that importable module. It does not tell you whether the package is installed elsewhere on the machine. Install or repair dependencies in the selected environment, rather than assuming a package installed into a different Python will become available automatically.

Also verify the project’s working directory:

from pathlib import Path
print(Path.cwd())

A correct interpreter can still run with the wrong working directory. That can affect relative file paths, local modules, configuration files, and data access. Keep these checks separate: kernel startup, interpreter identity, dependency availability, and project path are distinct acceptance points.

How do you make an older Notebook use a newly registered Python environment?

Register the new environment, open the Notebook, and select its kernel through JupyterLab’s kernel controls. The JupyterLab documents and kernels guide explains how a document is associated with a kernel. After changing the selection, run the sys.executable check in the Notebook. Do not rely on a saved kernel label or on the fact that the Notebook opens.

Changing a Notebook’s kernel does not automatically recreate the project’s dependencies, data files, or working directory. Before rerunning a full analysis, confirm that the new environment contains the packages the project requires and that the Notebook points to the expected files. Keep the previous environment available until the new one passes the project checks, especially when a Notebook depends on older package versions.

Use a focused sequence for startup failures

When the kernel is visible but will not start, or repeatedly disconnects, isolate the failure before changing the project. The following sequence keeps the checks small and reversible.

1. Confirm the host. Verify that the terminal, Jupyter server, and kernel are on the expected machine. If the Notebook connects to a remote server, local Mac commands do not inspect that server’s kernelspecs.

2. Confirm the server launch context. Record how JupyterLab was started and which environment provides the jupyter command. If a launcher starts the service for you, identify its configured environment rather than assuming it uses the terminal’s active environment.

3. Inspect the kernelspec. Run jupyter kernelspec list in the relevant context. Find the specification for the selected kernel and check whether its argv executable still exists.

4. Test a minimal cell. After selecting the intended kernel, run a cell that prints sys.executable and sys.version. If this fails, the problem is earlier than the analysis code or its data.

5. Check the project path and imports. Once a minimal cell works, inspect Path.cwd() and test only the dependencies needed for the next analysis step. This distinguishes a kernel startup failure from a project configuration issue.

6. Preserve evidence before cleanup. Record the kernel name, executable path, environment location, and exact error text. Avoid deleting environments or reinstalling global Python while the cause is still unclear.

This sequence is deliberately diagnostic. It does not attribute every startup error to JupyterLab 4.6. The failure may be a missing executable, a stale registration, an environment that is not visible to the service, or a host mismatch. If a kernel starts and then disconnects, first reproduce the failure with a minimal cell. Only then investigate project-specific imports, resource use, or server logs.

For macOS virtual environments, Python’s official venv documentation covers how environments are created and activated. The important troubleshooting point is that a virtual environment is tied to its Python installation and location. If the environment is moved or rebuilt, an old kernelspec may no longer point to a working executable.

Accept the repair with a reproducible check

A repair is complete only when the target Notebook runs in the intended environment and can perform the project’s necessary checks. Use this compact checklist before returning to a full analysis:

• [ ] The Jupyter server is running on the intended host and under the expected launch context.
• [ ] jupyter kernelspec list shows the target kernel in a context visible to that service.
• [ ] The Notebook has the intended kernel selected.
• [ ] sys.executable and sys.version match the project’s Python environment.
• [ ] Required imports resolve inside the Notebook, not just in a separate terminal.
• [ ] The Notebook’s working directory and required files are correct.
• [ ] A small, representative analysis step runs without relying on sensitive data.
• [ ] The environment and kernel details are recorded so another lab member can reproduce the check.

For a reproducibility note, save the environment’s location, the kernelspec name, the interpreter path reported inside the Notebook, and the key dependency information. Do not place research data or credentials in a troubleshooting record. If the Notebook contains confidential material, first review the lab’s data-handling requirements before moving work to another machine or service.

Choose a computing route that fits the actual requirement

A remote Mac is not a general fix for an incorrectly registered kernel. If the Notebook is meant to run in a Linux or Windows environment, repair that environment where it belongs. Consider macOS only when the work genuinely requires macOS validation, a macOS-specific tool, or a check that cannot be performed on the lab’s available systems.

If the lab lacks a Mac but a project needs macOS validation, review HireVM’s remote Mac access and usage guides before deciding. Check the documented access method and whether it fits the work. A remote machine does not guarantee that a specific research application or dataset will be compatible. For examples of the kinds of remote Mac workflows to evaluate, see HireVM’s examples.

The trade-off is practical. A lab’s existing Linux or Windows machine may not provide the macOS environment a specific check requires. Buying a Mac creates an upfront hardware commitment and leaves the lab responsible for maintenance. Remote access avoids purchasing a local machine for a short validation task, but it introduces network dependence and requires careful review of data-handling and access arrangements. If work must run continuously on a stable, dedicated machine or needs local physical connections, remote rental may not be the right choice.

Fix the kernel registration first, then decide whether the project also needs a Mac. When the remaining requirement is temporary macOS access and the lab has no suitable device, compare the documented remote access options with the project’s security and workflow needs on HireVM.