Claude Code With Jupyter Notebooks: Edit, Run, and Review

Claude Code can read, edit and execute cells in a Jupyter notebook. It understands the notebook format, can add or modify code cells, and can inspect the outputs that result from running them. Tools like fenbs keep the experiment decisions and reviewed findings outside the notebook so the next session starts from a shared, checked base rather than re-reading every cell to work out what was already confirmed.

This guide covers how to give Claude Code the context a notebook needs, how to handle cell execution, how to check reproducibility, and how to pass findings forward.

How Claude Code reads a notebook

Claude Code reads a .ipynb file as structured JSON. It sees the cell source, the cell outputs (text, images and errors), the kernel metadata and the notebook-level metadata. This means it can reason about what the code does and what the last run produced — as long as the outputs are saved in the file.

Unsaved outputs are invisible to Claude Code. If you last ran a notebook hours ago, clear the outputs and re-run it before asking Claude to review the results, or make sure you saved the notebook with outputs included.

A notebook is also stateful: a cell near the end may depend on variables set in a cell at the top. Claude Code benefits from a brief description of the cell execution order and any non-obvious dependencies — either as a comment in the first cell or as context you provide in the prompt.

Editing cells and adding new ones

Claude Code can modify existing cells and insert new ones. When you ask it to fix a function or add a visualization, it writes the change to the .ipynb file. You can then re-run the affected cells and review the output.

Be specific about where the change should go. Notebooks are not linear scripts; a change in cell 3 can affect cells 7 and 11. Tell Claude Code which cells depend on the one being changed, or ask it to describe its plan before making edits.

For exploratory work, it helps to keep a markdown cell above each code section explaining what that section tests and what a passing result looks like. Claude Code can update those cells when it changes the code, keeping the notebook's own documentation accurate.

Running cells and checking execution

Claude Code can run shell commands, including jupyter nbconvert --to notebook --execute. This re-runs all cells and saves the outputs. For a single-cell check, it can run a Python script or use the %run magic to execute the notebook from the command line.

After execution, ask Claude Code to check the outputs for errors, unexpected shapes or out-of-range values. A result that looks reasonable in a summary can hide a bug in an edge case. Ask it to state what it confirmed and what it did not check.

Track which cells were actually re-run versus which still show older outputs. Claude Code can add a timestamp or version comment to a cell to record when it last ran, making the audit trail clearer.

Reproducibility and consistent results

A notebook that runs cleanly in one environment may fail in another. Random seeds, library versions, local data files and kernel state all affect reproducibility. When Claude Code helps you debug a result, ask it to flag every assumption about the environment.

A standard first cell that prints the library versions and the random seed makes the environment explicit. Claude Code can generate this cell. If a result changes between runs, this cell is the starting point for diagnosis.

For a notebook that is meant to be shared, ask Claude Code to run it in a clean kernel (restart and run all) before you share it. A notebook that runs cleanly from the top is far more useful to the next person than one that depends on a variable set in an earlier exploratory session.

Recording findings and lessons

An experiment notebook accumulates decisions: which model architecture was tested, which hyperparameter range was explored, which preprocessing step was added after a bad result. Those decisions matter the next time someone opens the notebook — or when a different person starts a related experiment.

Ask Claude Code to summarize the key decisions and findings at the end of a working session. Record those in fenbs as task notes or lessons. "We tried batch sizes 32 and 64; 64 overfit on the validation set with the current dropout rate" is useful. A general "tried various settings" is not.

When a session surfaces a surprising result or a trap to avoid — a data leakage issue, a metric that looked good but was not, a preprocessing order that matters — record it as a lesson linked to the project. The next experiment reads those lessons before starting similar work. The same mistake stays in the record, not just in memory.

How to do this with fenbs

1. Create a free account and add a project for the research or analysis work.
2. Add a task for the current experiment. Note the hypothesis, the data source, and what a successful result looks like.
3. Connect Claude Code from Integrations. Ask it to read the project context, including any earlier experiment lessons, before it opens the notebook.
4. After each session, ask Claude Code to save findings as context notes and any surprises as lessons in fenbs.
5. When you start a new experiment, ask Claude Code to check the lessons from earlier ones first.

For more on how Claude Code handles files and sandboxing, see Claude Code sandbox and Claude Code checkpoints.