After extensive comparative analysis of the default security postures in both OpenHands and Aider, our team has reverted to Aider for active development on a legacy monolith. The decision, while seemingly a regression from a hardened configuration standpoint, was necessitated by OpenHands' stringent default sandboxing, which proved incompatible with the non-standard build and execution patterns inherent to our older system.

The core issue lies in the fundamental architectural philosophy: OpenHands adopts a default-restricted, zero-trust posture for agent-executed commands, whereas Aider operates with a default-open, trust-the-user model. For greenfield projects adhering to modern containerized workflows, OpenHands is superior. However, legacy codebases often require orchestration of bespoke scripts, direct package manager calls outside of declared environments, and interactions with local daemons. OpenHands' sandbox, likely leveraging namespace isolation and seccomp-bpf filtering, systematically blocked these necessary operations.

Our primary pain points manifested in the following scenarios:

* **Build System Integration:** The legacy build process involves a series of chained Python and shell scripts that modify the `PATH` and `LD_LIBRARY_PATH` dynamically. OpenHands' sandbox prevented these environment variable injections, causing consistent "command not found" failures.
* **Local Service Dependency:** The application requires a connection to a locally running, unauthenticated Redis instance on a non-standard port for a specific data transformation step. The sandbox's network filtering appeared to block this loopback communication, despite our attempts to configure allowed hosts.
* **File System Access Patterns:** Several scripts write temporary artifacts to sibling directories outside the declared project root, a pattern we are not currently positioned to refactor. The sandbox's filesystem jail correctly denied these writes, halting the pipeline.

We attempted to configure the OpenHands sandbox policy, but the documentation for advanced profiles is sparse. The apparent requirement to define an exhaustive allow-list of binaries, arguments, and network endpoints was untenable given the complexity and fluidity of our legacy dev environment. In contrast, Aider's model, which essentially runs with the user's permissions, presented no such barriers.

This experience raises a critical question for the community regarding the security trade-offs in self-hosted agent environments: **How are teams managing the gap between ideal, restricted agent execution and the pragmatic needs of brownfield development?** Is the prevailing strategy to:
* Dilute the sandbox policy to near-permissiveness, accepting the risk?
* Invest in substantial refactoring of the legacy codebase to conform to the sandbox's expectations before agent adoption?
* Or, as we did, regress to a less restrictive agent, compensating with other controls like network-level segmentation and rigorous code review on the agent's outputs?

I am particularly interested in any documented patterns for creating graduated or learning sandbox policies that can be relaxed incrementally based on observed, legitimate needs, rather than requiring a complete and perfect policy definition upfront.

- Lei