Hey everyone, been experimenting a lot lately with Aider as a self-hosted coding assistant, especially after playing with OpenHands. I'm really drawn to Aider's git integration—it feels powerful to have an agent that can directly stage and commit—but that power absolutely terrifies me from a security perspective when running it locally with a capable model. The idea of an LLM with write access to my entire codebase because of a clever prompt injection or just a hallucination... yeah, no thanks.
So I've been trying a different approach: running Aider against a read-only file system snapshot. The theory is simple. I make a temporary copy or a snapshot (using something like `overlayfs` or even just a `cp -r` to a `/tmp` location) of the project I want to work on. I then start Aider with its `--git` flag disabled (or point it at this snapshot directory) and let it do its analysis and suggest changes. All the edits happen in the snapshot. I review the suggested diffs manually, and only *then* do I apply them to the real working directory myself.
It's clunky, but it turns Aider from an autonomous agent with a commit bit into a very smart, interactive linter/suggestion engine. Here's a super basic shell snippet of the workflow I'm manually following:
```bash
# Create a snapshot workspace
SNAPSHOT_DIR=$(mktemp -d)
cp -r /path/to/real/project/* "$SNAPSHOT_DIR/"
# Launch Aider confined to the snapshot
cd "$SNAPSHOT_DIR"
aider --no-git
# After the session, review changes from the snapshot
cd /path/to/real/project
diff -ur /path/to/real/project "$SNAPSHOT_DIR" | less
# Then carefully apply what I want
# cp "$SNAPSHOT_DIR/modified_file.py" /path/to/real/project/
```
This is obviously a huge departure from the intended, fluid Aider experience. You lose the git staging magic entirely. But for me, the trade-off in safety feels worth it for now. It forces a human-in-the-loop for any actual filesystem mutation.
I'm curious if anyone else has tried similar "safe mode" approaches with coding agents? How do you balance capability with containment in your homelab setups? OpenHands feels like it starts from a more restricted posture by default, which is interesting, but I find its project structure a bit more involved to self-host. Maybe there's a middle ground—some clever Docker or Podman configuration with bind mounts set to `ro` and a separate `rw` volume for the agent's own scratch space?
Would love to hear about your experiments, failures, and workarounds. The goal for me is a setup where I can still get that amazing "collaborative programming" feel without lying awake at night wondering if the agent just `rm -rf`-ed my repo on a whim.
- Sam
Still learning, still breaking things.
Yeah, that's a really smart approach, honestly. It turns the fear of autonomous writes into a proper human-in-the-loop review. I do something similar when I'm using tools to refactor or audit unsafe Rust blocks - they run in a sandbox and spit out suggestions, then I apply them.
The clunkiness is real though. Have you looked at wrapping this flow in a small script that automates the snapshot, runs aider, and then presents you with a tidy diff to apply? Could make it feel less like a hack and more like a legit workflow.
I wonder if the Aider folks have considered a "dry-run" or "suggest-only" mode as a first-class feature, given how many people are probably nervous about the commit bit.
Fearless concurrency, fearless security.
Your approach is just a local version of the security theater we already do in CI pipelines. Snapshotting shifts the risk but doesn't eliminate it.
What's the threat model here? If you're worried about prompt injection leading to arbitrary writes, you've now just moved the target. The LLM's output still gets written to disk in the snapshot. A malicious payload could be sitting there, waiting for you to copy it into your main tree during your manual review. Are you auditing every single line of every suggested diff?
You're trading automation for a manual review burden. That's fine if your time is cheap. But the real question is whether this workflow scales or if you'll get lazy and just accept the diffs in six months.
Show me the numbers.
That's a fair point about the review burden. It does shift the risk rather than eliminate it. But I think you're downplaying the actual risk reduction.
The threat isn't just "a malicious payload sitting there." It's that payload being executed automatically by the tool's own functionality. In the normal mode, a single injected command could `rm -rf` the repo or commit a backdoor. In the snapshot mode, the worst it can do is *suggest* that backdoor. The human review is the air gap. It's not about auditing every line, it's about preventing automated action on those lines.
Whether people get lazy is a human factors problem, not a technical one. The same argument could be made about any code review process. At least this gives you a fighting chance.
Stay sharp, stay civil.
Exactly. The security improvement is about reducing the attack surface from arbitrary execution to a controlled review stage. It's a classic application of the principle of least privilege to the tool's own operational capabilities.
However, user310's underlying concern about scaling isn't just about laziness, it's about workflow integration. If the process is too cumbersome, engineers will find shortcuts that re-introduce the risk. The real policy question is whether to mandate this pattern for certain assurance levels, similar to how some orgs require a separate "security" git push for high-risk repos.
A read-only snapshot essentially enforces a manual code review as a guardrail. That's a valid and often necessary control when dealing with high-autonomy agents. The alternative is to rely entirely on the model's built-in alignment, which is not a control your security policy can audit or enforce.
Policy is code