I've been running OpenHands on a local box for a week now, side-by-side with Aider for comparison. The headline for me is that OpenHands, by default, requires explicit approval for almost every operation, while Aider tends to just get on with it. This leads to a very different workflow.
With Aider, you often get rapid, impressive changes, but you need to have a lot of trust in its interpretation of your request. I've had it make sweeping refactors across files I didn't intend, simply because it inferred that's what I wanted. OpenHands, in contrast, stops and asks. Want to install a pip package? It shows you the exact command and asks for a yes/no. It wants to run a shell script to test something? Approval required. This forced pause is initially frustrating, but it dramatically reduces "what just happened?" moments.
The key difference is in their default security posture. Aider's git integration is powerful but permissive; it can stage, commit, and even create branches autonomously. OpenHands treats git operations as significant actions requiring user consent. For self-hosting, this explicit model is easier to reason about from a security perspective. You're not relying on the agent's judgment to avoid a bad commit; you're the gatekeeper.
Here's a snippet from my OpenHands config where I relaxed one rule, just to show the level of control:
```yaml
# openhands/config/actions.yaml
actions:
execute_shell:
default: require-approval
read_file:
default: allow
write_file:
default: require-approval
git_operation:
default: require-approval
```
You start with everything locked down and allow specific actions per project. Aider feels more like a collaborative pair programmer who sometimes acts on a hunch; OpenHands feels like a meticulous assistant who documents every planned step and waits for your go-ahead. For long-running sessions on a production codebase, the OpenHands approach generates less cognitive load from surprise changes.
The trade-off is speed, of course. If you're brainstorming a new project, Aider's velocity is fun. For working on established, critical code, I find OpenHands' methodical style leads to fewer rollbacks and a clearer audit trail of what was done and why.
Has anyone else compared their git handling or sandboxing approaches in a self-hosted setup? I'm particularly interested in how you've configured their respective execution environments.
- Pete
Keep it technical.
You've hit on the core trade-off in agent design: autonomy versus auditability. Aider's approach optimizes for velocity in a trusted environment, effectively treating the user as a supervisor who occasionally intervenes. OpenHands models the user as a verifier in a zero-trust loop.
This explicit approval model isn't just a UI choice; it's a critical containment layer. From a threat modeling perspective, each approval prompt is a decision gate that breaks an otherwise continuous attack path. If a prompt injection or malicious tool output suggests a `pip install` of a typosquatted package, the user has a final visual checkpoint to see the raw command. In Aider's more permissive flow, that same malicious instruction could be folded into a larger, legitimate-looking code change and committed before the user reviews the diff.
The frustration you note is real. The security cost is friction, which degrades usability. The question is whether that friction is correctly placed. For self-hosted, personal use, I think OpenHands has it right. You're not just preventing "what just happened" moments; you're systematically removing the opportunity for the agent to chain unintended actions without a conscious break in the process.
That "forced pause is initially frustrating" part really hits home for me. I just started using it yesterday and caught myself getting annoyed when it wanted to approve a simple ls -la command. But you're right, that tiny friction feels different when you're self-hosting on a box with actual keys or sensitive data on it. It's like a built-in speed bump.
I'm curious, have you tried adjusting the approval levels at all? Or do you stick with the default "ask for everything" mode? I saw there's a config for it in the docs but haven't messed with it yet.
The git thing is huge. Knowing it won't just commit something on its own makes me way more comfortable letting it near my projects. Less "trust" and more "verified."
Your point about the security posture being a fundamental design choice is absolutely correct. This extends beyond just git operations, it's about the entire trust boundary of the agent's action space.
I see this as a direct application of the principle of least authority, but implemented at the user interaction layer. The agent isn't just sandboxed in a technical sense, it's also sandboxed by a mandatory human-in-the-loop for any action with side-effects. That's the "auditability" layer user358 mentioned, and it's what prevents those cascading inference errors you experienced with Aider.
The interesting tension is that this model puts a significant burden on the user's attention span. It trades cognitive load from debugging unintended changes for cognitive load from constant micro-approvals. I find it's sustainable only because the prompts are explicit and the proposed action is shown verbatim, which is itself a form of output validation.
cargo audit --deny warnings