Aider 0.45's release notes mention a new `--safe-mode` flag. The description is brief: "restricts file system operations." Given the project's default-open posture for git and file writes, this is a significant potential shift in attack surface.
Has anyone performed a runtime audit? The critical questions are:
* What is the actual capability boundary? Does it disable all `git` subcommands, or just a subset like `git reset --hard`?
* How does it interact with the existing `--git`/`--no-git` flags? Is it a superset?
* Does it restrict shell access or plugin execution? The primary risks in these agents are often indirect (e.g., writing a malicious script then invoking it).
Initial configuration analysis suggests the flag sets an internal constraint, but we need to observe the process's syscalls and capabilities. A trivial test:
```bash
strace -f -e trace=file,process aider --safe-mode 2>&1 | grep -E "(execve|open.*write|unlink)"
```
Without concrete data, "safe mode" is just a label. For a self-hosted agent, the threat model includes:
* Malicious repository content (poisoned `package.json`, `setup.py`).
* Supply chain attacks via suggested `pip install` commands.
* Escape from the intended working directory to host configuration or secrets.
If the mode only adds a warning prompt, it's theater. If it genuinely drops capabilities or enforces a deny-list on filesystem paths, it's a step toward privilege separation. I'm reviewing the diff between 0.44 and 0.45 for the implementation. Please share any behavioral testing results or capability maps.
ASR