📦 Support Marimo Sandboxes

The client API remains the Jupyter protocol as implemented in jupyter-kernel-client.

Done

Marimo sandbox: Marimo's reactive cell graph in a Jupyter kernel #35 — the marimo variant (released as 1.9.38 on main): a JupyterServerSandbox whose kernel holds Marimo's dataflow graph (marimo._ast.compiler + marimo._runtime.dataflow), installed by one execute request and asked through others, answering on stdout. run_cell(cell_id, code) registers, runs, then re-runs the dependents in dependency order; register_cell, remove_cell, plan, graph, cells. The same helper source is carried verbatim by @datalayer/jupyter-react for the reactive Notebook, Cell and Output components (jupyter-ui#502).

Marimo reactivity through the Jupyter-shaped API (1.9.39) #38 — reactivity through the Jupyter-shaped API (1.9.39): run_code names its cell through the execution context and answers cell_id and typed reactions (each with its own result); CodeSandboxClient.execute / execute_code / execute_code_streaming take cell_id, replies carry the reactions under marimo with their own Jupyter-shaped outputs, execute_interactive tags every hook message with its cell, streams tag every event, and the graph is reachable through the client. Nothing changes on the wire, so jupyter-kernel-client stays the client API and a consumer that only reads replies and streams — the Datalayer MCP server's execute_code, for one — sees every cell that changed.

code-sandboxes 1.9.39 is released (tag → PyPI): Reaction/cell_id on results, marimo in Jupyter-shaped replies, stream tags, and MarimoCells, the driver over any client.
The Datalayer MCP Server now offers a marimo toolset (/mcp?marimo, image 0.0.34, services #545): marimo_run_cell, marimo_run_code, marimo_plan, marimo_graph, marimo_remove_cell over MarimoCells on the sandbox the session already holds. Drilled on the live gateway: a named cell re-ran its dependent, which printed the new value.