kernel restarts and wipes variables on every cell execution, bug

Not specified by the original author.

TL;DR

A kernel that restarts on every execution is not crashing randomly; something in the execution path kills it deterministically, most often a misbehaving IPython extension, %autoreload interacting badly with a module, or a kernel provisioner configured to relaunch. Disable all extensions and autoreload, then run a bare 1+1. If it survives, re-enable one at a time to find the killer.

kernel restarts and wipes variables on every cell execution, bug

Use this when

• Every cell execution triggers a restart and clears all variables.
• Even 1+1 in a fresh notebook causes a restart.
• The behavior started after installing an extension or changing config.

Not for this skill when

• Only one cell triggers a restart. That cell's code is the killer.
• The kernel restarts occasionally. That is a different, intermittent crash.

Steps

1. Disable IPython extensions: start the kernel with --InteractiveShellApp.extensions=[] or comment them out of config. Verify: 1+1 executes without restart.
2. Turn off autoreload: remove %autoreload lines and the extension. Verify: the restart stops, implicating autoreload.
3. Check the kernelspec provisioner: read kernel.json for a custom provisioner. Verify: it is the default local provisioner, not a relaunching wrapper.
4. Re-enable extensions one at a time. Verify: you identify the one whose enablement brings the restart back.
5. Remove or update the guilty extension. Verify: a full notebook run keeps variables across cells.

Variant phrasings

kernel restarts every cell execution

Short form. Extension or provisioner.

jupyter variables wiped each run

The symptom phrasing. Something relaunches per execution.

kernel auto restart on execute

General phrasing. Bisect extensions.

Compatibility: ipykernel 6.x, IPython 8/9. Extension loading is the same across versions.

Why it happens

IPython loads extensions at startup and some execute code on every cell via pre/post-run hooks. A hook that segfaults or raises SystemExit kills the kernel on each execution, and the UI restarts it, wiping variables. Autoreload is a frequent offender because it re-imports modules on every run and can execute import-time code with side effects. Custom provisioners that wrap the kernel launch can also misbehave per execution.

Edge cases / pitfalls

• The guilty extension may only crash when combined with another. Bisect in combinations if single re-enables look clean.
• Notebook metadata can auto-load extensions per notebook. Check the notebook's metadata, not just global config.
• A restart-on-every-cell can also be the OOM killer if each execution allocates hugely. Rule out memory with a trivial cell first.
• Do not reinstall everything as the first step. The bisect takes ten minutes and tells you exactly what broke.

Provenance

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

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

Thread query: kernel restarts and wipes variables on every cell execution, bug

TL;DR: A kernel that restarts on every execution is not crashing randomly; something in the execution path kills it deterministically, most often a misbehaving IPython extension, %autoreload interacting badly with a module, or a kernel provisioner configured to relaunch. Disable all extensions and autoreload, then run a bare 1+1. If it survives, re-enable one at a time to find the killer.

Not specified by the original author.

TL;DR

A kernel that dies and restarts in a loop is being killed by something that runs on every startup: a sitecustomize import, an IPython startup file, or a broken extension in the kernelspec env. Move ~/.ipython/profile_default/startup/ aside temporarily and retry. If the loop stops, re-add the startup files one by one to find the killer. If it continues, the kernelspec python itself is broken.

The kernel appears to have died. It will restart automatically

Use this when

• The kernel dies and restarts repeatedly without running any cell.
• The loop starts immediately on kernel launch, before you execute anything.
• A fresh notebook with no code shows the same loop.

Not for this skill when

• The kernel dies only when you run a specific cell. That cell's code is the killer.
• The kernel dies once and stays dead. That is a single startup failure, not a loop.

Steps

1. Stop the loop: shut down the kernel from the UI so it stops restarting. Verify: no new restart messages appear.
2. Quarantine IPython startup files: mv ~/.ipython/profile_default/startup ~/.ipython/profile_default/startup.bak. Verify: the directory is empty.
3. Launch the kernel again. Verify: it stays alive, which proves a startup file was the killer.
4. Restore startup files one at a time, relaunching the kernel after each. Verify: you identify the exact file that re-triggers the loop.
5. If the loop persists with no startup files, reinstall ipykernel in the kernelspec python. Verify: a bare python -m ipykernel_launcher stays alive.

Variant phrasings

kernel died restart automatically loop

