kernel restarts wiping variables every cell execution

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

Select the kernel that actually ran the cells; the explorer only shows the active kernel's namespace. The explorer is bound to whichever kernel the notebook UI selected, which may differ from the one that executed your code. Use the kernel picker to switch to the executing kernel, then re-run a cell to refresh the explorer.

vscode jupyter variable explorer empty: kernel connected but not the right one

Use this when

• Variables are defined and usable but the variable explorer is empty
• Multiple kernels appear in the picker and the explorer disagrees with cell output
• The explorer worked before a kernel restart or reconnect

Not for this skill when

• The kernel fails to start at all - that is item 121
• No kernels are listed - that is item 122
• Variables genuinely do not exist (NameError in cells) - that is a code problem

Steps

1. Check which kernel the notebook is using: read the kernel indicator in the top-right of the notebook. Expected: a kernel name that may not be the one you ran cells with.

2. List what is actually running: compare recent cell outputs against the indicator. Expected: evidence that cells executed under a different kernel.

3. Switch with the kernel picker to the kernel that ran the code. Expected: the indicator updates to the executing kernel.

4. Re-run any cell to force a namespace refresh. Expected: the variable explorer populates with the defined variables.

5. Going forward, set the kernel once per notebook and avoid switching mid-analysis without re-running. Expected: explorer and cells stay consistent.

Tool compatibility

VS Code 1.85+, Jupyter extension, ipykernel 6.x

Variant phrasings

vscode variable explorer empty wrong kernel

Same fix applies: see the Steps section above.

vscode jupyter variables not showing

Same fix applies: see the Steps section above.

vscode notebook variable explorer blank

Same fix applies: see the Steps section above.

Why it happens

The variable explorer is a view over the active kernel's namespace, fetched over the kernel's comm channel. VS Code lets the UI-selected kernel drift from the kernel that executed cells (after restarts, reconnects, or picker changes), and the explorer faithfully shows the empty namespace of the newly selected kernel. Nothing is lost; the variables live in the other kernel. Re-selecting the executing kernel rebinds the explorer to the namespace that holds the data.

Edge cases / pitfalls

• Restarting a kernel wipes its namespace; the explorer empties legitimately then - re-run cells.
• Remote kernels over SSH show variables only while the connection is healthy; reconnect first.
• Very large variables can make the explorer slow; that is a display cost, not a binding problem.

Provenance

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

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

Thread query: vscode jupyter variable explorer empty: kernel connected but not the right one

TL;DR: Select the kernel that actually ran the cells; the explorer only shows the active kernel's namespace. The explorer is bound to whichever kernel the notebook UI selected, which may differ from the one that executed your code. Use the kernel picker to switch to the executing kernel, then re-run a cell to refresh the explorer.