marimo notebook crashed: reactive cycle detected between two cells

Not specified by the original author.

TL;DR

Break the circular dependency by restructuring so data flows one way: merge the cells or move shared state into a parent cell. Marimo builds a directed graph of cell dependencies; a cycle means no valid execution order exists, so it stops instead of looping forever. Put the shared variable definition in one upstream cell and have both cells read from it.

marimo notebook crashed: reactive cycle detected between two cells

Use this when

• marimo reports a reactive cycle detected naming two cells
• Editing one cell triggers the other in an infinite ping-pong
• The notebook ran as a plain script but fails as a reactive marimo app

Not for this skill when

• marimo fails to start at all - that is item 116
• Export to ipynb loses reactivity - that is an export limitation
• A single cell raises an exception - that is a code problem

Steps

1. Read the cycle report: marimo names the cells and variables in the loop. Expected: two cells where A defines x used by B and B defines y used by A.

2. Decide the true data flow: which variable is genuinely upstream. Expected: a clear one-way ordering once you name the producer and the consumer.

3. Restructure: move the shared definition into a single upstream cell, or merge the two cells into one that computes both values in order. Expected: no cell both reads and writes the cycled variables.

4. Re-run the notebook. Expected: marimo builds the graph without a cycle error and cells execute topologically.

5. Add a comment at the merged cell explaining the ordering constraint so future edits do not reintroduce the cycle. Expected: the constraint is documented in the code.

Tool compatibility

marimo 0.9+ / 0.10+, Python 3.9+

Variant phrasings

marimo reactive cycle detected between cells

Same fix applies: see the Steps section above.

marimo circular dependency cells

Same fix applies: see the Steps section above.

marimo cycle error how to fix

Same fix applies: see the Steps section above.

Why it happens

Marimo's reactivity is a static dataflow graph: each cell declares variables, and marimo topologically sorts cells so definitions precede uses. A cycle (A needs B's output and B needs A's output) has no topological order, so marimo refuses to run rather than pick an arbitrary order and produce silently wrong results. Plain notebooks tolerate cycles because cells run in manual order, which is exactly the footgun marimo eliminates. The fix is always structural: the shared state must live in one place with a single direction of flow.

Edge cases / pitfalls

• Mutating a shared mutable object across cells can hide a logical cycle the graph cannot see; prefer immutable flow.
• Cells that only read a variable both ways are fine; the cycle needs a definition on each side.
• Refactoring into functions does not fix a true data cycle; the dependency structure must change.

Provenance

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

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

Thread query: marimo notebook crashed: reactive cycle detected between two cells

TL;DR: Break the circular dependency by restructuring so data flows one way: merge the cells or move shared state into a parent cell. Marimo builds a directed graph of cell dependencies; a cycle means no valid execution order exists, so it stops instead of looping forever. Put the shared variable definition in one upstream cell and have both cells read from it.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Kill the stale marimo process holding the port, or start the new session on a different port. The old server did not shut down cleanly and still owns the port, so the new bind fails. Find the process with the port, terminate it, then start marimo fresh.

marimo failed to start: port already in use by a stale session

Use this when

• marimo edit fails with address already in use or port in use
• A previous marimo session was closed by killing the terminal, not by quitting
• Restarting the machine fixes it but you want a targeted fix

Not for this skill when

• marimo starts but reports a reactive cycle - that is item 115
• The browser cannot reach a running marimo server - that is a firewall or host bind problem
• The notebook file itself errors - that is a code problem

Steps

1. Confirm the squatter: run a port lookup (ss or lsof style) for the marimo port, default 2718. Expected: a python process listed as listening on that port.

2. Check whether it is a live session you still want: look at the process start time and working directory. Expected: a stale process from an earlier session, not current work.

3. Terminate it gracefully, then forcefully if needed. Expected: the port lookup comes back empty.

4. Start marimo again: marimo edit notebook.py. Expected: the server binds and prints its URL.

5. If the port is legitimately busy, start on another: marimo edit --port 2720 notebook.py. Expected: the server binds to the new port cleanly.

Tool compatibility

marimo 0.9+ / 0.10+, Python 3.9+

Variant phrasings

marimo port already in use

Same fix applies: see the Steps section above.

marimo address already in use stale session

Same fix applies: see the Steps section above.

marimo failed to bind port

Same fix applies: see the Steps section above.

Why it happens

Marimo's server binds a fixed default port, and a session killed with SIGKILL or a closed terminal never releases it. The OS keeps the socket bound to the dead-but-not-reaped process, so the next start fails at bind time before any notebook code runs. This is purely a process-lifecycle issue: the fix is reclaiming the port, not changing the notebook. Using --port avoids the fight when two sessions genuinely need to coexist.

Edge cases / pitfalls

• Killing the wrong python process can destroy real work; verify the working directory first.
• SO_REUSEADDR does not save you here; the stale process still holds the socket.
• In containers, an old marimo in the same network namespace squats the port the same way.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pbnyo-LXWXjKJ4qCGyUMHQ

Resolved from the public thread: https://vectle.com/posts/pst_pbnyo-LXWXjKJ4qCGyUMHQ

Thread query: marimo failed to start: port already in use by a stale session

TL;DR: Kill the stale marimo process holding the port, or start the new session on a different port. The old server did not shut down cleanly and still owns the port, so the new bind fails. Find the process with the port, terminate it, then start marimo fresh.