Related Pages

Related topics: Reactive Runtime, Dataflow & Cell Execution, Frontend Editor, UI Plugins & CodeMirror Integration, AI Integration, MCP, Deployment & Extensibility

marimo Overview & System Architecture

marimo is an open-source reactive notebook for Python that ships as a single, installable package containing a frontend, a Python runtime, a notebook server, an editor, an export pipeline, and a WASM-compatible distribution. The README positions it as "a reactive Python notebook: run a cell or interact with a UI element, and marimo automatically runs dependent cells (or marks them as stale)," and frames the project as "open-source, reproducible, reactive, shareable, deployable, scriptable, and git-friendly." Source: README.md:1-40

The project targets three execution surfaces: local edit/run via marimo edit, headless / app-mode serving via marimo run, and an in-browser sandbox via marimo run --sandbox plus a Pyodide-based WASM build. All three surfaces share the same notebook format (.py files storing cells as Python code) and the same reactive execution semantics.

Reactive Notebook Model

The defining architectural idea is that a marimo notebook is a pure-Python script whose cell graph is computed statically from the source AST. Each cell is a function annotated with @app.cell, and marimo builds a directed dataflow graph by analyzing the global variable references each cell defines and consumes.

• Cell decoration and registration is exposed through marimo.App in the public API. Source: marimo/__init__.py:1-80
• The decorator and cell-construction logic live in marimo/_ast/app.py, which translates source strings into a list of Cell objects together with their CellId, Ref mapping, and per-cell metadata. Source: marimo/_ast/app.py:1-200
• The dependency graph itself is implemented as a DAG in marimo/_runtime/dataflow/graph.py, where nodes represent cells and edges represent the variable-level dataflow computed during static analysis. Source: marimo/_runtime/dataflow/graph.py:1-120

When a cell's outputs change — either because the user edited it, ran it, or interacted with a UI element it exposes — the runtime traverses the graph and re-runs the descendants of the changed cell, marking any descendant that becomes inconsistent as stale rather than silently skipping it. This eliminates hidden state and out-of-order execution, two of the most common pain points in traditional notebooks. Source: DESIGN.md:1-120

Runtime and Server Subsystems

The Python runtime is responsible for executing cells, maintaining a kernel state per session, and broadcasting updates (cell outputs, UI messages, errors, variable definitions) to the frontend over WebSockets. It is structured around a Kernel class that holds the dataflow graph, a Python executor, and a set of cell outputs. Source: marimo/_runtime/runtime.py:1-200

The server is a Tornado-based ASGI application that multiplexes multiple notebook sessions, handles HTTP requests, WebSocket connections, and notebook save/load. It exposes endpoints for editing, autosave, file management, app-mode rendering, and static asset serving, and it is the entry point for both marimo edit and marimo run. Source: marimo/_server/main.py:1-200

A typical request flow is:

1. The browser loads the marimo frontend (a TypeScript/React SPA bundled with the Python wheel).
2. The frontend opens a WebSocket to the server, identifying the notebook and session.
3. When a user edits a cell, the frontend sends an update message; the kernel re-parses the AST, recomputes the affected subgraph, and streams back output, variable, defs, and stale messages.
4. The frontend re-renders only the cells whose outputs actually changed.

This separation lets marimo run as a long-lived daemon (editor mode), a one-shot script (marimo export), or a WASM module that performs all of the above inside the browser without a Python server process. The recent "LazyStore dual-mode WASM backend" work described in the 0.23.12 release notes extends the WASM path to support both in-memory and persisted storage. Source: pyproject.toml:1-80

Frontend, Editor, and Integrations

The frontend is a React/TypeScript SPA that ships pre-compiled inside the Python package and is served as static assets by the Tornado server. It owns cell rendering, the variable explorer, the dependency visualizer, the data-table component, and the plugin surface for third-party widgets (notably anywidget).

marimo integrates with multiple hosts and ecosystems:

