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

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