Was tun, wenn JupyterLab 4.6 im Jahr 2026 keinen Python-Kernel findet?

Das Symptom: JupyterLab öffnet sich, aber der gewünschte Python-Kernel fehlt oder startet nicht.

Die schnellste Lösung: Prüfen Sie zuerst, mit welcher Python-Umgebung der JupyterLab-Dienst läuft. Installieren und registrieren Sie ipykernel anschließend in der Zielumgebung. Fehlt nur das Projekt-Environment in der Liste, installieren Sie JupyterLab nicht vorschnell neu.

Dieser Leitfaden richtet sich an Studierende und Forschende, deren Kernel-Auswahl leer ist oder eine benötigte Python-Umgebung nicht enthält.
Auch nach einem Wechsel des Virtual Environments, einer Conda-Umgebung oder der Python-Version können Sie damit prüfen, ob ein vorhandenes Notebook noch den richtigen Interpreter verwendet.
Technische Mitarbeitende, die Mac-Analyseumgebungen betreuen, erhalten außerdem ein Verfahren zur Fehlereingrenzung und zur dokumentierten Abnahme.

JupyterLab 4.6 findet den Python-Kernel nicht: zuerst die Fehlerstelle bestimmen

JupyterLab-Oberfläche, gestarteter JupyterLab-Dienst und Python-Kernel sind miteinander verbunden, aber nicht dasselbe. Dass sich die Oberfläche öffnen lässt, beweist daher nicht, dass die gewünschte Python-Umgebung als Kernel verfügbar ist. Die JupyterLab-Dokumentation beschreibt die Kernel-Auswahl und die Arbeit mit Dokumenten; für die Fehlersuche sollten Sie diese drei Ebenen getrennt betrachten (Dokumentation zu Dokumenten und Kernels).

Halten Sie zunächst fest, wie JupyterLab gestartet wurde: über ein Terminal, eine Entwicklungsumgebung, einen Hintergrunddienst oder eine entfernte Sitzung. Notieren Sie außerdem das Konto, mit dem der Dienst läuft, den im Terminal sichtbaren JupyterLab-Versionsstand und das verwendete Projekt-Environment. Der Startweg ist wichtig: Ein Dienst kann unter einem anderen Konto laufen oder eine andere Jupyter-Konfiguration laden als das Terminal, in dem Python funktioniert. Jupyter Server dokumentiert Konfigurationsmöglichkeiten, die beim Abgleich des Dienstkontexts relevant sind (Konfigurationsdokumentation von Jupyter Server).

Für die Versionsprüfung ist jupyter lab --version ein sinnvoller Ausgangspunkt, sofern der Befehl aus derselben Shell-Umgebung stammt, mit der Sie den Dienst starten. Der offizielle Changelog führt JupyterLab 4.6.5 als stabile Version zum redaktionellen Prüfstand am 04.11.2026. Prüfen Sie die Versionsangabe vor einer späteren Veröffentlichung erneut, weil sie sich ändern kann (offizieller JupyterLab-Changelog).

JupyterLab lässt sich öffnen, aber die Liste enthält keinen Python-Kernel: Was ist zuerst zu prüfen?
Prüfen Sie, ob der Dienst überhaupt ein Kernel-Spec findet. Führen Sie jupyter kernelspec list im selben Benutzer- und Dienstkontext aus, aus dem JupyterLab läuft. Sind keine passenden Einträge vorhanden, ist das zunächst ein Registrierungs- oder Suchpfadproblem. Python muss deshalb nicht zwingend neu installiert werden.

Fehlende Einträge: Kernel-Spec und Dienstkontext

Ein Kernel-Spec verbindet Jupyter mit dem Programm, das den Kernel startet. Dazu gehören unter anderem der Startbefehl und dessen Argumente. Jupyter verwaltet solche Spezifikationen getrennt von der Frage, ob eine Python-Umgebung in einer beliebigen Terminal-Shell aktiviert werden kann. Die Beschreibung des Jupyter-Client erläutert, wie Kernel-Specs und Kernel-Start zusammenhängen (Dokumentation zu Jupyter-Kernels und Kernel-Specs).

