llm-sandbox's manifest reads 0.3.13 while the index is at 0.3.45

The manifest reads 0.3.13 and the newest release is 0.3.45

The project metadata in the repository declares version 0.3.13. The newest published release is 0.3.45, tagged on 2026-09-28, three days before the last commit on the default branch. The release description for that newest tag is one sentence: a security fix for sandbox archive extraction. In a library whose job is unpacking archives that a model produced, that is the most important sentence in the file, and it is attached to a version the repository does not claim to be. The middle release adds its own oddity, since 0.3.43 and 0.3.44 were published on the same morning three hours apart. The practical consequence is narrow but real: installing from a clone gives you code from a much older line than installing from the index, and the only place the difference is visible is by comparing two files.

One runtime dependency, and six extras for the backends

The base install is genuinely small. The declared runtime dependency list holds a single validation library, and everything else is opt-in, starting with the plain package:

pip install llm-sandbox

The extras come in two sets of three. One set covers the backends, one for Docker, one for Kubernetes, one for Podman, which the page describes as rootless containers for extra security. The second set covers the same three backends again, each adding the model context protocol library. So a user who wants the plain session on Kubernetes and a user who wants the agent server on Kubernetes install different packages, and there is no combined extra for the server. The server itself is declared as a console script pointing at a module inside the package, and the registry name sits in a comment on the first line of the readme rather than in the metadata.

Four backend mechanisms in the examples, three in the features

The feature list names three backends. The examples directory adds a fourth: alongside one file per named backend there is a code runner built on micromamba, which the page never mentions. The rest of that directory is more revealing than the feature list. There is a demonstration of running with container user privileges, and a demonstration of a read-only filesystem on Kubernetes, which between them are the two files anyone evaluating the isolation claims should read first. There is also a demo of attaching to a container that already exists, which is a different threat model from starting a fresh one, a file-copy demo in both directions, a tool wrapper example, a demo about a package-manager warning, and several about artifact capture. The examples are where the security posture actually lives.

Six languages for a session, one for an interactive kernel

The multi-language claim covers Python, JavaScript on a Node runtime with npm, Java with Maven or Gradle, C++ with compilation, Go with modules, and R with packages from its statistical repository, and each call takes a list of libraries to install. The interactive session is a separate class with a narrower promise. It spins up a long-running kernel inside the sandbox so that each call behaves like a notebook cell, with state, imports and magic commands surviving until the context manager exits, and a history size you set. It is documented as supporting all three backends and targeting Python only. So the two claims do not overlap: a workflow that needs to run Go and then keep a Python session warm is two classes, not one.

R is the one language that needs a named image

Every language example relies on the default image except one. The R session passes an explicit image reference and turns on verbose output, and the reference's name encodes both a specific language version and a specific distribution release, which is the pattern you would expect for a statistical runtime with a heavy base. That is a sensible design decision and also the sharpest edge in the quick start, because a user on a different version of that language has to edit a container reference inside their own code rather than pass a version argument. The R example is also the one the page cuts short, ending partway through a data frame literal after two of its columns, so the closing syntax of the longest example on the page is not shown.

Pooling gets six demos and its trade-off gets none

The advanced features are artifact extraction for plots and visualisations, installing dependencies at call time, copying files in and out, custom images, a fast production mode that skips environment setup for faster container startup, and container pooling, which the page marks as new. Pooling pre-warms containers and reuses them, and the examples back it harder than anything else on the page, with separate demos for basic use, concurrency, artifact handling, a Kubernetes deployment and monitoring. What the page does not say is the obvious cost. A reused container is a container that carried state from its previous tenant, so the value of pooling for a code interpreter depends entirely on whether the runtime is reset between runs. The security section's claims about isolation say nothing about reuse, and the fast production mode that skips setup is a second feature in the same area with the same gap.

A research artefact with a DOI and a paper directory

The repository root is arranged like a published study rather than a library. There is a paper directory, a digital object identifier in the project metadata pointing at an archive, and a citation file, alongside a benchmarks directory. Quality is wired to more than one external service: a coverage service configuration, and a code-quality service named in two separate property files, plus a security linter configuration and a security policy. There are also two instruction files for two different coding assistants. The build system has three runners, a Makefile, a lock file, and a tox configuration, and the Makefile's check target is the interesting one: it verifies the lock file still matches the project file, runs the whole pre-commit suite, type-checks, and then runs a checker built to find dependencies that are declared but unused.

Publishing has no version check

The publish path is short. One target removes the distribution directory and builds a wheel through an ephemeral builder, the next uploads it through an ephemeral uploader pointed at the legacy package index upload endpoint, and a third does both in sequence. None of them reads or writes a version. There is no step that compares the manifest version against a tag, and no step that bumps anything, which is the mechanism you would expect to be missing if the project file in the tree is thirty-two patch versions behind the index. For a library whose release notes include a security fix, that is the single most useful thing to add, and it would have taken one line.

Editorial conclusion

For what it does, this is a well-shaped library: one dependency at the base, backends and the agent server as separate extras, and an isolation story that is configured rather than assumed. Two things decide whether it is safe for you. Install from the package index rather than the repository, because the tree's manifest is a long way behind the published artefact and the gap includes a security fix. And decide for yourself whether pre-warmed pooled containers are acceptable, since a reused container is a container that kept whatever state it was created with.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vndee/llm-sandbox on GitHub