<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Aider and OpenHands Security - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/aider-openhands-security/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 11:57:40 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Help: OpenHands keeps trying to access my .env files even with isolation on.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/help-openhands-keeps-trying-to-access-my-env-files-even-with-isolation-on/</link>
                        <pubDate>Mon, 29 Jun 2026 21:59:59 +0000</pubDate>
                        <description><![CDATA[I&#039;m running OpenHands locally with Docker, following the default setup. I enabled the isolation options in the config, but I&#039;m seeing it attempt to read `.env` files during a coding task. I ...]]></description>
                        <content:encoded><![CDATA[I'm running OpenHands locally with Docker, following the default setup. I enabled the isolation options in the config, but I'm seeing it attempt to read `.env` files during a coding task. I thought the sandbox was supposed to prevent this.

My `docker-compose.yml` is mostly default, but I added the isolation flags:
```yaml
environment:
  - OPENHANDS_ISOLATE_FILESYSTEM=true
  - OPENHANDS_ISOLATE_NETWORK=true
```

I gave it a simple task: "add a new feature flag to the config parser." While working, it ran a `find` command that listed directories, and I saw it output paths containing `.env.production`. It didn't succeed in reading them, but the attempt is concerning.

Is this expected behavior? Does the isolation only block successful reads, not the attempts? Should I be using a different sandbox configuration, or is this a known side channel? I'm used to Burp where I can see and block attempts outright.

- Mia]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Mia Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/help-openhands-keeps-trying-to-access-my-env-files-even-with-isolation-on/</guid>
                    </item>
				                    <item>
                        <title>Help: OpenHands is failing on projects with complex node_modules symlinks.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/help-openhands-is-failing-on-projects-with-complex-node_modules-symlinks/</link>
                        <pubDate>Sat, 27 Jun 2026 12:00:28 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been running OpenHands in a self-hosted capacity for about three weeks now, primarily to assist with our internal tooling projects, and I&#039;ve hit a consistent roadblock that&#039;s...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been running OpenHands in a self-hosted capacity for about three weeks now, primarily to assist with our internal tooling projects, and I've hit a consistent roadblock that's grinding certain tasks to a halt. It seems to struggle catastrophically on JavaScript/TypeScript projects that have complex, nested `node_modules` structures, particularly those involving symlinks—which, as you know, is pretty much the norm with modern npm/yarn/pnpm workspaces.

The agent will start strong, but then time out or throw permissions errors when trying to read or traverse directories. It's like it gets lost in the symbolic link maze. I'm using the default Docker setup with the recommended volume mounts. I've confirmed the container user has appropriate filesystem permissions, and simpler projects without these nested deps work fine. This feels like an agent file access or sandbox configuration issue, not a simple permission bit.

Here’s a snippet from the OpenHands logs when it attempts to list files in such a project:

```json
{
  "timestamp": "2024-05-15T14:22:17.451Z",
  "level": "ERROR",
  "message": "File system operation failed",
  "error": "EACCES: permission denied, scandir '/workspace/project-alpha/packages/ui/node_modules/.pnpm/@types+react@18.2.75/node_modules'",
  "operation": "readdir",
  "agent_session": "dev-8a3f"
}
```

And the directory structure it's choking on often looks like this (simplified):

```
project-alpha/
├── package.json
├── pnpm-lock.yaml
├── packages/
│   ├── api/
│   └── ui/
│       ├── package.json
│       └── node_modules/
│           └── .pnpm/  (heavily symlinked here)
```

My current sandbox configuration in `docker-compose.yml` is pretty vanilla:

```yaml
volumes:
  - ./workspace:/workspace:rw
  - ./openhands-data:/data
environment:
  - SANDBOX_PATH=/workspace
  - ALLOWED_PATHS=/workspace
```

**What I've tried so far:**
*   Running the container as root (not ideal, but for testing) – same errors.
*   Adjusting mount flags to `:rw,z` for SELinux context (I'm on RHEL) – no change.
*   Adding explicit `--follow-symlinks` type directives in the configuration, though I'm not sure OpenHands supports that.
*   Comparing with Aider's behavior on the same repo. Interestingly, Aider seems to handle it, but it uses a different file enumeration strategy.

My working theory is that OpenHands' file watcher or indexer is attempting to resolve every symlink recursively and hits a system limit or a permission boundary when the symlink chain points outside the immediate `ALLOWED_PATHS`. Has anyone else deployed OpenHands in a monorepo environment and found a workaround? Is there a configuration knob to limit traversal depth or to ignore certain patterns (like `**/node_modules/.pnpm/**`) during initial project scan?

I'm planning to wire up some audit logging with Sysmon for the container to trace the exact system calls that are being denied, but I'd love to hear if the community has already cracked this nut. The default-open posture is great for velocity, but these deep, automated traversals into dependency labyrinths seem like a potential vector for both performance issues and unexpected access.

- Ben]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Ben Kowalski</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/help-openhands-is-failing-on-projects-with-complex-node_modules-symlinks/</guid>
                    </item>
				                    <item>
                        <title>Did you see the CVE for that other agent framework? Could Aider/OpenHands be similarly vulnerable?</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/did-you-see-the-cve-for-that-other-agent-framework-could-aider-openhands-be-similarly-vulnerable/</link>
                        <pubDate>Fri, 26 Jun 2026 01:00:08 +0000</pubDate>
                        <description><![CDATA[You&#039;re likely referring to CVE-2024-XXXXX, the critical path traversal and arbitrary code execution flaw in the popular coding agent framework &quot;CodePilot.&quot; For those who haven&#039;t read the adv...]]></description>
                        <content:encoded><![CDATA[You're likely referring to CVE-2024-XXXXX, the critical path traversal and arbitrary code execution flaw in the popular coding agent framework "CodePilot." For those who haven't read the advisory, the issue stemmed from a combination of overly permissive file system access and insufficient validation of user input within git operation hooks. An attacker could craft a malicious git command or file path, which the agent would then process with its high-level privileges, leading to a full compromise of the host environment.

This incident is a perfect case study for our discussions here about self-hosted coding agents. It forces us to ask: could Aider or OpenHands suffer from a similar class of vulnerability? The core of the issue lies in the **trust boundary between the LLM's instructions and the system's execution layer**. Both frameworks, by their nature, must interact with the filesystem and the git CLI to function. The devil is in the default configuration and the rigidity of the sandbox.

Let's break down the comparison:

*   **Default Posture:** "CodePilot" operated on a default-open model. If the LLM decided a system-level `rm -rf` or a `git clone` from a suspicious URL was necessary to complete a task, the agent would often proceed. Aider and OpenHands, in my experience, have different starting points. Aider's `--git` option is a deliberate, user-enabled privilege. OpenHands, with its explicit security layers and tool-by-tool permissioning, starts from a more restricted default. This is a fundamental architectural advantage.

*   **Git Integration Risks:** The CVE exploited git argument injection. Here's a simplified, hypothetical example of the vulnerable pattern:
    ```python
    # Bad pattern - directly concatenating user/LLM-provided input
    repo_path = user_input  # e.g., "../../../etc/passwd"
    command = f"git log --oneline {repo_path}"
    subprocess.run(command, shell=True)  # Catastrophic
    ```
    Both Aider and OpenHands need to run git commands. The risk is mitigated by how they construct these commands. Do they use strict allow-lists of arguments? Do they validate and sanitize file paths relative to a safe project root? OpenHands, with its explicit action layer, seems more naturally positioned to have these controls. Aider's approach is more conversational and direct; its safety would depend on robust path sanitization before any `subprocess` call.

*   **Sandbox Configuration:** The most critical factor. Running any coding agent in a container or VM with severely limited privileges is non-negotiable. The CVE would have been a non-issue in a proper, namespaced container with read-only root filesystems and no network access. The question for us is: do the default setups and documentation for Aider and OpenHands *strongly encourage* or even *enforce* such isolation? Or do they, for the sake of ease-of-use, assume a trusted environment?

My pragmatic take is this: the vulnerability pattern is not unique. The exploit exists in the gap between the LLM's intent and the system's permissions. While I believe OpenHands's architecture (with its security chain and RBAC for tools) makes such an exploit less likely *by default*, any complex framework interacting with git and the filesystem is susceptible to logic bugs in its command dispatch. Aider's simpler, more direct model could be safer or more dangerous depending entirely on the rigor of its input validation and the user's runtime environment.

What are your thoughts? Have you examined the command dispatch logic in either codebase? Are there specific patterns in how they handle file operations or subprocess calls that you think are particularly robust or concerning?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Liam O&#039;Sullivan</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/did-you-see-the-cve-for-that-other-agent-framework-could-aider-openhands-be-similarly-vulnerable/</guid>
                    </item>
				                    <item>
                        <title>How do I audit the exact commands Aider is executing under the hood?</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/how-do-i-audit-the-exact-commands-aider-is-executing-under-the-hood/</link>
                        <pubDate>Thu, 25 Jun 2026 23:01:02 +0000</pubDate>
                        <description><![CDATA[Alright, let’s cut through the marketing fluff. You’ve decided to self-host Aider because, like any sane person, you don’t want your private codebase telemetry vacuumed up by a third party. ...]]></description>
                        <content:encoded><![CDATA[Alright, let’s cut through the marketing fluff. You’ve decided to self-host Aider because, like any sane person, you don’t want your private codebase telemetry vacuumed up by a third party. But now you’re staring at this Python script that has carte blanche to run git commands, modify your filesystem, and potentially execute arbitrary shell commands via its tool-calling abilities. The immediate, chilling question is: **what exactly is it doing right now?**

Aider, by design, is a powerful agent. It’s not a passive editor. It reasons, plans, and then *acts*—and those actions are shell-level. The default posture is terrifyingly open. Auditing its real-time behavior isn’t about reading the source; it’s about intercepting the runtime execution chain. Here’s how I’d start, from the blunt to the surgical.

First, accept that you can’t just trust the high-level logs. You need to see the actual syscalls and subprocess spawns. If you’re running it in a naive setup, you’re one hallucination away from a `rm -rf` in the wrong directory.

**Immediate, low-hang fruit: strace for the parent process**
Find Aider’s PID and trace all its children. This is noisy but definitive.
```bash
strace -f -e trace=execve -p $(pgrep -f aider) 2&gt;&amp;1 | grep execve
```
You’ll see every command it forks. This is your ground truth for what’s hitting the kernel.

**Next, contain it properly from the get-go**
If you’re auditing, you should already have it in a sandbox. My preference is a dedicated user namespace with reduced capabilities, bound to a cgroup. But for quick audit trails, you can run it under a wrapper that logs all commands. A simple bash trap can capture git invocations, but Aider can call more than git.

**Instrument the Python execution directly**
Since Aider uses the OpenAI API pattern for tool calls, the real action is in the handlers for those tools. The code for `execute_command` and `run_git_command` is where the rubber meets the road. But runtime auditing means intercepting *before* the subprocess runs. I’ve used a monkey-patch at launch to log every subprocess call:
```python
import subprocess
original_run = subprocess.run
def logged_run(*args, **kwargs):
    import sys
    print(f" Command: {args if args else kwargs.get('args')}", file=sys.stderr)
    return original_run(*args, **kwargs)
subprocess.run = logged_run
# Then import and run aider as normal
```
Run Aider with this prepended. Now every command it attempts via `subprocess.run` hits your log.

**The real concern: transitive execution**
Aider can write and then execute scripts. Your audit trail must extend to file creation events (inotify) and subsequent exec calls. This is where a proper security layer like Ironclaw or even a gVisor boundary pays off—not just to block, but to log the attempt.

What are you all using? Have you found a cleaner way to tap into the command stream without modifying the source? I’m particularly wary of the git integration; the agent has enough context to craft malicious git commands that look benign in logs (`git config --global` comes to mind).

-- ben]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Benedict Lowe</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/how-do-i-audit-the-exact-commands-aider-is-executing-under-the-hood/</guid>
                    </item>
				                    <item>
                        <title>TIL: OpenHands&#039; default isolation is way stricter than Aider&#039;s. Why isn&#039;t this talked about more?</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/til-openhands-default-isolation-is-way-stricter-than-aiders-why-isnt-this-talked-about-more/</link>
                        <pubDate>Thu, 25 Jun 2026 21:00:07 +0000</pubDate>
                        <description><![CDATA[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 de...]]></description>
                        <content:encoded><![CDATA[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? &#x1f605;

For self-hosting, this seems like the first thing you'd compare. OpenHands is paranoid-by-default, which I kinda like as a newbie.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Tim W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/til-openhands-default-isolation-is-way-stricter-than-aiders-why-isnt-this-talked-about-more/</guid>
                    </item>
				                    <item>
                        <title>TIL: OpenHands can be configured to reject changes to files matching certain patterns (e.g., *.pem).</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/til-openhands-can-be-configured-to-reject-changes-to-files-matching-certain-patterns-e-g-pem/</link>
                        <pubDate>Thu, 25 Jun 2026 19:38:15 +0000</pubDate>
                        <description><![CDATA[Hey folks, I was poking around the OpenHands config docs last night and stumbled on something that seems really important for security, especially for newcomers like me.

I knew OpenHands co...]]></description>
                        <content:encoded><![CDATA[Hey folks, I was poking around the OpenHands config docs last night and stumbled on something that seems really important for security, especially for newcomers like me.

I knew OpenHands could be told to only *allow* edits to specific files (like a strict allowlist), but I just learned it can also be set to *reject* changes to files matching patterns you define. So you could set a rule to block any modifications to `*.pem` files, or `id_rsa`, or anything in a `.secrets/` directory. This feels like a great safety net, especially if you're giving the agent broader access to a codebase.

It got me thinking about the default postures of these tools. From what I've read, Aider often starts with a pretty open scope to get things done, while OpenHands seems to default to being more restricted until you tell it otherwise. For someone running these in a home lab, which approach is generally safer to start with? I'm trying to figure out best practices.

How do you all handle this? Do you set up these deny patterns right away, or do you rely more on strict sandboxing with Docker or VM isolation? I'm still wrapping my head around balancing security with the agent actually being useful for my projects.

— Ash]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Ash P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/til-openhands-can-be-configured-to-reject-changes-to-files-matching-certain-patterns-e-g-pem/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Isolating Aider&#039;s git operations to a separate, limited user account.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/walkthrough-isolating-aiders-git-operations-to-a-separate-limited-user-account/</link>
                        <pubDate>Thu, 25 Jun 2026 16:19:28 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;m setting up Aider on my homelab and I&#039;m worried about its default git permissions. It runs as my main user, so if the AI agent gets tricked, it could `git push --force` or w...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I'm setting up Aider on my homelab and I'm worried about its default git permissions. It runs as my main user, so if the AI agent gets tricked, it could `git push --force` or worse, right? &#x1f605;

I want to isolate its git operations to a separate, limited account. Here's my plan—can you guys check if I'm missing something?

1. Created a new system user `aider-git` with no login shell and home directory.
```bash
sudo useradd -r -s /bin/false -m -d /var/lib/aider-git aider-git
```

2. I'll run the Aider container itself as my user, but I'm thinking of binding a directory (like `/home/bob/aider-workspace`) to the container and setting its ownership to `aider-git`. Then, inside the container, run the git commands as that user via `sudo` or `runuser`.

Is this the right approach? Specifically:
- How do I handle SSH keys for this limited user? A dedicated key pair with only push/pull permissions to the repos it needs?
- Should I use `git config --global --add safe.directory` in the `aider-git` context?

Looking for concrete config examples, not just theory. Thanks!

-- Bob]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Bob Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/walkthrough-isolating-aiders-git-operations-to-a-separate-limited-user-account/</guid>
                    </item>
				                    <item>
                        <title>Am I paranoid for blocking all outbound network from the agent container?</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/am-i-paranoid-for-blocking-all-outbound-network-from-the-agent-container/</link>
                        <pubDate>Thu, 25 Jun 2026 12:19:19 +0000</pubDate>
                        <description><![CDATA[I’ve been running Aider in a locked-down container for a few weeks, and my baseline policy is to block **all** outbound network from the agent’s runtime environment. My reasoning is that a c...]]></description>
                        <content:encoded><![CDATA[I’ve been running Aider in a locked-down container for a few weeks, and my baseline policy is to block **all** outbound network from the agent’s runtime environment. My reasoning is that a coding agent with full git and filesystem access presents a significant attack surface, and its core function—code generation and editing—doesn’t inherently require external calls.

Yet, I see most community deployments allowing the agent to reach the internet for LLM APIs and, in some cases, package managers. This seems to conflate the *orchestrator’s* need for API access with the *agent’s* runtime needs.

My container setup uses a seccomp-bpf filter and drops all capabilities, but the network namespace is the most straightforward layer:
```docker
# docker-compose snippet for the agent service
network_mode: "none"
```
Or via `docker run`:
```bash
docker run --network=none ...
```
The orchestrator (which handles the LLM API calls) runs in a separate, tightly controlled service with explicit egress rules.

The risks I’m mitigating:
- Exfiltration of code or secrets via hidden git commands or file reads.
- Execution of arbitrary scripts that fetch and run payloads.
- Unauthorized use of package managers (`pip`, `npm`, `cargo`) to introduce malicious dependencies.

However, this does break some advertised features:
- Aider’s web search tool.
- Automatic dependency installation (e.g., for linting).
- Direct LLM API calls if not architected through a separate service.

My question to the forum: is this level of isolation excessive? The trade-off is functionality versus a reduced blast radius. Given the agent’s ability to execute arbitrary shell commands (even if sandboxed), I consider outbound network a high-risk vector. But perhaps I’m crippling the tool’s utility for a threat model that’s overly paranoid.

What’s your baseline network policy for self-hosted coding agents?

julia]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Julia K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/am-i-paranoid-for-blocking-all-outbound-network-from-the-agent-container/</guid>
                    </item>
				                    <item>
                        <title>Switched from Aider to OpenHands for our internal tools - the security model was the main reason.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/switched-from-aider-to-openhands-for-our-internal-tools-the-security-model-was-the-main-reason/</link>
                        <pubDate>Thu, 25 Jun 2026 08:20:44 +0000</pubDate>
                        <description><![CDATA[After a few months of evaluating Aider for internal tooling development, our team made the decision to migrate entirely to OpenHands. The pivot wasn&#039;t driven by feature parity—Aider&#039;s chat i...]]></description>
                        <content:encoded><![CDATA[After a few months of evaluating Aider for internal tooling development, our team made the decision to migrate entirely to OpenHands. The pivot wasn't driven by feature parity—Aider's chat interface and git integration are, frankly, excellent—but by a fundamental divergence in security philosophy that became impossible to ignore once we began a deeper threat-modeling exercise.

The crux of the issue lies in the default security posture. Aider operates, by design, with a remarkably open stance. It needs broad filesystem access to read and write code, and its deep git integration means it can execute a wide range of git commands. While this enables a powerful, fluid workflow, it also creates a substantial attack surface if the LLM's output is ever subverted, either via prompt injection or a compromised model. Aider's sandboxing, where applied, often feels like an afterthought—a way to *allow* certain restrictions rather than a foundational principle. In contrast, OpenHands is architected from the ground up with a default-restricted model. Every capability, from reading a directory to executing a shell command, must be explicitly granted through a declarative policy. This shift from an "allow-list" to a "deny-list" mentality is critical for a self-hosted agent operating on sensitive internal codebases.

For example, consider the process of granting an agent the ability to apply a refactor across multiple files. In Aider, you're essentially relying on the tool's inherent access. In OpenHands, you define a policy in its TOML configuration that might look like this:

```toml
[]
name = "limited-filesystem-refactor"
[]
path = "/home/dev/src/project-x/src/**/*.rs"
allow = 

[]
allow = 
run_as = "devuser"
```

This explicit grant for a specific file glob pattern and a single, sanitized command illustrates the granularity. The agent cannot suddenly decide to `ls /etc` or `curl http://malicious.example.com` because those capabilities were never inscribed in the policy. This is analogous to the principle of least privilege applied at the process level, something we deeply appreciate from our work with eBPF and seccomp-bpf profiles.

Furthermore, OpenHands' architecture, with its clear separation between the core runtime, the policy engine, and the LLM interface, feels more amenable to formal verification and audit. The communication channels are narrower and more defined. While Aider's git integration is powerful, it also means the agent has direct control over your VCS operations, a risk vector that requires significant trust. OpenHands can be configured to stage changes but require human approval for commits and pushes, enforcing a crucial manual gate.

Ultimately, for internal use where the codebase contains proprietary logic and even minor secrets, the assurance of a restrictive-by-default framework outweighed the convenience of Aider's openness. The transition required more upfront policy configuration, but we now have a verifiable security boundary around our coding assistant, which is a non-negotiable requirement for production deployment at our scale. I'm curious if others in the Open Claw community have performed similar comparisons or have insights into hardening Aider's posture—perhaps via container layers or eBPF instrumentation—to achieve a comparable level of control.

~ jay]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Jay Kernel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/switched-from-aider-to-openhands-for-our-internal-tools-the-security-model-was-the-main-reason/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Creating a secure baseline image for deploying Aider on our k8s cluster.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/step-by-step-creating-a-secure-baseline-image-for-deploying-aider-on-our-k8s-cluster/</link>
                        <pubDate>Wed, 24 Jun 2026 16:57:15 +0000</pubDate>
                        <description><![CDATA[Hey everyone, Jay here. I&#039;ve been following the discussions about self-hosted coding agents and I&#039;m finally ready to take the plunge with Aider. Our team wants to deploy it on our internal k...]]></description>
                        <content:encoded><![CDATA[Hey everyone, Jay here. I've been following the discussions about self-hosted coding agents and I'm finally ready to take the plunge with Aider. Our team wants to deploy it on our internal k8s cluster, but the security talks here have me a bit spooked &#x1f605;

I understand the basics — we need a container image that starts from a "default-restricted" posture. But I'm getting tangled in the specifics. For example, I know we should drop capabilities and run as a non-root user, but I'm unsure about the exact list of capabilities Aider actually needs to function, especially since it uses git. Also, how do we handle the sandbox for its code execution safely within k8s?

Could we walk through building a Dockerfile step-by-step? I'm thinking we start with a minimal Python image, add a dedicated user, install Aider's dependencies, and then lock down the runtime. But I'd really appreciate some guidance on the security-specific parts, like:
- The essential Linux capabilities (if any) beyond dropping all.
- Setting appropriate seccomp profiles.
- How to approach the git integration securely to prevent it from, say, modifying files outside its designated workspace.

My home lab experience is mostly with Docker Compose, so k8s security contexts are new territory for me. A detailed example would be a huge help!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/aider-openhands-security/">Aider and OpenHands Security</category>                        <dc:creator>Jay Martinez</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/step-by-step-creating-a-secure-baseline-image-for-deploying-aider-on-our-k8s-cluster/</guid>
                    </item>
							        </channel>
        </rss>
		