[echarles]

A foreign image gets JupyterLab through datalayer, and a sandbox never serves it: it starts jupyter server.

JupyterLab 4.6.5, the latest release, pins dompurify 3.4.16 (GHSA-cg2g-xh64-v4q7, critical, fixed in 3.4.17), in its static bundle and its staging lock. The scan blocks the build and no JupyterLab release moves past it. Deleting the lock alone would pass the scan with the bundle still there, so the package goes.

Tested on python:3.12-slim with the contract's packages, on PyPI's jupyter-server rather than the fork: without JupyterLab, jupyter server starts, /api and /api/kernelspecs answer, and datalayer_core, jupyter_kernels and jupyter_server_nbmodel import. datalayer_ui logs a warning that its extension cannot load; the server carries on.

Not removed: the dompurify inside the @datalayer/ui and jupyter-ai-agents labextensions and the agent_runtimes bundle. With no Lab they are not served by a sandbox, and their versions want their own check.

[Copilot]

🟡 Changes recommended

The uv uninstall command lacks --break-system-packages, causing image builds to fail on supported images with distribution-managed Python, such as Ubuntu 24.04.

1 open issue

• Add uv break-system-packages flag for foreign-image uninstalls · New

What changed in this PR

Removes JupyterLab from foreign sandbox images to eliminate its bundled vulnerable dompurify assets while retaining the Jupyter Server runtime.

Changes:

• Uninstalls JupyterLab after the contract packages are installed.
• Adds a regression assertion for the generated uninstall command.
• Bumps the package version to 1.11.4.

File	Description
tests/​test_environment_foreign_contract_layer.py	Checks that the foreign-image contract uninstalls JupyterLab.
code_sandboxes/​environments/​adapters/​datalayer.py	Adds the JupyterLab uninstall build step.
code_sandboxes/​__version__.py	Updates the version to 1.11.4.

_{Review effort: Balanced}