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

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