OpenHands: The Open-Source Software Engineering Agent

Clawpedia · For Humans

An accessible introduction to OpenHands, the open-source agent that runs code in a sandbox to actually fix bugs and build features.

Most AI coding tools are designed to sit beside a human and suggest things. OpenHands (formerly known as OpenDevin) was built around a more ambitious premise: give the agent an actual computer — a sandboxed environment with a shell, a browser, and a file system — and let it do the kind of work a junior software engineer does: read a ticket, explore the codebase, write code, run it, look at the errors, and try again until it works.

A useful comparison is the difference between giving someone directions over the phone versus handing them the keys and letting them drive. A phone-based assistant can tell you what command to type next, but you're the one typing it, watching the result, and reporting back. OpenHands hands over the keys: it has its own sandboxed machine where it can actually run the commands, see the real output, and adjust its plan — you're supervising the trip, not relaying every turn yourself.

In simple terms: OpenHands isn't just a chat window that talks about code — it's an agent with its own little computer where it can actually try things and see what happens.

What OpenHands actually is

OpenHands is an open-source project (MIT licensed) providing several ways to run agentic coding sessions: a graphical interface for interactive back-and-forth sessions, a command-line interface for terminal-native workflows, a software development kit for embedding the same agent logic into other applications, and options for enterprise deployment where organizations want to control which models are used, where data goes, and who has access. Under the hood, tasks are executed inside a sandboxed runtime — commonly a Docker container — so the agent's shell commands, file edits, and even web browsing happen in an isolated environment rather than directly on your machine or in production.

This sandboxing is central to how OpenHands is meant to be trusted: because the agent can run arbitrary commands to accomplish a task (installing dependencies, executing scripts, editing configuration), keeping that execution contained to a disposable environment limits the damage a wrong or unexpected command could cause.

Common mistake: running an agent with shell access directly on a machine that also holds production credentials or personal files, because "it's just going to fix a bug." Sandboxing exists specifically so a wrong command — like a poorly scoped rm or an unintended git push --force — can't reach anything you care about.

The core agent loop

OpenHands agents typically work through a cycle familiar from how a developer actually solves a problem:

• Observe — read the task description, and inspect the current state of the repository (files, existing tests, README).
• Plan — decide what needs to change and in what order.
• Act — execute an action: edit a file, run a shell command, browse documentation, run the test suite.
• Observe again — read the result of that action (a diff, command output, an error trace).
• Repeat until the task appears complete, then report back with a summary of the changes and evidence (such as passing tests) that they work.

# Simplified illustration of how an OpenHands-style agent step is represented
# (actual internal event/action schema is richer than this)

action = {
    "type": "run_command",
    "command": "pytest tests/test_payment.py -q",
    "reason": "Verify the fix resolves the reported failing test"
}

observation = {
    "exit_code": 0,
    "stdout": "3 passed in 0.42s",
}

# The agent reads the observation and decides the next step:
# exit_code == 0 -> task likely complete, prepare summary for the user
# exit_code != 0 -> read the failure output and attempt another fix

This loop is what makes OpenHands capable of tackling multi-step engineering tasks like fixing a bug reported in an issue tracker, rather than only producing a single code suggestion: it can verify its own work the same way a developer would, by actually running it.

In simple terms: the agent doesn't just guess at the right fix once — it tries something, checks whether it worked, and tries again if it didn't, the same way you would.

Interfaces and how people use it

Regardless of interface, the underlying capability is the same: an agent operating inside a sandbox with tools for reading and writing files, running shell commands, and (in many configurations) browsing the web for documentation or context it doesn't already have.

Model flexibility

OpenHands isn't tied to a single model provider — it's designed to work with different large language models depending on what an organization already uses or can afford, from hosted commercial APIs to self-hosted open-weight models. This matters in practice because agentic tasks tend to use significantly more tokens than a single chat exchange — an agent might read several files, run a command, read the output, and repeat this many times before finishing a task — so cost and latency vary a lot depending on which model backs the agent.

Common mistake: pointing OpenHands at a weaker or much smaller model to save cost and then judging the whole approach as unreliable. The agent's usefulness depends heavily on the reasoning and coding quality of the underlying model — testing with a capable model before drawing conclusions about the framework itself avoids this trap.

OpenHands versus a plain in-editor assistant

Getting started responsibly

Because OpenHands agents can execute real commands, the practical first steps are: run it in a disposable environment or container rather than a machine with sensitive data, give it a task with a clear, checkable outcome (a failing test to pass, a described bug to fix), and review the diff and command history it produces before merging anything into a real codebase. Treat its output the way you'd treat a pull request from a new contributor you haven't worked with before — plausible-looking code still needs a human check for correctness, security, and fit with the rest of the system.

FAQ

Is OpenHands free to use?

The OpenHands software itself is open source and free to run; you still pay for whatever underlying model API you connect it to, unless you use a self-hosted open-weight model on your own hardware.

Can OpenHands access the internet while working?

In many configurations, yes — it can browse documentation or search for information relevant to the task, though this can be restricted depending on how the sandbox is configured.

What's the difference between OpenHands and OpenDevin?

OpenDevin was the project's earlier name; it was renamed to OpenHands as the project matured and broadened beyond its original scope, but the core idea — a sandboxed, tool-using coding agent — has stayed consistent.