This morning two pieces of agent news landed within hours of each other. GitHub announced that Copilot Workspace now runs multiple specialized agents that coordinate over a shared context window. And OpenHands, the open-source autonomous coding agent, shipped its 1.0 release with production-ready Docker sandboxing, built-in security policies, resource limits, and a plugin system.
The Copilot news is interesting. The OpenHands news is more important, at least if you care about where your code and your API keys live. For the first time, the open option is not a hobby project trailing the commercial agents. It autonomously completes roughly 68% of SWE-bench Verified tasks, which puts it in the same conversation as commercial agents that cost real money per task, and it now ships the safety rails that used to be the excuse for not self-hosting.
I run my own AI agent infrastructure that publishes articles and manages my content pipeline overnight, so this is a topic I care about personally. Full disclosure before we go further: I have followed OpenHands since its early monolithic days and I walked through the 1.0 install while researching this piece, but I have not yet shipped production workloads on 1.0. Everything below comes from the official docs, the SDK paper, and published benchmark data, with my own judgment layered on top.
Here is the setup and lockdown guide I wish existed this morning.
OpenHands 1.0 is not a feature bump. It is a ground-up rebuild around a Software Agent SDK, documented in a paper the team published on arXiv. The old version was a monolith where agent logic, evaluation, and the web app all lived in one codebase. The new version splits into four Python packages with sharp boundaries:
Three design choices in the new architecture matter to you as an operator:
Everything is an event. Every prompt, bash command, file change, and compiler error is an immutable event in an append-only log. This gives you deterministic replay and session recovery. When an agent does something weird at 3 AM, you can replay exactly what happened instead of guessing from a chat transcript.
Components are immutable. Agents, tools, and LLM configs are validated Pydantic models frozen at construction. The only mutable thing is the conversation state. This sounds academic until you have debugged an agent whose config silently drifted mid-run.
Security is a first-class loop, not a checkbox. A SecurityAnalyzer rates every tool call as low, medium, or high risk. A ConfirmationPolicy decides whether the agent must and wait for your approval before executing. With the ConfirmRisky policy, the agent sits in a WAITING_FOR_CONFIRMATION state until a human says yes. That is the exact mechanism the agent-safety people have been asking for, and it is on by default in the stack.
On capability: OpenHands with a frontier model as the backend scores about 68% on SWE-bench Verified, the benchmark of 500 real GitHub issues. For context, Devin 2.0 publicly reported around 45.8%. OpenHands paired with Devstral 24B, an open-weight model, scores roughly 46.8%, which already matches Devin's commercial number.
The CLI path needs Python 3.12+ and uv:
uv tool install openhands --python 3.12
openhands
The first run walks you through LLM configuration and saves it to ~/.openhands/settings.json. Conversation history lands in ~/.openhands/conversations. One migration note from the docs: if you used a CLI version before 1.0, you need to redo your settings, because the configuration format changed with the SDK rewrite.
There is also a binary installer if you do not want Python tooling on your host:
curl -fsSL https://install.openhands.dev/install.sh | sh
That gets the agent running. Do not stop here. Running an autonomous coding agent directly on your workstation with full access is exactly the configuration you should avoid, for reasons I will come back to.
The Docker sandbox is the recommended option, and the docs are refreshingly direct about why: isolation reduces the risk when the agent runs commands, and it makes the environment reproducible across machines.
The official Docker launch command looks like this:
docker run -it \
--pull=always \
-e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
-e AGENT_SERVER_IMAGE_TAG=1.26.0-python \
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands:/root/.openhands \
--add-host host.docker.internal:host-gateway \
--name openhands-cli-$(date +%Y%m%d%H%M%S) \
python:3.12-slim \
bash -c "pip install uv && uv tool install openhands --python 3.12 && openhands"
Two details in that command deserve your attention:
host_path:container_path[:mode]. Mount only the project you are working on:
export SANDBOX_VOLUMES=$PWD:/workspace:rw
Anything mounted read-write into /workspace is fair game for the agent. This is the single most important knob in the whole setup. Mount your home directory and you have handed an LLM a paintbrush for your entire machine. Mount one project folder and the blast radius of a bad decision is one folder.
If you prefer the simpler launcher, openhands serve --mount-cwd mounts your current directory into the sandbox workspace automatically.
Here is the save-worthy part. Self-hosting an autonomous agent is only responsible if you actually constrain it. Work through this list before your first real task:
SANDBOX_NETWORK_DISABLED=true blocks internet access from agent containers. Yes, this breaks tasks that need to pip install or hit APIs. For refactoring, test writing, and code review tasks, the agent does not need the internet, and a sandboxed agent with no network cannot exfiltrate your secrets or download surprises.--security-opt no-new-privileges and --read-only where your workflow allows. These are standard Docker flags, but they matter more here because the container's purpose is to run commands an LLM chose.LOG_ALL_EVENTS=true. Because 1.0 is event-sourced, this costs you little and gives you a complete replayable audit trail of every action the agent took.
One honest gap: the 1.0 core focuses on single-agent conversations. Delegation exists as a blocking parallel tool, but rich multi-agent orchestration is explicitly future work. If your use case is a swarm of cooperating agents, the commercial tools are further along today. If your use case is one capable agent doing real repo work safely on your own hardware, this is your release.
The cost math is the quiet story here. Commercial autonomous agents charge per task on subscription models. A self-hosted OpenHands stack costs roughly $0.20 to $1.05 per resolved task at H100 GPU rates, depending on which model you put behind it, based on published community analysis. That is the agent harness cost. Your model API bill sits on top if you use hosted models, or disappears entirely if you run open-weight models like Devstral on your own GPUs.
And the open-weight path is no longer embarrassing. OpenHands with Devstral 24B at 46.8% on SWE-bench Verified matches what Devin 2.0, a funded commercial product, publicly reported. For internal tooling, dependency upgrades, boilerplate features, and test coverage work, an open model through an open harness at a fraction of the cost is a legitimate production choice in September 2026. For your hardest architectural work, put the frontier model behind the same harness. The harness does not care.
If I were adopting this on my own infrastructure this week, my sequence would be:
I write about AI agents, developer tools, and building with AI every week. Subscribe, it's free, and the next piece in this series will cover wiring OpenHands to open-weight models end to end.
What about you? Have you run OpenHands or another self-hosted coding agent on your own hardware? Did the sandbox hold up, or did you catch it doing something you did not authorize? Tell me in the comments, I read every one.