kernel died after installing new conda package, how to fix

TL;DR

A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

kernel died after installing new conda package

Use this when

• The kernel worked, you installed one conda package, and now it dies on startup or first import.
• conda list --revisions shows a solver run right before the breakage.
• Imports of numpy, scipy, or pandas now segfault or die silently.

Not for this skill when

• The kernel dies only on large data. That is memory pressure, not a bad install.
• The kernel dies on a fresh environment too. That points at the machine, not the package.

Steps

1. List revisions: conda list --revisions. Verify: you can see the revision number from before the bad install.
2. Roll back: conda install --revision [N]. Verify: the kernel starts and the previously working imports succeed.
3. If rollback fails, export the env: conda env export --no-builds > env-backup.yml. Verify: the file lists your packages.
4. Recreate cleanly: conda env remove -n [env], then conda env create -f env-backup.yml. Verify: the new env's kernel starts.
5. Reinstall the new package pinned: conda install [package]=[version] from the main channel only, avoiding pip/conda mixes for numpy/scipy. Verify: imports still work after install.

Variant phrasings

conda install broke jupyter kernel

General phrasing. Rollback is the fastest recovery.

kernel died after pip install conda env

The pip-into-conda variant. Pip can overwrite conda-managed binaries; same rollback applies.

jupyter kernel dies after installing package

Symptom phrasing. Binary clash is the prime suspect.

Compatibility: conda/mamba on Linux and macOS, ipykernel 6.x. Revision rollback needs conda (mamba keeps the same history format).

Why it happens

Conda's solver optimizes for resolving the requested install, and it will happily swap your numpy build from MKL to OpenBLAS or mix pip-installed wheels with conda binaries to make the numbers work. The kernel then loads two incompatible BLAS libraries in one process and dies before any python traceback can print, which is why there is no error message, just a dead kernel.

Edge cases / pitfalls

• Never pip install numpy inside a conda env that already has conda numpy. That single command causes most of these deaths.
• Rollback only works if you have not run conda clean in a way that removed the cached packages. Check the revision list first.
• Rebuilding the env loses unexported pip installs. Export both conda env export and pip freeze before removing.
• If you must mix pip and conda, install conda packages first, then pip, and never pip-install anything conda already provides.

Provenance

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

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

Thread query: kernel died after installing new conda package, how to fix

TL;DR: A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.