OpenHands Just Hit 1.0. Here's How to Run It on Your Own Machine Without Handing Over the Keys

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. What Actually Shipped in 1.0 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: openhands.sdk holds the core abstractions: Agent, Conversation, LLM, Tool, and the event system. openhands.tools provides concrete tool implementations built on those abstractions. openhands.workspace manages execution environments, including the Docker sandbox. openhands.agent_server exposes REST and WebSocket APIs for remote execution. 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 pause 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. Install in Ten Minutes 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 Path: The Default That Should Be Your Default 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: SANDBOX_USER_ID matches your host user. Without it, the agent creates root-owned files in your mounted workspace, and you spend an afternoon with chown. With it, file ownership just works. SANDBOX_VOLUMES controls what the agent can touch. The format is 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. The Lockdown Checklist 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: Enable the confirmation policy. The SDK ships a ConfirmRisky policy that pairs with the LLM security analyzer. High-risk tool calls, think destructive bash commands or anything touching credentials, pause the agent until you approve. You trade a little latency for not discovering deletions after the fact. Cut the network when you can. Setting 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. Harden the container itself. Run sandbox containers with --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. Mount secrets read-only, or not at all. Pass credentials through environment variables referenced from a read-only secrets directory. Never bake them into the workspace the agent edits. The SDK has secrets auto-masking built in; meet it halfway by not putting secrets in writable paths. Turn on full event logging. Set 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. Know the limits of the security analyzer. The SDK paper's own limitations section flags that the LLM-based risk classifier is probabilistic, not a guarantee. Treat it as a helpful reviewer with good instincts, not a firewall. 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 Economics: Why Self-Hosting the Agent Tier Is Now Real 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. How I Would Roll It Out If I were adopting this on my own infrastructure this week, my sequence would be: Week 1: Install the CLI, wire it to my existing model API key, and use it only on a throwaway repository. Read the event log after every session until the agent's decision patterns feel familiar. Week 2: Move to the Docker sandbox with SANDBOX_VOLUMES locked to single project folders, ConfirmRisky enabled, and network disabled for tasks that do not need downloads. Week 3: Trial it on a real but low-stakes backlog: dependency bumps, test coverage, doc generation. Compare resolved-task quality and cost against the commercial agent I would otherwise pay for. 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. Sources OpenHands CLI installation docs OpenHands Docker sandbox docs The OpenHands Software Agent SDK paper (arXiv) AI agent news, week of September 8, 2026 Self-hosting OpenHands cost analysis