## 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.

```text
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