Vergleichen Sie die Ausgabe von jupyter kernelspec list mit der Liste der Kernels, die JupyterLab in der Oberfläche anbietet. Führen Sie den Befehl nach Möglichkeit als das Konto und in dem Kontext aus, mit dem der Dienst gestartet wurde. Wenn die Shell ein Kernel-Spec anzeigt, die Oberfläche aber nicht, prüfen Sie als Nächstes die Dienstkonfiguration, das Dienstkonto und die geladenen Jupyter-Datenpfade. Ein Terminal unter einem persönlichen Benutzerkonto und ein Hintergrunddienst unter einem separaten Konto können unterschiedliche Kernel-Specs sehen.

Ist überhaupt kein Python-Kernel verfügbar, unterscheiden Sie zwischen „Python ist nicht installiert“ und „Python ist nicht als Kernel registriert“. Testen Sie den Interpreter gezielt mit python -c "import sys; print(sys.executable)". Ein erfolgreicher Befehl belegt, welcher Python-Interpreter in dieser Shell ausgeführt wird. Er belegt nicht, dass JupyterLab ihn kennt. Erst die Kombination aus einer passenden Python-Umgebung, installiertem ipykernel und einem auffindbaren Kernel-Spec stellt die Verbindung her.

Prüfen Sie beim Abgleich auch Dateirechte und den Dienststandort. Ein Kernel-Spec kann in einem Benutzerverzeichnis liegen, auf das der JupyterLab-Dienst keinen Zugriff hat. Läuft der JupyterLab-Dienst auf einem anderen Rechner als das Terminal, muss das Kernel-Spec für den tatsächlichen Dienst und den dort verfügbaren Interpreter eingerichtet werden. Eine lokal registrierte Umgebung erscheint nicht automatisch auf einem entfernten Host.

Virtual Environment ohne Kernel-Eintrag

Wenn andere Kernels in der Oberfläche sichtbar sind, aber das Projekt-Environment fehlt, richten Sie ipykernel in der Zielumgebung ein. Wichtig ist, dass Installation und Registrierung mit genau dem Python-Interpreter erfolgen, den das Notebook später verwenden soll. Die Python-Dokumentation erklärt die Verwendung isolierter Umgebungen; IPython beschreibt die Kernel-Installation für weitere Umgebungen (Python-Dokumentation zu venv, IPython-Anleitung zur Installation eines Kernels).

ipykernel ist im Virtual Environment installiert, aber JupyterLab zeigt es nicht an: Warum?
Häufig wurde das Paket mit einem anderen pip oder für einen anderen Python-Interpreter installiert als dem, den das Projekt verwendet. Prüfen Sie daher python -m pip show ipykernel in der Zielumgebung und vergleichen Sie den Interpreterpfad mit sys.executable. Ein erfolgreicher Paketnachweis in einer anderen Umgebung reicht nicht.

Arbeiten Sie die Einrichtung in dieser Reihenfolge ab:

1. Wechseln Sie in das Projektverzeichnis und aktivieren Sie das vorgesehene Environment. Bei einem mit venv erstellten Environment können Sie auf macOS beispielsweise source .venv/bin/activate verwenden. Die Aktivierung ist eine Bedienungshilfe für die Shell; entscheidend bleibt, welcher Interpreter anschließend tatsächlich ausgeführt wird.
2. Kontrollieren Sie den Interpreter mit python -c "import sys; print(sys.executable)". Merken Sie sich den ausgegebenen Pfad. Er sollte zum Projekt-Environment gehören.
3. Installieren Sie ipykernel in genau diesem Environment: python -m pip install ipykernel. Die Schreibweise python -m pip bindet den Paketmanager an den Interpreter des aufgerufenen python.
4. Registrieren Sie die Umgebung als Kernel, zum Beispiel mit python -m ipykernel install --user --name projektanalyse --display-name "Python (Projektanalyse)". Der Wert hinter --name dient als interner Bezeichner; --display-name ist die lesbare Beschriftung in der Oberfläche. Wählen Sie Bezeichnungen, mit denen sich Projekt und Umgebung auseinanderhalten lassen.
5. Führen Sie danach jupyter kernelspec list im passenden Jupyter-Kontext aus. Wenn der Eintrag fehlt, vergleichen Sie den Ort, an dem Sie ihn registriert haben, mit dem Benutzerkonto und dem Dienst, der JupyterLab ausführt.
6. Aktualisieren Sie die Kernel-Auswahl in JupyterLab und wählen Sie den neu registrierten Eintrag. Öffnen Sie ein Test-Notebook oder wechseln Sie bei einem bestehenden Notebook den Kernel über die Kernel-Auswahl. Die JupyterLab-Dokumentation beschreibt, wie Kernels für Notebooks ausgewählt und verwendet werden (Anleitung zum Ausführen von Notebooks).

