kernel failed to start: 'kernel error' with empty traceback in jupyter lab

TL;DR

JupyterLab shows kernel error with nothing in the traceback when the kernel process dies before logging, which almost always means the kernelspec's python is missing, broken, or lacks ipykernel. Open jupyter kernelspec list, read the kernel.json argv, and run that exact command in a terminal. The terminal prints the real error; fix that, reinstall the spec if needed, and the Lab error clears.

kernel failed to start: 'kernel error' with empty traceback in jupyter lab

Use this when

• JupyterLab shows kernel error and the traceback panel is empty.
• The server log shows the launch attempt but no python error.
• Other kernels (or the same kernel elsewhere) work.

Not for this skill when

• The traceback is non-empty. Read it; the answer is in there.
• The kernel starts but dies later. That is a runtime crash.

Steps

1. List specs: jupyter kernelspec list. Verify: the failing kernel's spec exists.
2. Read its kernel.json and note argv[0], the python path. Verify: that path exists on disk.
3. Hand-launch: [that python] -m ipykernel_launcher -f /tmp/test.json. Verify: you see the real error (no module, bad path, permission).
4. Fix the revealed problem: install ipykernel into that python, or fix the path. Verify: the hand launch stays alive.
5. Reinstall the spec from the fixed python if the path changed. Verify: Lab launches the kernel cleanly.

Variant phrasings

jupyterlab kernel error empty traceback

Short form. The spec's python is broken.

kernel error no details jupyter lab

UI phrasing. Hand-launch reveals the error.

kernelspec broken python kernel error

The cause phrasing. Fix the spec's python.

Compatibility: JupyterLab 3/4, ipykernel 6.x. kernelspec layout is stable.

Why it happens

Lab renders whatever the kernel process reported, and a process that fails during interpreter startup reports nothing, so the panel is empty by construction. The usual underlying failures are a deleted conda env still referenced by a spec, a python path that moved, or ipykernel missing from that python. All three are invisible from the UI and obvious from a terminal.

Edge cases / pitfalls

• Deleting and recreating a conda env with the same name leaves a spec pointing at the old path. Reinstall specs after env recreation.
• The default python3 spec may resolve differently for the server than for your shell. Check the spec's absolute path, not your PATH.
• A spec with extra env vars in env can break the launch. Compare against a known-good spec.
• Fixing your shell python does not fix the spec python. Work from kernel.json outward.

Provenance

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