• VS Code: a dedicated extension adds a .py notebook editor with marimo semantics. The community has repeatedly asked for VS Code–level features such as a true "debug cell" command that honors IDE breakpoints (see #1325, 25 comments), which requires coordination between the extension, the kernel, and debugpy.
• PyCharm: the project does not currently ship an official plugin, and #6297 tracks the long-standing community request to run marimo notebooks inside PyCharm with a scratch-file workflow analogous to Jupyter support.
• WASM export: notebooks can be exported as a static, in-browser sandbox via marimo export html-wasm. Local module imports inside an exported bundle are not fully supported today, which is the subject of issue #5488, and the WASM LazyStore backend shipped in 0.23.12 partially addresses the storage half of that problem.
• Agent cells: community issue #3916 tracks upstreaming marimo-agents, an extension that turns plain-text cells into promptable agents backed by LangChain/LangGraph-style runtimes.
• Run-mode UX: marimo run --redirect-console-to-browser forwards Python print output to the browser console, but tracebacks are not yet mirrored there — issue #7246 requests full traceback mirroring.

Distribution and Packaging

marimo is distributed as a single PyPI package (marimo) declared in pyproject.toml, which bundles the Python sources, the prebuilt frontend assets, the WASM artifacts, and optional dependency groups for the LSP server, AI completion, SQL, and various widget integrations (anywidget, wandb, etc.). Because the notebook format is just .py files, version control, code review, and CI all work on marimo notebooks exactly as on any other Python module — a property the README highlights as a core design goal. Source: README.md:1-40

Together these subsystems implement the central promise: a notebook whose execution order is determined by its dataflow rather than by hand, that can be edited locally, shared as a script, served as an app, or exported to the browser.

Related Pages

Related topics: marimo Overview & System Architecture, Frontend Editor, UI Plugins & CodeMirror Integration, AI Integration, MCP, Deployment & Extensibility

Reactive Runtime, Dataflow & Cell Execution

Purpose and Scope

Marimo's reactive runtime is the engine that turns a marimo notebook into an executable dataflow program. Unlike traditional notebooks where cells re-execute only on user request and in source order, marimo automatically re-runs any cell whose referenced variables have changed. The runtime is composed of three collaborating subsystems:

• A dataflow layer (graph.py, topology.py) that models variable definitions, references, and the resulting cell DAG.
• A scheduler (scheduler.py, cell_runner.py) that decides which cells are stale and a CellRunner that evaluates one cell.
• A kernel/runtime (runtime.py, executor.py) that orchestrates runs, manages variable state, and bridges Python execution with the frontend WebSocket protocol.

The design rule "a global variable is owned by exactly one cell" is enforced by this dataflow graph; violations surface as cycle errors at graph-construction time. Source: marimo/_runtime/dataflow/graph.py:1-80

Dataflow Graph and Topology

Graph construction

graph.py defines Cell, Edge, and DataflowGraph. Each cell carries:

• defs: variable names the cell defines.
• refs: variable names the cell reads from other cells.
• cell_id and metadata used by the editor (imports, dotprops).

The graph is built during notebook parsing and updated incrementally when cells are added, removed, or edited. add_cell and delete_cell rewire edges using sets of defs/refs, keeping adjacency lists consistent and recomputing the affected transitive closure. Source: marimo/_runtime/dataflow/graph.py:60-220

Topological ordering and cycle handling

topology.py converts the cell DAG into a topological order and rejects illegal cycles. Two cells that mutually reference each other form a cycle that marimo forbids. The function topological_sort produces a deterministic run order, while find_cycles reports the offending cell ids so the editor can highlight them. Source: marimo/_runtime/dataflow/topology.py:1-110

flowchart LR
  A["Cell A<br/>defs: x"] -->|refs: x| B["Cell B<br/>defs: y"]
  B -->|refs: y| C["Cell C<br/>refs: x, y"]
  A --> C
  UI["Frontend edit<br/>mutates x"] --> A

Reactive Scheduler and Cell Runner

The scheduler

scheduler.py implements Scheduler, the component that reacts to mutation events. When a cell runs and its outputs change, the scheduler:

1. Compares the cell's defs set against the previous run to find stale variables.
2. Walks the graph from the mutated cell along outgoing edges to compute the transitive closure of cells that must re-run.
3. Maintains a priority queue of "dirty" cells ordered by topological rank, so independent cells can run concurrently while dependencies are honored. Source: marimo/_runtime/runner/scheduler.py:40-200

The scheduler also tracks per-cell run history (CellRunResult) and prunes queued cells whose dependencies have failed.

The cell runner

cell_runner.py wraps the executor and converts raw execution outcomes into typed results: RunResult.success(outputs, defs), RunResult.exception(exc) with a serialized traceback, and RunResult.interrupted() for user cancellation. It captures stdout/stderr, applies --redirect-console-to-browser behavior, and emits the structured messages the frontend renders. The traceback-rendering path requested in community issue #7246 ("Traceback browser console logging") lives here: console output is captured per run and forwarded through the kernel's messaging channel. Source: marimo/_runtime/runner/cell_runner.py:30-180

Runtime Execution Loop

runtime.py defines the long-lived Kernel (or Runtime) object held by a WebSocket session. Its main responsibilities:

• Executor glue. executor.py provides execute_cell, which parses the cell source via ast, instruments each referenced variable with __marimo_get__, and runs it inside a controlled namespace. This is how a variable x used in cell B always reads cell A's latest binding. Source: marimo/_runtime/executor/executor.py:50-240
• Run-loop orchestration. When the frontend sends RunCell or RunAll, the runtime calls into the scheduler, drains the resulting queue, and streams each CellOutput back to the client.
• Cancellation. Long-running cells register with the runtime so subsequent edits or stops can interrupt them through threading.Event flags surfaced to the executor. The "debug cell" workflow from issue #1325 reuses the same entry point but routes tracebacks and breakpoints through the active debugger. Source: marimo/_runtime/runtime.py:200-460
• State persistence. Variable bindings are stored per cell so they can be invalidated when the owning cell is edited, preserving the "no hidden state" invariant. For WASM notebooks (issue #5488), the executor installs a meta_path finder that resolves imports from marimo's virtual filesystem, letting the same reactive machinery run under Pyodide. Source: marimo/_runtime/executor/executor.py:240-340

How the Pieces Fit Together

Frontend edit ──► Kernel receives cell mutation
                          │
                          ▼
            DataflowGraph updated (defs/refs)
                          │
                          ▼
            Scheduler enqueues stale-cell closure
                          │
                          ▼
            CellRunner → Executor.execute_cell
                          │
                          ▼
            outputs / errors streamed over WebSocket

Key Invariants

• Single ownership. Every global is defined by exactly one cell; cycles are forbidden. Source: marimo/_runtime/dataflow/topology.py:30-90
• Deterministic reactivity. A cell re-runs iff one of its referenced defs changes, detected by value identity and optional content hash. Source: marimo/_runtime/runner/scheduler.py:90-180
• Isolated execution. Each cell runs in a namespace derived from the graph's bindings, not Python's ambient globals. Source: marimo/_runtime/executor/executor.py:60-150

These invariants are what let a marimo notebook behave like a pure functional program on top of Python while still allowing cells to be edited interactively. They are also why marimo integrates predictably with external tooling (VSCode per issue #1325, PyCharm per #6297): the IDE only needs to drive the same RunCell/RunAll protocol the web frontend uses, and the kernel takes care of propagation.

Related Pages

Related topics: marimo Overview & System Architecture, Reactive Runtime, Dataflow & Cell Execution, AI Integration, MCP, Deployment & Extensibility

Frontend Editor, UI Plugins & CodeMirror Integration

The frontend editor is the React-based notebook surface where users author Python, observe reactive execution results, and interact with UI plugins such as the dependency graph and the data table. It is hosted by MarimoApp.tsx, which mounts the notebook shell, registers top-level providers (state, theming, hotkeys, plugin slots), and routes the cell tree to the editor. Cell bodies are rendered by Output.tsx, which maps a cell's MIME-bundled result to a concrete React component (text, HTML, dataframe-backed data table, plot, etc.). Source: frontend/src/core/MarimoApp.tsx:1-120 and frontend/src/components/editor/Output.tsx:1-80.

CodeMirror Integration

All cell code is edited through CodeMirror 6. The cm.ts module centralizes configuration: it instantiates EditorView, applies shared state facets (read-only, vim/emacs keymaps, theming, language), wires up completion and signature-help providers, and exposes helper builders consumed by cell components. Source: frontend/src/core/codemirror/cm.ts:1-140.

Cell-specific behavior lives in extensions.ts, which composes per-cell extensions: a Python language pack with the marimo dialect, markdown highlighting for mo.md blocks, hover docs, go-to-definition, inline diagnostics streamed from the kernel, an "AI transform" command palette entry, and the marimo-specific decorations that color referenced/unreferenced global variables so users can see what each cell defines and consumes. Source: frontend/src/core/codemirror/cells/extensions.ts:1-200.

A typical cell therefore composes: base extensions from cm.ts + the cell extras from extensions.ts + a placeholder (mo.ui helper hints) when the cell is empty. Editing a cell dispatches a debounced updateCellCode action; saving sends an updateCellCodeRequest over the WebSocket, and the kernel replies with new diagnostics and AST metadata that the same extensions subscribe to.

Cell Output Pipeline & UI Plugins

Output.tsx is the dispatcher for cell outputs. It receives a result envelope { mimetype, data, channel } from the kernel and selects a renderer: text/plain, text/html, text/markdown, application/vnd.marimo+error, image/*, application/json, and the marimo MIME types for tables, plots, and anywidget instances. Errors are rendered with a collapsible traceback and a "copy" action; the community has asked for those tracebacks to also be forwarded to the browser console when --redirect-console-to-browser is active (issue #7246), which would be a small change in this dispatcher. Source: frontend/src/components/editor/Output.tsx:80-220.

Two prominent UI plugins are first-class outputs:

• Dependency graph – dependency-graph.tsx consumes the variable-usage graph that the kernel emits alongside each run. Nodes are global variables, edges are read/write relations, and clicking a node scrolls the editor to the defining cell while highlighting transitive consumers. It is opened from the top bar and uses the same cell-id primitives the editor uses, so navigation stays consistent. Source: frontend/src/components/dependency-graph/dependency-graph.tsx:1-160.
• Data table – data-table.tsx renders tabular outputs (pandas/Polars DataFrames, mo.ui.table) with sortable columns, type-aware filters, pagination, and a "show as code" toggle that re-emits the query as Python. It registers a MIME handler in Output.tsx and shares the selection model with the rest of the notebook so selections can drive other cells. Source: frontend/src/components/data-table/data-table.tsx:1-180.

The plugin boundary is intentionally narrow: an "output" is anything that can render a MIME bundle, which is the same contract anywidget uses. Improving anywidget error messages (PR #10026 in 0.23.12) flows through this same dispatcher.

Architecture & Data Flow

flowchart LR
  A[MarimoApp.tsx] --> B[Cell Tree]
  B --> C[cm.ts]
  C --> D[cells/extensions.ts]
  B --> E[Output.tsx]
  E --> F[dependency-graph.tsx]
  E --> G[data-table.tsx]
  H[Kernel via WS] --> B
  H --> E

MarimoApp owns the cell list and the WebSocket session; cell components own their EditorView (via cm.ts + extensions.ts) and their output slot (via Output.tsx). When the kernel pushes new state, MarimoApp re-renders only the affected cells, preserving editor focus and scroll position. Reactive invalidation is driven by the kernel's graph, which is exactly what the dependency-graph plugin visualizes, so the editor and the graph are two views of the same model. Source: frontend/src/core/MarimoApp.tsx:120-260.

Extending the Editor

New cell behaviors are added by composing extensions in extensions.ts; new result renderers are added by registering a MIME handler in Output.tsx. Top-bar panels (graph, debugger, variables, snippets) plug into the layout slots provided by MarimoApp.tsx, which is the pattern the community has explored for richer integrations such as marimo-agents (issue #3916) and richer debugging affordances like "debug cell" parity with Jupyter (issue #1325). IDE integrations (VSCode, PyCharm – issues #1325, #6297) reuse the same React tree by mounting MarimoApp in a webview and routing kernel traffic through their own runner.

Related Pages

Related topics: marimo Overview & System Architecture, Reactive Runtime, Dataflow & Cell Execution, Frontend Editor, UI Plugins & CodeMirror Integration

AI Integration, MCP, Deployment & Extensibility

Marimo exposes its notebook engine through several interoperable surfaces: a programmatic AI tool layer, two Model Context Protocol (MCP) servers, a feature-rich CLI for deployment, and a lint-rule plugin model that doubles as the AST-walking backbone for the other layers.

AI Tool Layer

The AI surface lives under marimo/_ai/ and is structured around typed, callable tools rather than free-form code generation.

marimo/_ai/_tools/tools/cells.py defines AI-callable operations on the live notebook graph: agents can list, inspect, mutate, and reorder cells while the engine preserves reactivity invariants. Tools are Pydantic-typed request/response models so that any MCP-compatible client or SDK can invoke them safely. Source: marimo/_ai/_tools/tools/cells.py:1-60

# Illustrative shape (paraphrased from the file's tool definitions)
class ListCellsRequest(BaseModel):
    notebook: str

def list_cells(req: ListCellsRequest) -> list[CellSummary]:
    return runtime.graph(req.notebook).cells()

marimo/_ai/text_to_notebook.py converts a natural-language prompt into a runnable marimo notebook. It composes cell definitions, validates each block against the dataflow graph, and returns a notebook object that can be written to disk or opened in the editor. Source: marimo/_ai/text_to_notebook.py:1-50

Community discussion (issue #3916 — upstreaming marimo-agents) shows that this tool layer is the intended foundation for richer LLM-driven workflows, including LangChain/LangGraph-backed "agent cells" that turn a markdown block into a prompt-driven function.

MCP Servers

Two MCP servers ship in marimo/_mcp/ so editors and agents can drive marimo through the standardized protocol:

• marimo/_mcp/server/main.py — the primary notebook server. It exposes resources for notebook state, tools for cell CRUD, and prompts for common editing patterns. Source: marimo/_mcp/server/main.py:1-70
• marimo/_mcp/code_server/main.py — a focused, code-only MCP server. It provides lightweight language-server-style capabilities (completion, diagnostics, formatting) without spawning a full notebook session. Source: marimo/_mcp/code_server/main.py:1-60

┌──────────────────┐    JSON-RPC / stdio    ┌────────────────────┐
│  MCP client      │ ◄────────────────────► │  marimo MCP server │
│  (IDE / agent)   │                        │  (notebook / code) │
└──────────────────┘                        └────────────────────┘
                                                       │
                                                       ▼
                                              ┌─────────────────┐
                                              │  Notebook graph │
                                              └─────────────────┘

This architecture lets editors mirror features like "debug cell" (issue #1325) and capture browser-side tracebacks (issue #7246) by routing through MCP rather than maintaining editor-specific forks.

CLI & Deployment

marimo/_cli/cli.py is the canonical deployment surface and registers subcommands for the full notebook lifecycle. Source: marimo/_cli/cli.py:1-90

For browser-based delivery, WASM exports ship notebooks as static assets. Community issue #5488 flags a current limitation: local module imports are not first-class in WASM exports because bundled files must be valid Python packages. The accepted workaround uses importlib path manipulation. The v0.23.12 release note ("LazyStore dual-mode WASM backend") signals ongoing work to broaden what runs in the browser. Source: marimo/_cli/cli.py:140-210

Extensibility via Lint Rules

Runtime linting is the primary plugin surface for adding new analyses. Rules implement a small protocol — walk the resolved AST, emit diagnostics — and the engine dispatches each rule across every cell of the notebook. Source: marimo/_lint/rules/runtime/branch_expression.py:1-50

branch_expression.py exemplifies the pattern: it inspects branch expressions to flag assignments inside conditionals where the bound name is read elsewhere in the graph, since marimo's reactivity makes such bindings fragile. Because the rule operates on the resolved AST rather than raw source text, it stays accurate after cell re-execution and refactors.

The same AST walk is reused outside linting: AI-tool safety checks consult lint diagnostics before applying a mutation, and the MCP servers forward lint output as resources to the client. This means a new rule is automatically visible to every higher layer.

IDE Integration Outlook

The community has asked for first-class IDE integrations: a PyCharm plugin (issue #6297) and VS Code "debug cell" support (issue #1325). Marimo's strategy is to expose these features through MCP and the CLI rather than maintain per-IDE codebases. Any editor that can host a terminal or a stdio MCP client can adopt the notebook server without depending on marimo's internal APIs. Source: marimo/_mcp/code_server/main.py:50-90

Summary

• AI tools in marimo/_ai/ provide typed, cell-level mutation and prompt-to-notebook generation.
• MCP servers in marimo/_mcp/ expose the same primitives to any MCP-compatible client.
• CLI in marimo/_cli/cli.py orchestrates editing, running, exporting, and MCP launch.
• Lint rules under marimo/_lint/rules/runtime/ double as the AST-walking backbone used by AI and MCP layers, keeping diagnostics consistent across surfaces.

The layers compose: each higher surface reuses the layer below it, so new deployment targets and editor integrations can be added without rewriting the notebook engine.

Doramagic Pitfall Log

Found 14 structured pitfall item(s), including 4 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10056

2. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10076

3. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10079

4. Maintenance risk: Maintenance risk requires verification

• Severity: high
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10034

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/marimo-team/marimo

6. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10084

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10081

8. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/marimo-team/marimo

9. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/marimo-team/marimo/issues/10077

10. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/marimo-team/marimo

11. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/marimo-team/marimo

12. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/marimo-team/marimo

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using marimo with real data or production workflows.

• Server is Down - github / github_issue
• Dark mode not working on deployed server - github / github_issue
• Failed to fetch dynamically imported module lab_00_introduction - github / github_issue
• Marimo handling of navigation when embedded in an iframe - github / github_issue
• Polars Query Plan Visualisation is showing incorrect orientation / relat - github / github_issue
• Standalone HTML export - github / github_issue
• Slides mode: speaker-notes popup stuck at "Connecting…" - github / github_issue
• Sandbox failed: backend start failed - github / github_issue
• data_editor not editable in full screen mode - github / github_issue
• 0.23.12 - github / github_release
• 0.23.11 - github / github_release
• 0.23.10 - github / github_release