JupyterLab Desktop wraps JupyterLab in Electron and adds a jlab launcher

The app is an Electron shell that carries its own JupyterLab

Most of what a reader calls "Jupyter on the desktop" is a server plus a browser pointed at localhost. JupyterLab Desktop takes a different route: the interface lives in an Electron window, and the Python side is installed and managed inside the application rather than in a conda environment you assembled yourself. The repository says exactly that in one line, calling it the cross-platform desktop application for JupyterLab and the quickest way to get started with notebooks on a personal computer, while leaving room for advanced use cases.

The code layout backs this up. package.json carries version 4.6.4-1, names the entry point as the main process, sets the start script to electron ., and keeps separate scripts for bundling the preload layer through webpack, compiling TypeScript with tsc, and running unit tests under vitest and end to end tests under playwright. A preload bundle is its own artefact, which is the usual shape for an Electron app that wants the renderer sandboxed rather than handing Node to page content. The top-level tree also holds env_installer/, workflow_env/ and python-env-management.md, so the Python provisioning path is a first-class part of the repository rather than an afterthought bolted on at release time.

What that buys you is a launcher with no server to start by hand and no browser to configure. What it costs is an application bundle that wraps a browser engine around a notebook editor, so memory use and window behaviour follow Electron rather than your system browser.

One root directory per launch, and the launch method picks it

The file browser root is not a fixed setting. The README ties it to how the app was started, which is a detail worth reading twice because it decides where your first notebook lands. Launching from the application icon, or running jlab with no arguments, sets the root to the default working directory, which is the user home directory and can be changed from the Settings dialog.

Double clicking a .ipynb file, or passing a file path to jlab, sets the root to that file's parent directory and opens the file. The same happens with the Open... and Open File... links on the Start section and with drag and drop. Passing a directory path, or using the --working-dir argument, sets that directory as the root. Three inputs, three different roots, no prompt.

The catch for a new user: home directory as the default root means the file browser opens on your entire home folder, so the first thing you see after install is a very large, very unfiltered listing. Fixing it means opening Settings and changing the default working directory before you start creating files, not after.

Sessions, projects and recent sessions are three different things

The documentation uses project and session almost interchangeably, and that overlap is the sharpest edge in the model. A session, per the README, is either a local project launch or a connection to an existing JupyterLab server, and each JupyterLab UI window maps to one. A project is a launch in a different working directory, and a project can carry its own configuration such as Python environment and UI layout. So a window is not a project, and a restored session restores that configuration.

Start options on the Welcome page divide along the same lines. New notebook... creates a file in the default working directory. New session... starts a JupyterLab session there. Open... starts a session in a chosen directory and opens any selected files in it, and on Windows and Linux the folder and file pickers appear as separate entries. Connect... attaches to a server running locally or remotely, and locally running servers are detected and listed in that dialog.

Restoration is a list, not a tree. Previously opened sessions are kept as part of application data and shown under Recent sessions on the Welcome page, and clicking one brings it back with its configuration. Nothing in that description says what happens when a restored session points at a Python environment that has since been deleted or moved.

Installing is a choice of package format, and Linux gets Snap first

The install table is organised by distribution rather than by a single instruction. Windows 10 and 11 have an x64 installer. macOS 12+ has separate arm64 and x64 disk images, one for Apple silicon and one for Intel. Linux covers Ubuntu 18.04+, Fedora 32+ and Debian 10+, and the recommended entry for that column is the Snap Store listing, with .deb and .rpm x64 installers offered alongside it.

On Windows the package is also reachable through winget, which is the shortest path if you already manage machines with it:

winget install jupyterlab

That command installs the package by its winget identifier; the README states it plainly and gives no extra flags. Elsewhere the README links installer files from the latest GitHub release, plus the Snap Store listing on Linux. If a previous copy is on the machine, the README points at a separate uninstall section in user-guide.md rather than describing removal inline.

The jlab command line is where the launch modes become explicit

Everything the GUI can do by opening files, the command line states as arguments, and the examples are short enough to read as a specification. A bare jlab . launches in the current directory. Paths work relatively or absolutely, so jlab ../notebooks and jlab /Users/username/notebooks both open a directory. File arguments open that file, including jlab ../test.py for a Python file. The --working-dir argument sets the root without opening anything from it.

Choosing the interpreter is a flag rather than an activated shell, which is the practical reason to reach for the CLI at all:

jlab --python-path /Users/username/custom_env/bin/python ../notebooks/test.ipynb

That launches the notebook against an interpreter you point at, no activate step. Connecting to a server you already run is the same command with a URL:

jlab https://example.org/lab?token=abcde

The CLI documentation lives in cli.md rather than the README, so anything beyond these examples, including the full option list and exit behaviour, has to be read there.

Where the Electron route breaks down

The bundle owns its Python. The jlab --python-path option launches a notebook against a custom Python environment, and the repository carries python-env-management.md on environment handling.

The app can also connect to an existing JupyterLab server running locally or remotely, but the README's launch and session sections do not address proxying, TLS or multi-user access, which is expected for a personal application and worth stating plainly before you evaluate it for anything else.

Against the browser route and the VS Code route

The ordinary alternative is pip installing jupyterlab and opening it in a browser, inside a Python environment you control. The difference in approach is ownership: the Electron build bundles its interpreter, while the pip route uses whichever Python is active, so the two can drift to different package sets on the same laptop. Anyone who already manages environments will get more from the pip install, and anyone who does not will get more from the installer.

The other alternative is the VS Code route, running notebooks in an editor tab with the Jupyter extension. There the notebook is a document inside an editor with the surrounding project files visible in the same window, where JupyterLab Desktop puts the notebook in a file browser with the filesystem as its root. Extensions are also handled differently: the README has a section on JupyterLab extension support.

Choose by where your work already lives. A data exploration directory that opens as a project in JupyterLab fits the desktop app. A code repository you edit in an editor fits the editor.

Editorial conclusion

Adopt JupyterLab Desktop if you want the JupyterLab interface on a personal Windows, macOS or Linux machine without managing conda, pip or a server process yourself, and if you are willing to let the application own the interpreter underneath. The repository is not archived and its last push landed on 2026-10-27. Do not adopt it for a shared or multi-user server, or for a machine where IT provisions Python through a locked image. Before installing, open one existing notebook and list the packages it imports, then compare that set against what the app managed environment provides. If the interpreter does not match, the fix is manual and it happens after install, not before it.

Frequently asked questions

Official sources

1. Issues
2. jupyterlab/jupyterlab-desktop on GitHub
3. License: BSD-3-Clause
4. README
5. Releases