Marimo VS Code extension
Python notebooks built on LSP and uv
Details
- External ID
- 45982774
- Source
- HN
- Company
- —
- Product
- Marimo VS Code extension
- Website domain
- github.com
- Launched
- Nov. 19, 2025
- Cohort
- —
- Upvotes
- 65
- Upvotes percentile
- 0.8624454148471615
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:25 p.m.
- Updated at
- Sept. 7, 2026, 9:25 p.m.
Description
Hi HN! We're excited to release our VS Code/Cursor extension for marimo [1], an open-source, reactive Python notebook.This extension provides a native experience for working with marimo notebooks, a long-requested feature that we’ve worked hard to get right.An LSP-first architectureThe core of our extension is a marimo notebook language server (marimo-lsp [2]). As far as we know, it’s the first notebook runtime to take this approach. The Language Server Protocol (LSP) [3] offers a small but important set of notebook-related capabilities that we use for document and kernel syncing; everything else is handled through custom actions and messages.By building on LSP, we aim to create a path to expose marimo capabilities in additional environments (beyond VS Code/Cursor). The notebook features in LSP are still limited, but as the protocol evolves, we’ll be able to shift more functionality out of the extension and into the language server, making it available to a wider range of editors and tools. For example, this could enable:- structural edits to notebook documents (e.g., adding or removing cells) [4]- editor hover information that reflects the live runtime values of variablesDeep uv integration with PEP 723Because marimo notebooks are plain Python files, we adopt PEP 723-style inline metadata [5] to describe a notebook’s environment. Tools such as uv already support this format: they read the metadata block, build or update the corresponding environment, and run the script inside it.The marimo CLI already integrates with uv in "sandbox" mode [6] to manage an isolated environment defined by PEP 723 metadata for a single notebook. In the extension, our uv-based “sandbox controller” manages multiple notebooks: each notebook gets its own isolated, cached environment. The controller keeps the environment aligned with the dependencies declared in the file and can update that metadata automatically when imports are missing.uv normally syncs such environments whenever you run a script, ensuring it matches the dependencies declared in its metadata; we apply this concept at the cell level so the environment stays in sync whenever cells run. The same cached uv environment is reused if you run the notebook as a script via uv (e.g., uv run notebook.py).—-------This work has been a complete rewrite, and we're grateful to the community for early feedback. While VS Code and the LSP support a subset of notebook features, the ecosystem has been shaped heavily by Jupyter, and we’ve had to work around some assumptions baked into existing APIs. We’ve been coordinating with the VS Code team and hope our work can help broaden the conversation—pushing the LSP notebook model forward and making room for runtimes that aren’t Jupyter-based.We'd love to hear your thoughts![1] https://marimo.io[2] https://github.com/marimo-team/marimo-lsp[3] https://microsoft.github.io/language-server-protocol/[4] https://github.com/microsoft/vscode-languageserver-node/issu...[5] https://peps.python.org/pep-0723/[6] https://docs.marimo.io/guides/package_reproducibility/
Enrichment
- Theme
- Claude integrations and coding agents
- Vertical
- Horizontal
- Function
- Dev tools
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Hobby / open-source project
- Normalized one-liner
- python notebook environment for vs code
- Manually corrected
- False
Could you build this?
Partial While basic VS Code extensions are straightforward to vibe-code, implementing a reliable Language Server Protocol (LSP) notebook integration with reactive execution semantics requires significant systems programming.
What it would actually take: The architecture pairs a TypeScript VS Code extension (implementing the VS Code Notebook and LSP APIs) with a high-performance Python daemon managing Marimo's reactive dataflow graph and uv package management. The complex part is maintaining bi-directional real-time sync between the reactive DAG state, cell dependency topology, virtual document LSP mappings, and language server diagnostics.
Discussion
5 comments analyzed.
Competitors mentioned: PyCharm, VSCode
Feature requests: PyCharm plugin
Competitors
Other products that read as similar to this one — 42 launches clear the similarity bar, closest 8 shown.
Attention rank: #7 of 43 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 11 days after the earliest competitor.
- Marimo pair · hn · 2026-04-07 · 140 upvotes · similarity 0.57
- Fluent Notebook — Python in your browser · ph · 2026-09-14 · 1 upvotes · similarity 0.39
- Tracecast · hn · 2026-05-18 · 6 upvotes · similarity 0.38
- Xpandas · hn · 2026-03-02 · 6 upvotes · similarity 0.36
- PicoFlow · hn · 2026-01-21 · 11 upvotes · similarity 0.35
- I created a RAW to HDRI stacker in (mostly) Common Lisp · hn · 2026-06-05 · 35 upvotes · similarity 0.34
- LUML · hn · 2026-02-03 · 7 upvotes · similarity 0.34
- btrc · hn · 2026-03-02 · 5 upvotes · similarity 0.33
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a dev tools tool for Sales yet.