Docker execution becomes an explicit workspace path
OpenHands published Agent Canvas 1.21.0 on 22 September with a new path for requesting Docker execution workspaces from Docker servers. The release moves more of the execution decision into the backend rather than assuming that an agent conversation will run directly on the local host. It also adds host-service advertisement for Docker conversations and fixes stale conversation-history merges, Forgejo host lookup, GitHub tree URLs used as app sources and static assets after Canvas rebuilds.
The change follows version 1.20.0, published five days earlier, which added selection of the secrets available to an agent profile, let automations select saved agent profiles and forwarded Docker conversation runtime settings. Taken together, the two releases make profile configuration and execution placement more explicit parts of the runtime. They do not by themselves establish that every profile or Docker workspace has the same isolation properties.
The release trail and licence are inspectable
OpenHands is MIT-licensed at the v1.21.0 tag. GitHub records the release against commit fc6d890f7b21c71a17de60d50597c00355e235ea and publishes desktop artefacts for macOS on Apple Silicon, Windows, Debian-based Linux and AppImage distributions, each with a SHA-256 digest in the release metadata. That gives outside users a concrete tagged source snapshot and downloadable artefacts to compare.
The release notes also show continued maintainer activity across the runtime rather than a single feature drop. Version 1.21 includes fixes from several contributors and updates the OpenHands SDK and Automation dependencies to 1.49.3 and 1.13.3. Version 1.20 similarly combined profile controls, Docker runtime forwarding and tests around ambient secrets, so the security and execution surfaces are moving alongside ordinary application fixes.
Profile scoping improves control, but host mode remains broad
The profile work in 1.20 can reduce unnecessary credential exposure by letting a saved profile define which secrets are available when an automation or conversation runs. That is useful for reproducibility because a task can be associated with a named execution profile instead of inheriting every credential present in the surrounding environment. The 1.21 Docker-workspace path adds another place where operators can separate execution from the desktop process.
OpenHands' own self-hosting documentation still gives a stronger warning for direct host mode: the agent server can have full access to the machine's filesystem, environment and network. A Docker workspace changes the execution boundary, but its effective isolation still depends on mounts, network policy, daemon permissions and the configuration of the Docker server. The release notes do not claim that Docker execution is a security sandbox, and no independent adversarial test of the new path was reviewed for this article.
What can be reproduced now
The public tags make the core behaviour testable: an operator can pin 1.21.0, create a profile with a deliberately limited secret set, run an automation through that profile and compare direct-host and Docker-backed conversations while inspecting the resulting workspace, network and credential boundaries. The published release artefacts and digests also make it possible to pin the tested desktop build rather than relying on an unversioned installer.
The story is Confirmed because the tagged source, release metadata and licence directly establish what OpenHands shipped. Reliability under long-running conversations, the practical security value of profile-scoped secrets and the isolation achieved by different Docker deployments still need independent testing. Those limits are especially important for coding agents because execution permissions and credential scope determine the impact of a mistaken or malicious tool action.