Just finished setting up both Aider and OpenHands on my local server. The security posture difference is huge and kinda shocking?
OpenHands seems to run everything in a Docker sandbox by default. It's locked down, no network, specific volumes. Aider's default install just... runs in your current environment? It can read and write anything your user can. You have to *opt-in* to the sandbox with `--sandbox` or Docker.
Why isn't this the main talking point? Feels like a big deal for a tool with git and file write access. Is it just because Aider is more established and people trust it? Or am I overreacting? 😅
For self-hosting, this seems like the first thing you'd compare. OpenHands is paranoid-by-default, which I kinda like as a newbie.
Totally noticed this too! I was setting up OpenHands last week and it was a bit of a pain to configure extra bind mounts because the defaults are so locked down. But you're right, that's way safer.
I think it's not talked about because Aider's approach feels more like a dev tool you run manually, like your editor? People run linters and formatters with full access all the time. But once you start letting an agent *autonomously* execute... that sandbox feels mandatory, not optional.
Maybe it's a philosophy thing: OpenHands assumes you're building something that runs on its own, Aider assumes you're sitting there watching it. Still, the risk is real if you let it commit code automatically or something.
Do you think stricter defaults will become the norm as these tools get more powerful?
You're definitely not overreacting. That default permission model is the biggest hidden risk in these tools, especially as they start doing autonomous git commits. I've been logging function call attempts in my own setups, and it's surprising how often an agent will try to read outside the project directory if you don't cage it.
I think it's less about trust and more about inertia. Aider's workflow grew from a CLI tool you run in a terminal you're watching, so the security model matched that. OpenHands was built later, when the "agent that acts on a schedule" use case was clearer, so they started with containment.
But you're right, we should be comparing this first. It's the difference between a hand tool and power machinery - you'd expect the guard to be on by default for the latter.
Injection? Where?
The logging point is key. It's one thing to assume an agent will stay in its lane, but seeing it attempt reads outside the working directory changes the whole conversation. That's not theoretical risk, that's observed behavior.
Your inertia take is spot on. It reminds me of the early days of Docker - folks ran random containers with `--privileged` because that's what the old workflow demanded, until we collectively realized the blast radius. Defaults set the security floor for the whole user base.
Maybe we need to start asking for SBOMs and signed builds from these projects too. If I'm going to run something with that much potential access, I'd like to know what's in it and where it came from. Paranoia builds on itself 😉
Trust but verify the checksum.