Lock down the JupyterLab extension manager by launching it read only or turning it off, using an allowlist of vetted extensions, locking the plugins you want fixed, and installing approved extensions in the image. Users then cannot add code to a shared server from the UI.
Why lock it
The JupyterLab docs warn that an installed extension can run arbitrary code on the server, kernel and browser. In a shared data science environment, an open extension manager lets any user add code to a server that holds shared credentials. See what an extension can reach.
The controls
| Control | What it does |
|---|---|
| Disclaimer gate | Users must acknowledge a warning before installing; acknowledgment persists |
| Read only manager | Shows installed extensions, allows enable or disable, but no install or uninstall |
| Admin disablement | The extension manager and plugin manager can be turned off by an administrator |
| Blocklist | Blocked extensions disappear from search and cannot be installed; installed ones are highlighted in red |
| Allowlist | Only vetted extensions show in search; precedence over a blocklist if both are set |
| Disable | Stops plugins running, though code still loads |
| Lock | Administrators lock a plugin or an extension so users cannot toggle it |
Steps
- Start read only. The docs name a launch option that sets the extension manager to read only. Put it in your server start command.
jupyter lab --LabApp.extension_manager=readonly
- Choose a list mode. For shared servers, an allowlist is the stronger choice, since only vetted extensions can be found. Only one mode is active, and the allowlist wins.
- Lock what must stay on. The docs describe administrator commands to lock a plugin or a whole extension.
jupyter labextension lock my-extension
- Uninstall, do not just disable. Disabling leaves code loaded.
- Bake approved extensions into the image with pinned versions, and give users no way to install at run time.
- Review quarterly. Remove unused extensions.
Limits to remember
The docs say the extension manager does not check compatibility with the current JupyterLab version. They also say listings are not a replacement for isolating the server environment from user controlled kernels in multi user deployments. The recommendation is to run the server in an environment users cannot modify.
Verify
Open the server as a normal user and try to install an extension. Confirm it fails, and that a locked plugin cannot be toggled.
Quick check
Allowlist or blocklist?
For shared servers an allowlist is tighter. If both are configured the allowlist takes precedence, per the docs.
Does read only mode stop kernel code from installing packages?
No. It governs the extension manager. Run the server where users cannot modify the environment.
Safeguard policies and dependency scanning can review the image that bundles your approved extensions. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
