Having recently audited several self-hosted coding agent setups, a common pattern emerges: developers run tools like Aider in overly permissive environments, negating the security benefits of self-hosting. The primary risk is not the agent itself, but the execution context it inherits. This guide outlines a method for running Aider within a VS Code Dev Container, applying a default-restricted, capability-dropping posture.

The goal is to create a container where Aider can function for code generation and Git operations, but is explicitly denied the ability to:
* Execute arbitrary shell commands outside its toolset.
* Access the Docker socket or host network.
* Write to filesystems outside the designated workspace.

A foundational `devcontainer.json` configuration achieves this by starting from a minimal image, adding only necessary packages, and dropping Linux capabilities. The `runArgs` are critical for containment.

```json
{
"name": "Aider (Locked-Down)",
"image": "mcr.microsoft.com/devcontainers/base:debian",
"features": {
"ghcr.io/devcontainers/features/git:1": {}
},
"runArgs": [
"--cap-drop=ALL",
"--security-opt=no-new-privileges",
"--read-only",
"--tmpfs=/tmp:rw,noexec,nosuid"
],
"mounts": [
"source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"
],
"postCreateCommand": "pip install --user aider-chat",
"customizations": {
"vscode": {
"extensions": []
}
}
}
```

Key security controls in this configuration:
- `--cap-drop=ALL`: Removes all Linux capabilities, preventing container breakout via privilege escalation.
- `--read-only` with a `/tmp` tmpfs: The root filesystem is immutable; only a volatile `/tmp` is writable, mitigating persistence of malicious scripts.
- Bind mount for workspace: The host's project directory is mounted explicitly, isolating container filesystem access.
- No `network` mode overrides: The container uses the default bridge network, isolated from the host.

For Git operations, Aider requires specific capabilities. The container provides Git, but the `--cap-drop=ALL` setting means any attempt by Aider to spawn subprocesses outside its direct function will fail. This must be validated against your specific workflow. Consider implementing additional guardrails:
* A pre-commit hook audit log within the workspace to monitor Git actions.
* A `.git/config` that uses a dedicated, non-administrative SSH key with minimal repository permissions.
* VS Code's own sandboxing of terminal access provides an additional layer.

This approach shifts the security model from hoping the agent doesn't misuse its environment to architecturally preventing misuse. It aligns with zero-trust principles for development tools, treating the agent API as an untrusted boundary. Further hardening would involve app-specific firewall rules to restrict Aider's outbound API calls to only the configured LLM endpoint.