vscode-jupyter: A Notebook Front End That Does Not Ship a Kernel
VS Code Jupyter extension
At a glance
- What is it?
- Microsoft's Jupyter extension for VS Code provides notebook editing and kernel selection for Python, Julia, R and C#, but it is not a kernel itself and it pulls in four companion extensions on install. Here is what the repository documents, where the design puts the burden on you, and when JupyterLab is the better fit.
- Who is it for?
- Adopt vscode-jupyter if you already live in VS Code and want notebooks, hot exit, find and replace, and editor extensions like Vim working inside cells, and if you accept that you must supply a Python environment with the jupyter package or a matching kernelspec yourself. Do not adopt it expecting a bundled kernel, a standalone notebook server, or a tool that runs without the Python extension if your work is Python.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not running notebooks, it is editing them in a code editor
Jupyter notebooks have always been editable, but the classic interfaces are built around the notebook, not around the code inside it. The README for vscode-jupyter frames the extension's value in exactly those terms: it uses VS Code's built-in notebook support so that users get hot exit, find and replace, and code folding out of the box, and so that editor extensions such as Vim, bracket colorization and linters remain available while a cell is being edited. That is the audience. If you write notebooks as part of a larger software project, keep the rest of that project open in the same window, and want the same keybindings and linters in a cell that you get in a .py file, this extension is aimed at you. If your notebook work is exploratory and self-contained, the same features are less of a draw.
It is a front end, and the README says so in bold
The most important sentence in the repository is a disclaimer, not a feature list: this is NOT a Jupyter kernel, and you must have a Python environment in which you have installed the Jupyter package. That single constraint shapes everything else. The extension supplies the notebook UI, the kernel picker, and the plumbing between VS Code's notebook API and a running kernel process. It does not supply the process. For Python users this means the Python extension and a working environment are prerequisites, not optional companions. For Julia, R and C# users the requirement shifts: the README states that many language kernels work with no modification, but to enable advanced features, modifications may be needed in the VS Code language extensions. In other words, the further you move from Python, the more the experience depends on code maintained outside this repository.
Installing it also installs four other extensions
The README states that the Jupyter Extension will automatically install four extensions by default: Jupyter Keymap for Jupyter-consistent keymaps, Jupyter Notebook Renderers for MIME types such as latex, plotly and vega, and Jupyter Cell Tags plus Jupyter Slide Show for tagging cells and presentations. A fifth, Jupyter PowerToys, is available but explicitly not installed by default. This is worth pausing on. A single marketplace install changes the state of your editor by more than one extension, and in managed or offline environments that behaviour is a deployment question rather than a convenience. The README notes that any of these can be disabled or uninstalled, and that marketplace extensions are subject to the Marketplace Terms of Use. It does not describe what degrades if you remove a specific one, so if you plan to strip them out, test the renderers first: they are the ones responsible for display of non-text output.
Getting from zero to a running cell: the documented path
The README gives a five-step Quick Start for Python. Install VS Code. Install Anaconda, Miniconda or another Python environment in which you have installed the Jupyter package. Install the Jupyter Extension and the Python Extension. Open the Command Palette with Ctrl+Shift+P and run the command Jupyter: Create New Jupyter Notebook. Then select your kernel either through the kernel picker in the top right of the notebook or through the command Notebook: Select Notebook Kernel. For non-Python languages the path is shorter and the prerequisite is different: install VS Code, make sure you have a Jupyter kernelspec installed for the language you want, install the Jupyter Extension, and open or create a notebook. Note the asymmetry. Python users are pointed at a Python environment; everyone else is pointed at a kernelspec. If you are on Python and the kernel picker shows nothing useful, the documented cause is step two, not the extension.
Where the extension stops being the right tool
The clearest failure mode is built into the design: no kernel, no execution. If your environment lacks the jupyter package, the extension can present a notebook and a kernel picker without being able to run anything, and the README places that responsibility squarely on the user. The second limitation concerns language coverage. The README states that the extension provides basic notebook support for kernels supported in Jupyter Notebooks today, and that advanced features for non-Python languages may require modifications in the corresponding VS Code language extensions. That is a soft boundary, not a guarantee, and it means feature parity across Julia, R and C# is not something the repository promises. The third is architectural: because the extension builds on VS Code's built-in notebook support, the editing experience is bound to VS Code's notebook API and its release cadence rather than to the extension's own. If you want a notebook interface that behaves identically outside VS Code, this is the wrong layer to adopt.
JupyterLab and this extension solve the same problem from opposite ends
JupyterLab is a browser-based environment whose server owns the kernels and the document model; the notebook interface and the execution backend ship together. vscode-jupyter inverts that. The editor owns the interface, and kernels are discovered from your machine through kernelspecs and Python environments. The practical difference shows up in three places. Setup: JupyterLab is reached through a running server, while this extension is reached through an editor you already have open, provided you have installed the jupyter package separately. Editing: JupyterLab is a notebook application, whereas this extension inherits VS Code features such as hot exit, find and replace, folding, the outline view and breadcrumbs, and lets editor extensions operate inside cells. Remote work: the README documents two browser routes for this extension, a web interface via vscode.dev (including github.dev, reached by typing a period while viewing a repository on github.com) and installation on VS Code in GitHub Codespaces, with Settings Sync as a way to have extensions installed automatically there. That is a different remote story from running a Jupyter server and pointing a browser at it, and which one fits depends on whether your remote environment is already a VS Code remote.
MIT licence, marketplace distribution, and the cost of keeping up
The repository is MIT licensed, which is permissive and places few obligations on how you use or redistribute the code. The practical distribution channel, however, is the Visual Studio Marketplace, and the README notes that extensions installed through the marketplace are subject to the Marketplace Terms of Use. Those are two different sets of terms governing two different things: the source code, and the packaged extension you install. Nothing here is legal advice, and if you are vendoring or repackaging the extension you should read both. On maintenance, the release cadence visible in the repository is monthly, with v2025.8.0, v2025.9.0 and v2025.9.1 appearing across September and October 2025, and the last push to main dated 2026-09-10. A monthly cadence cuts both ways. Fixes arrive quickly, but so do changes to an extension that auto-installs four others and sits underneath your notebook workflow. Pinning a version in a managed deployment is the obvious mitigation, and it is the kind of decision the README does not discuss.
Who should install it, and what to check before you do
Install it if VS Code is already your editor, your notebooks live beside ordinary source files, and you want the editing features the README lists without giving up kernel execution for Python, Julia, R or C#. Skip it if you need a self-contained notebook environment, if you cannot install the jupyter package into the environment you intend to use, or if you are unwilling to have four companion extensions added on your behalf. The verification step is small and specific: create a notebook with Jupyter: Create New Jupyter Notebook, then run Notebook: Select Notebook Kernel and confirm the kernel you expect appears. If it does not, the problem is upstream of the extension, in the environment or the kernelspec, and no amount of configuration inside VS Code will fix it.
Editorial conclusion
Adopt vscode-jupyter if you already live in VS Code and want notebooks, hot exit, find and replace, and editor extensions like Vim working inside cells, and if you accept that you must supply a Python environment with the jupyter package or a matching kernelspec yourself. Do not adopt it expecting a bundled kernel, a standalone notebook server, or a tool that runs without the Python extension if your work is Python. Before committing, verify three things on your own machine: that your chosen environment actually has the jupyter package installed, that the kernel picker lists the kernelspec you intend to use for non-Python languages, and that the four auto-installed companion extensions (Jupyter Keymap, Jupyter Notebook Renderers, Jupyter Cell Tags, Jupyter Slide Show) are acceptable in your environment or can be disabled without breaking your workflow.
Community notes