Der Anzeigename ist kein Nachweis für den verwendeten Interpreter. Auch ein Eintrag namens „Python (Projektanalyse)“ kann auf eine veraltete oder falsche Umgebung verweisen. Öffnen Sie deshalb das Kernel-Spec im von jupyter kernelspec list genannten Verzeichnis und prüfen Sie die Startangabe. Die Jupyter-Client-Dokumentation beschreibt den Aufbau der Kernel-Specs und die Startkonfiguration (Kernel-Spec-Referenz).

Wie lässt sich ein bestehendes Notebook nach einem Python-Wechsel mit dem neuen Kernel verbinden?
Registrieren Sie zunächst den neuen Interpreter als eigenen Kernel und wählen Sie ihn dann im bestehenden Notebook aus. Speichern Sie das Notebook und führen Sie eine kurze Prüfung aus, bevor Sie die eigentliche Analyse fortsetzen. Ein früher gespeicherter Kernelname sorgt nicht dafür, dass Jupyter automatisch die neue Python-Umgebung erkennt.

Notebook läuft, verwendet aber den falschen Interpreter

Ein gestarteter Kernel ist noch kein Beleg dafür, dass das Notebook mit dem richtigen Projekt arbeitet. Prüfen Sie im Notebook selbst den Interpreter:

import sys
print(sys.executable)

Der Pfad muss zur vorgesehenen Umgebung passen. Prüfen Sie anschließend ein oder mehrere für das Projekt notwendige Pakete direkt aus diesem Notebook. Zum Beispiel können Sie mit importlib.util.find_spec feststellen, ob ein Modul über den aktiven Interpreter auffindbar ist:

import importlib.util
print(importlib.util.find_spec("pandas"))

Ersetzen Sie pandas durch ein tatsächlich benötigtes Projektpaket. Ein vorhandenes Paket im Terminal bedeutet nicht automatisch, dass es im Notebook-Kernel installiert ist. Notebook und Terminal können unterschiedliche Interpreter verwenden. Installieren Sie fehlende Abhängigkeiten deshalb gezielt über den Interpreter des ausgewählten Kernels, statt vorschnell globale Python-Installationen oder die Projektabhängigkeiten zu überschreiben.

Prüfen Sie zusätzlich das Arbeitsverzeichnis. Relative Dateipfade beziehen sich auf das Verzeichnis, aus dem die Analyse ausgeführt wird, und nicht zwingend auf den Speicherort des Notebooks. Halten Sie den Projektstartpfad, den Interpreter und die für den Versuch relevanten Abhängigkeiten in einer kurzen Reproduktionsnotiz fest. So kann ein anderes Labormitglied später unterscheiden, ob ein Fehler durch den Kernel, eine fehlende Bibliothek oder einen abweichenden Datenpfad entsteht.

Bei sensiblen Forschungsdaten gehört auch der Ausführungsort zur Prüfung. Ein Notebook, das lokal startet, kann andere Zugriffsrechte und Datenschutzbedingungen haben als ein Notebook auf einem gemeinsam genutzten Server. Verwenden Sie zur Fehlersuche keine vertraulichen Daten, wenn ein minimales Beispiel ausreicht. Für die Prüfung der Datenschutz- und Zugriffsbedingungen können Sie die Hinweise zum Datenschutz bei HireVM heranziehen und die Vorgaben Ihrer Hochschule berücksichtigen.

