Can someone review the PRs that slim down the agent-server image for OSS/Canvas? Umbrella issue: github.com/OpenHands/software-agent-sdk/issues/4643 No published image changes contents. Enterprise, Replicated, cloud, and evaluation/benchmarks all consume agent-server:<v>-python, which is untouched. These PRs add a new python-slim variant; nothing consumes it until a follow-up Canvas PR switches over. Two capabilities dominate the size, ACP providers (315 MB) → rely on the existing npx fallback. It already existed and was version-pinned, but wasn't practical. Now: a persistent npm cache shared across conversations, --prefer-offline, and a visible warm step before the handshake. Measured cold installs are 1–4 s, so a slim user picking an ACP agent gets a brief first-run download and nothing to configure. → github.com/OpenHands/software-agent-sdk/pull/4805 Docker Engine (135 MB) → informative error. dockerd needs --privileged at container start, so nothing can be installed later — a message is the only recovery path. • The tradeoff, honestly: OSS users who run Canvas with --privileged today do have working Docker-in-sandbox, and they lose it. That's undocumented for Canvas (the docs are enterprise-only) and the documented launch can't use it, but it's a real capability loss, not dead weight — details and the open question of how many people this affects: github.com/OpenHands/software-agent-sdk/issues/4643#… • github.com/OpenHands/software-agent-sdk/pull/4808 — the shim explaining absence • github.com/OpenHands/software-agent-sdk/pull/4809 — drops Docker from slim (draft, stacked on #4805) Perhaps not worth merging because of capability loss. Once merged and released, the next step is a Canvas PR pointing at the slim tag.

I will review them.

Not really. But perhaps you can start with ACP? Then the two other PRs go together.

ok the first one seems good. But then you can decide which one you want to download? Or how it would work in cloud?

cloud and replicated images would stay on the heavier agent-server images.

ok good for me

This is the OSS feature loss when removing docker engine. Not sure it's worth it. Asking @calm-artist-7206 since you reacted to the previous feature removal 😛 AI description of feature loss

The capability loss

The agent can no longer run containers inside its own sandbox. Concretely:

- Build a Dockerfile and run it — so when a task involves creating or modifying one, the agent can verify the change works instead of editing it blind
- Bring up a docker compose stack to reproduce a bug or QA a multi-service app
- Use containerized toolchains published only as images
- Run components a user distributes as images

The agent can still edit Dockerfile and compose.yaml — it just can't prove the edit works. On a containerized project it stops at the point where a container is required.

Who loses it: only OSS/Canvas users who add --privileged to their docker run. That's undocumented for Canvas (the docs live under enterprise/), and the documented launch can't use it — but I verified it genuinely works when you do add the flag (daemon 29.7.2 starts).

Why no fallback is possible

This is the crux, and it's a hard architectural limit rather than a missing feature.

Privilege is granted at container start, by the host, and cannot be acquired later. When you run docker run --privileged, the host's Docker daemon creates the container with elevated capabilities — CAP_NET_ADMIN, CAP_SYS_ADMIN, device access. A process already inside an unprivileged container has no mechanism to request them; that's the entire point of the security boundary.

So installing Docker at runtime doesn't help. You'd get the binary and then:

failed to start daemon: Error initializing network controller:
error creating default "bridge" network: operation not permitted

That's the daemon failing to create a network bridge — it needs kernel networking capabilities the container was never given. Nothing you install fixes a capability you weren't granted.

A quick note, as I’m reading through stuff. The

-acp

packages are redistributable. If it’s only these, they are bridges right, they’re fine in or out of the images

yes for those we do have functional fallbacks 🙂 it's more for the docker engine

Yes, sorry, those are related to licensing, and I’m a bit of a copyright freak, couldn’t help it 😅

doesn't matter that much but it's the last hanging fruit in a memory freeing effort 😛 It's just a bit unclear to me if that feature is important at all in canvas. For enterprise I do think it's important (at least its documented)

I think it’s important that the agent is able to run inside docker and yet, run docker itself and spin up containers

OK. As a remark, . The Canvas launch instructions are a plain docker run -p 8000:8000 -v … with no --privileged, and docker-in-sandbox.mdx lives only under enterprise/. So an OSS user has no way to know the capability exists or how to enable it.

Yes, let’s do that, thank you!

doc pr github.com/OpenHands/docs/pull/774 @calm-artist-7206

Docker-in-docker has always had to many issues for my liking. An alternative I've used with OpenHands Local is to patch in the docker socket into the container and start containers in parallel to current. Also no need for privilege in this case. Then you only need to install the docker client command and not whole package. Both ways have headaches to deal with so I guess depends on each persons specific use case.

@strong-ice-84145 I left a comment asking for more context