JupyterLab Desktop: the Electron app that wraps JupyterLab in a native window

What JupyterLab Desktop actually adds to JupyterLab

JupyterLab itself is a web application. You start a server, open a browser tab, and work there. JupyterLab Desktop is the cross-platform desktop application for JupyterLab, built on Electron, and its job is to remove the server-and-browser step from the common case. The README frames it as "the quickest and easiest way to get started with Jupyter notebooks on your personal computer, with the flexibility for advanced use cases."

The audience is therefore people who want notebooks on a laptop without a terminal ritual: students, analysts, scientists who treat Python as a tool rather than a hobby. The app also registers itself as the handler for .ipynb files, so double-clicking a notebook opens the app and loads the file. That single behaviour is the clearest statement of who this is for. If your normal workflow is ssh into a box, run jupyter lab --no-browser, and forward a port, the desktop app adds little and takes away the remote-first assumptions you rely on.

Sessions, projects and how the working directory is chosen

The architecture separates two ideas. A session is a JupyterLab launch or a connection to an existing JupyterLab server, and each JupyterLab UI window in the app is tied to its own session. A project is a working directory: every launch in a different working directory is a separate project, and projects can carry their own Python environment and UI layout. Sessions are persisted as application data and listed under Recent sessions on the Welcome Page.

The root directory of the File Browser is not arbitrary. It is derived from how you launched the app. Launch from the OS icon or run jlab with no arguments and the default working directory (the user home directory, unless changed in the Settings dialog) becomes the root. Launch by double-clicking a .ipynb file, or pass a file path to jlab, and the file's parent directory becomes the root. Pass a directory path or use --working-dir and that directory becomes the root. Drag and drop follows the same rule.

That rule is worth internalising because it is the main source of surprise. Two notebooks in the same folder open into the same project with the same environment; a notebook one level up is a different project and may resolve a different interpreter. The Connect dialog covers the other direction: it attaches to an existing JupyterLab server, local or remote, and the README states that locally running JupyterLab servers are detected automatically and listed there.

Installing JupyterLab Desktop and opening a first notebook

The README lists installers per platform rather than a single universal download. Windows 10 and 11 get an x64 installer; macOS 12+ gets separate arm64 (Apple silicon) and x64 (Intel) disk images; Linux is covered by a Snap package described as recommended, plus .deb packages for Debian and Ubuntu and .rpm packages for Red Hat, Fedora and SUSE. There is also a winget route on Windows.

winget install jupyterlab

After installation, the app can be started from the OS GUI or from the command line. The CLI entry point is jlab, and the documented examples are path-based launches.

jlab .
jlab ../notebooks
jlab /Users/username/notebooks

The first command launches in the current directory, the second uses a relative path, the third an absolute path. In each case the directory you name becomes the File Browser root for that session, and the session appears in Recent sessions afterwards. If you prefer not to touch the terminal at all, the Welcome Page offers New notebook..., New session..., Open... and Connect... links, with Open Folder... and Open Files... shown as separate items on Windows and Linux.

One packaging detail matters if you are reinstalling: the README points to uninstall instructions in user-guide.md and warns that a previous installation should be removed by following them, rather than by deleting the application bundle alone.

Where the desktop wrapper gets in the way

The most concrete limitation is the coupling between the app and the JupyterLab server it ships. The package version is 4.6.3-1, and the release history in the repository shows a gap: v4.2.5-1 in August 2024, then v4.6.2-1 in July 2026 and v4.6.3-1 in August 2026. Anyone who needed a JupyterLab server version between those points had no desktop release carrying it. If your team pins a JupyterLab version for extension compatibility, the desktop app is the wrong place to enforce that pin; the Connect dialog is the escape hatch, because it attaches to a server you run yourself.

Second, Electron packaging is heavy. The repository ships installers for three platforms and two macOS architectures, and the build scripts in package.json (dist:linux-64, dist:osx-arm64, dist:win-64 and others) exist precisely because each target is a separate artefact. That is cost paid by maintainers and, indirectly, by anyone who wants a fix on an unusual architecture.

Third, the working-directory rule cuts both ways. Because the root follows the launch path, a notebook opened from a downloads folder becomes its own project with its own environment settings, which is rarely what the user intended. There is no documented way to say "always use this root regardless of how I launched", beyond setting the default working directory in Settings.

Finally, the README does not document rollback of an upgrade, and it does not describe what happens to stored sessions when the app version changes. Treat session restore as a convenience, not a backup.

JupyterLab Desktop versus a browser tab versus VS Code

The honest comparison is with the browser, because that is the default JupyterLab experience. Running jupyter lab in a terminal and opening a tab gives you the same UI, the same kernels and the same extensions, with none of the Electron overhead, and it works identically whether the server is on your laptop or a machine in another building. What it does not give you is file association, a dock icon, session restore or a per-project environment picker. JupyterLab Desktop is a bet that those conveniences are worth a bundled runtime.

Against VS Code with the Jupyter extension, the difference is the unit of work. VS Code is an editor that can execute notebooks; JupyterLab Desktop is a notebook environment that happens to have a file browser and a terminal. If you spend most of your time in .py files and open notebooks occasionally, the desktop app is the narrower tool. If the notebook is the artefact you deliver, the reverse holds. The repository's own topics (jupyter, jupyter-notebook, jupyterlab) make no claim beyond notebooks.

There is also a middle path inside the project itself: install the app, then use Connect... to attach to a JupyterLab server you already run. That gets you the native window and file association without adopting the bundled environment management.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-22, one day before this article's reference point, so the project is being worked on. The release cadence is uneven, however: the three most recent releases are v4.6.3-1 (2026-08-26), v4.6.2-1 (2026-07-22) and v4.2.5-1 (2024-08-29). Two releases in two months followed by a roughly two-year gap is a pattern worth knowing before you build a workflow on a specific version.

The licence is BSD-3-Clause, which is permissive and imposes no copyleft obligation on your own code. That is a statement about the licence text, not legal advice; if you redistribute a modified build, read LICENSE and the bundled third-party notices yourself.

Upgrade cost is dominated by environment handling rather than by the app binary. The repository carries python-env-management.md and an env_installer/ directory, which tells you the project treats Python environment provisioning as a first-class subsystem rather than a thin wrapper. That is where version drift will bite: a new app release can change which environment a project resolves to, and the README's project model means the change is per working directory, not global. If you keep several projects on one machine, check each one after an upgrade instead of assuming the default carried over. The repository also documents troubleshooting in troubleshoot.md and CLI behaviour in cli.md, which are the two files to read before filing an issue.

Editorial conclusion

Adopt JupyterLab Desktop if you want a double-clickable notebook environment on a laptop, per-project Python environments without hand-managing conda, and .ipynb files that open in the app rather than a browser tab. Skip it if your work lives on a remote cluster, if you need an editor with deep language tooling, or if you must pin the exact JupyterLab server version your team runs. Before committing, verify that the bundled environment mechanism matches your Python workflow in python-env-management.md, check that your OS version is inside the supported range (macOS 12+, Ubuntu 18.04+, Fedora 32+, Debian 10+), and confirm the app's own version number, v4.6.3-1, against the JupyterLab server version you intend to use.

Frequently asked questions

Official sources

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