Registrierter Kernel startet nicht oder bricht ab

Wenn ein Kernel-Eintrag sichtbar ist, aber nicht startet, prüfen Sie zuerst den ausführbaren Pfad im Kernel-Spec. Er kann nach dem Verschieben oder Löschen einer Umgebung ins Leere zeigen. Auch eine neu erstellte Umgebung am selben Projektnamen muss nicht denselben Interpreterpfad haben wie die alte. Kontrollieren Sie deshalb den im Spec hinterlegten Startbefehl und vergleichen Sie ihn mit dem aktuellen Wert von sys.executable.

Gehen Sie bei wiederholten Abbrüchen schrittweise vor:

• Starten Sie das Notebook mit dem verdächtigen Kernel und notieren Sie die genaue Fehlermeldung.
• Prüfen Sie, ob der eingetragene Interpreter existiert und für das Dienstkonto ausführbar ist.
• Vergleichen Sie den Host des JupyterLab-Dienstes mit dem Host, auf dem die Zielumgebung liegt.
• Testen Sie eine kleine Zelle mit einer Interpreter- und Modulprüfung, bevor Sie die vollständige Analyse ausführen.
• Registrieren Sie ein neues Kernel-Spec nur dann, wenn das vorhandene auf einen nicht mehr gültigen Interpreter verweist.

Vermeiden Sie die Annahme, ein solcher Abbruch sei ein allgemeiner Fehler von JupyterLab 4.6. Die Ursache kann im Startpfad, in Zugriffsrechten oder in der Zuordnung zwischen Dienst und Environment liegen. Eine Neuinstallation von JupyterLab hilft nicht, wenn das Kernel-Spec weiterhin auf einen nicht vorhandenen Interpreter zeigt. Ändern Sie auch nicht mehrere Projektpakete gleichzeitig, bevor Sie den Fehler mit einer kleinen, wiederholbaren Prüfung eingegrenzt haben.

Abnahme und Entscheidung über eine Mac-Umgebung

Wählen Sie nach der Korrektur den beabsichtigten Kernel im Notebook aus und führen Sie einen Test ohne sensible Daten aus. Prüfen Sie dabei den Interpreterpfad, die Verfügbarkeit der zentralen Projektabhängigkeiten und einen repräsentativen Analyseschritt. Halten Sie außerdem fest, wie JupyterLab gestartet wird und wie das Kernel-Spec heißt. So entsteht ein nachvollziehbarer Abnahmenachweis, ohne dass dafür die gesamte Forschungsanalyse erneut ausgeführt werden muss.

Wenn die Analyse ausschließlich auf einer vorhandenen Linux- oder Windows-Umgebung ausgeführt werden soll, beheben Sie zuerst deren Kernel-Zuordnung. Eine zusätzliche Mac-Umgebung ist für diesen Reparaturschritt nicht automatisch erforderlich. Anders liegt der Fall, wenn das Projekt gezielt unter macOS getestet werden muss, im Labor aber kein nutzbarer Mac verfügbar ist. Dann kann ein gemieteter, realer Mac eine Ergänzung zu vorhandenen Hochschulrechnern sein.

Die Alternativen haben unterschiedliche Nachteile: Der Kauf eines eigenen Macs bindet Budget und setzt ein lokales Gerät voraus; Laborrechner stehen möglicherweise nicht jederzeit zur Verfügung; ein HPC-System bietet nicht automatisch eine macOS-Umgebung. Ein entfernter Mac bringt seinerseits mögliche Netzwerklatenz und Anforderungen an den Umgang mit Forschungsdaten mit sich. Er sollte deshalb erst nach Prüfung von Zugriffsweg, Übergabe und Datenschutz in den Arbeitsablauf aufgenommen werden. Für einen vorübergehenden macOS-Test können Sie die bei HireVM beschriebenen Zugangswege und Einsatzgrenzen prüfen. Die passende Umgebung muss zum Projekt und zu den Daten passen; sie garantiert nicht, dass eine konkrete Notebook-Konfiguration ohne weitere Anpassung läuft.