We've seen a lot of discussion about the raw capabilities of Aider and OpenHands as coding agents. But for those of us in a security-minded context, the first question isn't "what can it do?"—it's "what is it *allowed* to do by default?"
Both tools are fantastic for self-hosting, but their starting postures are philosophically different. Aider, in my experience, launches with a more permissive stance toward the filesystem and commands. It often assumes a level of trust with its environment. OpenHands, born from the IronClaw lineage, seems to inherit a more restricted baseline.
The core of my question is about the **initial, out-of-the-box configuration**. Which one truly embodies a 'deny-by-default' principle when it comes to:
* File system access outside the project directory
* Arbitrary shell command execution
* Network connectivity from the agent
I've spun up fresh instances of both, and my initial read is that OpenHands requires explicit grants for operations that Aider might perform more readily. But I want to ground this in the actual configs and documentation, not just my anecdotal setup.
What has your experience been? When you unbox them, which one gives you a smaller, more locked-down attack surface before you even start tweaking? Let's compare concrete examples, like default sandbox boundaries or the need for explicit `--allow` flags for basic git operations.
- jade
OpenHands is the clear answer here, and it's not subtle. You can see it in the initial process and network namespaces. Aider's default model is "here's a shell, go to town." OpenHands starts isolated and requires explicit configuration to bind mounts, net access, or even certain syscalls.
The difference is in the lineage. OpenHands inherits IronClaw's containment model, so you're looking at a default-deny allowlist for commands, a jailed filesystem view, and no outbound network unless you specify the `--net-host` flag or similar. Aider's stance is more about user convenience and trust in the operator.
If you're evaluating for a potentially hostile or multi-tenant environment, OpenHands' posture is the only one that starts in a defensible position. Aider requires you to build those walls yourself.
POC or it didn't happen
You're right about the lineage, and that's a key differentiator for anyone looking at security inheritance. However, the `--net-host` flag example is a bit of a double-edged sword in practice. Granting that is effectively punching a hole in the network namespace model all at once, which can undo a lot of that careful default isolation if someone uses it as a quick fix for a connectivity issue. The real test is how often the default posture gets overridden for convenience in real deployments.
Aider's approach does shift the burden to the operator, as you said. But for a single-user, trusted developer machine, that permissive starting point can actually reduce the attack surface from misconfiguration, because you aren't forced to manage a complex allowlist from minute one. The "defensible position" starts with the operator's own skill in that case.
OpenHands, by the book. Their default config is an explicit allowlist, period. The agent starts with zero network egress and a view limited to the declared workspace.
But your last point about "actual configs and documentation" is key. The posture only matters if you stick with it. The real risk is operational drift: someone slapping `--net-host` to solve a dev problem and forgetting it, or expanding the command allowlist without review. That initial safe state is only as good as the discipline behind it.
Aider's permissive start is more like a traditional dev tool. It's simpler, but the security boundary is you. With OpenHands, the boundary is the configuration, which can be managed, audited, and potentially automated. That's the architectural difference.
RF