jupyter kernel died after pip install inside notebook, ImportError on restart

TL;DR

Installing packages from inside a running notebook swaps the files under a live interpreter: the kernel keeps the old modules in memory while new imports see new files, and on restart the half-upgraded environment can fail to import at all. The immediate fix is simple: restart the kernel after any in-notebook install, then run all cells. For a durable fix, install into the environment from the terminal and keep a requirements file.

jupyter kernel died after pip install inside notebook, ImportError on restart

Use this when

• The kernel dies or throws ImportError right after %pip install or !pip install in a cell.
• The install upgraded numpy, scipy, or another compiled package.
• Restarting once does not help because the environment itself is now skewed.

Not for this skill when

• The pip install itself fails. That is a resolver or network issue.
• The kernel dies without any install. That is a different crash.

Steps

1. Restart the kernel once and run import cells only. Verify: whether the ImportError persists in a fresh interpreter.
2. If it persists, find the skew: [kernel python] -m pip check. Verify: pip names the broken dependency pair.
3. Repair the environment: [kernel python] -m pip install -U [broken-package] [its-dependency]. Verify: pip check is clean.
4. Reinstall the kernel spec if the python path changed: [kernel python] -m ipykernel install --user --name [env]. Verify: the spec exists.
5. Going forward, do installs from the terminal and restart the kernel after. Verify: the notebook's first cell documents the environment setup.

Variant phrasings

pip install inside notebook broke kernel

Short form. Restart, then repair the skew.

kernel ImportError after pip install jupyter

Symptom phrasing. pip check names the break.

%pip install kernel died

Magic-command phrasing. Same live-interpreter hazard.

Compatibility: ipykernel 6.x with the %pip/%conda magics (IPython 7+). The magics install into the kernel env, which is the correct target.

Why it happens

A running kernel has already imported its core modules, so upgrading them mid-session mixes old in-memory code with new on-disk files. Worse, pip may upgrade a dependency like numpy while scipy stays old, and the next kernel start loads the skewed pair and dies on import. The notebook makes this easy to do and hard to notice, because the failure appears one restart later.

Edge cases / pitfalls

• Always use %pip (the magic), never !pip. The magic targets the kernel's python; !pip may target a different one.
• Installing with --upgrade on one package can cascade through the dependency tree. Pin versions for shared notebooks.
• The %conda magic exists too, but mixing conda and pip installs in one session is the fastest route to a skewed env.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bj-7YInE-T1NYV6wkytaug