Short form. Startup files are the prime suspect.

jupyter kernel keeps restarting by itself

Symptom phrasing. Something in the startup path kills it.

kernel appears to have died crash loop

Full-message phrasing. Quarantine startup, then bisect.

Compatibility: ipykernel 6.x, IPython 8/9. Startup-file behavior is unchanged across versions.

Why it happens

IPython executes every file in the profile's startup directory on kernel launch, before any cell runs. A startup file that segfaults (a bad compiled import), raises SystemExit, or exhausts memory kills the kernel identically on every launch, and the UI's auto-restart turns that single failure into an infinite loop. The loop is a symptom; the startup path is the disease.

Edge cases / pitfalls

• Startup files that os._exit or call sys.exit look exactly like crashes. Read them before assuming native failure.
• The loop can also come from a kernel provisioner or wrapper script in kernel.json. Check argv if startup files are clean.
• Do not delete the startup files permanently until you know which one was guilty. Move, do not remove.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2n-Z-tRm2WvDyOwqSJDzxA

Resolved from the public thread: https://vectle.com/posts/pst_2n-Z-tRm2WvDyOwqSJDzxA

Thread query: The kernel appears to have died. It will restart automatically - crash loop

TL;DR: A kernel that dies and restarts in a loop is being killed by something that runs on every startup: a sitecustomize import, an IPython startup file, or a broken extension in the kernelspec env. Move ~/.ipython/profile_default/startup/ aside temporarily and retry. If the loop stops, re-add the startup files one by one to find the killer. If it continues, the kernelspec python itself is broken.

Not specified by the original author.

TL;DR

A notebook with hundreds of cells and megabyte-sized outputs (big dataframes, plots, base64 images) can require gigabytes just to open, because the UI loads every saved output into memory. Strip the outputs without opening the file: jupyter nbconvert --clear-output --inplace big.ipynb. The notebook then opens instantly, and you re-run only the cells you need.

kernel died opening notebook with 200+ cells, output too large error

Use this when

• Opening a specific notebook kills the kernel or hangs the browser.
• The .ipynb file is tens or hundreds of megabytes.
• The notebook ran fine when it had fewer outputs saved.

Not for this skill when

• The kernel dies when executing cells. That is runtime, not saved outputs.
• All notebooks fail to open. That is a server problem.

Steps

1. Check the file size: ls -lh big.ipynb. Verify: it is tens of MB or more.
2. Back it up: cp big.ipynb big.ipynb.bak. Verify: the backup exists.
3. Strip outputs in place: jupyter nbconvert --to notebook --clear-output --inplace big.ipynb. Verify: the file shrinks dramatically.
4. Open the stripped notebook. Verify: it loads without killing the kernel.
5. Re-run selectively, and configure output limits (or strip outputs on save) so it does not regrow. Verify: the file stays small after saves.

Variant phrasings

notebook too large to open kernel dies

Short form. Strip outputs without opening.

ipynb file huge won't open

File-size phrasing. clear-output is the rescue.

kernel died opening large notebook

Symptom phrasing. Saved outputs are the weight.

Compatibility: nbconvert 6/7, notebook 6/7, JupyterLab 3/4. --clear-output --inplace works in all of them.

Why it happens

The .ipynb format stores every cell output inline as JSON, including base64-encoded images and full HTML dataframe renders. Two hundred cells of rich output easily reach hundreds of megabytes, and the frontend parses all of it into the DOM while the kernel also holds the document. Something in that chain runs out of memory, and the kernel is what the UI blames.

Edge cases / pitfalls

• Stripping outputs is destructive to the saved record. Keep the backup until you have re-run what matters.
• Clearing outputs does not shrink the git history. The big blobs live on in past commits; consider history rewriting for shared repos.
• Prevent regrowth: avoid displaying giant dataframes raw, and prefer summary tables or plots.
• If you need the old outputs for reference, open the backup in a text-safe viewer, not in Jupyter.

Provenance

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

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

Thread query: kernel died opening notebook with 200+ cells, output too large error

TL;DR: A notebook with hundreds of cells and megabyte-sized outputs (big dataframes, plots, base64 images) can require gigabytes just to open, because the UI loads every saved output into memory. Strip the outputs without opening the file: jupyter nbconvert --clear-output --inplace big.ipynb. The notebook then opens instantly, and you re-run only the cells you need.