agent's marimo export to ipynb lost the reactive graph: static cells only

TL;DR

Marimo's reactivity (cells re-running when their dependencies change) lives in the marimo runtime, not in the file, so an ipynb export is necessarily a static snapshot: cells in file order with whatever outputs the last run produced. Keep the .py marimo file as the source of truth and regenerate the ipynb export on every change. If consumers need the reactive behavior, point them at the marimo file or a marimo-hosted app, not the exported notebook.

agent's marimo export to ipynb lost the reactive graph: static cells only

Use this when

• An exported ipynb shows cells and outputs but nothing re-runs when values change.
• An agent's pipeline exports marimo to ipynb for compatibility and downstream users expect reactivity.
• The exported notebook's cell order does not match the reactive dependency order.

Not for this skill when

• The marimo notebook itself fails to run. That is a marimo execution problem, not an export problem.
• An ipynb has out-of-order execution bugs. That is classic notebook statefulness, a different fix.

Steps

1. Confirm the source of truth: locate the marimo .py file the export came from. Expected: the marimo file exists and opens as a reactive app.
2. Re-export after any change: run the marimo export command to regenerate the ipynb from the current marimo file. Expected: the ipynb reflects the latest marimo state.
3. Order the export for readers: marimo exports in dependency order where possible; verify the ipynb reads top to bottom sensibly. Expected: a reader can follow the static notebook linearly.
4. Document the export as a snapshot: add a note (in the marimo file's header and the export pipeline) that the ipynb is a static rendering. Expected: no consumer mistakes the snapshot for a reactive document.
5. For consumers who need interactivity, serve the marimo file directly (marimo run) or export to HTML with marimo's app mode instead of ipynb. Expected: interactive consumers get reactivity; ipynb consumers get a correct snapshot.
6. Wire the export into the agent's pipeline so it regenerates on every marimo change, never by hand. Expected: the ipynb can never go stale relative to the marimo source.

Tool compatibility

marimo 0.9.x and later; ipynb export via marimo's export command; Jupyter notebook 7.x / Lab 4.x for viewing.

Variant phrasings

marimo to ipynb export static

The snapshot phrasing. The export is static by design; regenerate it from the marimo source.

marimo reactive cells lost in jupyter export

The loss phrasing. Reactivity is a runtime property that ipynb cannot carry.

convert marimo notebook to ipynb keeps reactivity

The hope phrasing. It cannot; serve the marimo app for reactivity.

Why it happens

Marimo and Jupyter have opposite execution models: marimo builds a dataflow graph and re-runs cells automatically when dependencies change, while ipynb is a linear document with manually executed cells. The ipynb format has no representation of a reactive graph, so any export is a lossy projection, cells plus last-known outputs in some linear order. Expecting the export to stay reactive is a category error. The healthy pattern is the same as compiled artifacts everywhere: the marimo file is source, the ipynb is a build artifact, and the build runs automatically.

Edge cases / pitfalls

• Hand-editing the exported ipynb creates a fork that the next export silently overwrites. All edits go in the marimo file.
• Cells with side effects (writes, API calls) may execute in a different order in the static export than in the reactive graph. Review the export for order-sensitive cells.
• Outputs in the export are from export time. A reader who re-runs cells manually gets classic notebook staleness, not marimo reactivity.
• Agents that diff the exported ipynb will see churn on every export. Diff the marimo .py source instead; it is the meaningful change.

Provenance

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