Aide Sandbox

Checked: 2026-07-14

Summary

Aide is an MIT-licensed command-line launcher for coding agents. It resolves a project context, decrypts configured secrets in memory, converts task capabilities into operating-system sandbox rules, and starts the chosen agent with a consistent interface.

It uses macOS Seatbelt or Linux Landlock/bubblewrap rather than a VM. Its main differentiator is permission bundles such as Docker, Kubernetes, AWS, GitHub, and language toolchains, plus context-specific agent profiles and SOPS-encrypted configuration.

Problem

Developers often choose between repeated approval prompts and letting an agent inherit their entire user account. Different agents also use different configuration, credentials, and plugin locations. Aide aims to make the allowed resources explicit and repeatable per project while hiding unrelated files and credentials.

How It Works

• Aide matches the current path and Git remote against YAML contexts.
• It selects an agent, profile, credentials, capabilities, and sandbox policy.
• SOPS-encrypted YAML secrets are decrypted in-process using age keys and rendered into the agent environment.
• Capabilities expand into filesystem, environment, network, and runtime guards.
• Aide generates a macOS Seatbelt profile or applies Linux Landlock. Bubblewrap is a filesystem-only fallback.
• It replaces itself with the agent process and forwards any arguments after --.
• Project .aide.yaml configuration is shown and requires trust before it can modify policy.
• Separate profiles can isolate each project’s Claude, Codex, Gemini, or other agent state and plugins.

Security Boundary

• This is same-kernel operating-system sandboxing, not hardware or guest-kernel isolation.
• Default guards protect project secrets, development credentials, Aide secrets, Keychain access, system paths, and unrelated filesystem areas while allowing the project and known agent state directories.
• never-allow rules can block sensitive files or environment names even when a capability would normally grant them.
• Capabilities deliberately expose powerful credentials. For example, Docker, Kubernetes, cloud, SSH, or GitHub access may let an agent make real external changes.
• yolo disables the agent’s own prompts but is intended to leave Aide’s operating-system sandbox active.
• A trusted project config, custom capability, explicit sandbox: false, or broad writable path can weaken or remove protection.
• On Linux without Landlock or bubblewrap, Aide warns and launches the agent without OS-level isolation. This is fail-open behavior.

Platforms and Agents

• Hosts: macOS and Linux.
• macOS backend: sandbox-exec with a generated Seatbelt profile.
• Linux primary backend: Landlock on kernel 5.13 or newer; TCP port enforcement requires kernel 6.7 / Landlock ABI 4.
• Linux degraded fallback: bubblewrap filesystem namespaces without port control.
• Built-in agent knowledge: Aider, Amp, Claude, Codex, Copilot, Cursor, Gemini, and Goose.
• Any executable on PATH can be selected as an agent target.
• Native Windows support is not documented.

Setup

1. Install a release binary or build with Go.
2. Run aide setup for interactive configuration, or let Aide detect an agent and its existing environment.
3. Define contexts by path or Git remote, with agent, profile, encrypted secret set, and task capabilities.
4. Preview grants with capability checks and confirm the active backend and isolation tier with aide status or sandbox inspection commands.
5. Run aide, adding session capabilities only when needed.
6. Trust or deny a repository’s .aide.yaml before it can affect policy.
7. Use provisioning commands to reconcile declared plugins and MCP servers per agent profile.

The README contains ambiguous wording about zero-configuration behavior: it says sandboxing is automatic but also says an agent is launched “directly” when no config exists. Users should confirm the status output before relying on protection.

Network and Credentials

• Default network mode allows outbound traffic. The sandbox can deny all network or filter TCP ports.
• Domain, URL, and MIME-type filtering were still listed as planned. An agent allowed port 443 can reach arbitrary HTTPS destinations unless another control intervenes.
• Encrypted secrets never need to be plaintext on disk, but they are rendered into the launched agent environment. The agent can read and potentially exfiltrate them over allowed networking.
• Capability bundles expose selected host credential directories or environment values. never-allow can subtract production credentials.
• Aide does not broker an API credential outside the agent process or scope it to a particular HTTP endpoint.
• Docker socket, Kubernetes, cloud, SSH, and GitHub capabilities can grant much broader authority than their filesystem paths suggest.
• Project secrets and common credential locations are denied by default unless a capability or explicit rule grants access.

Strengths

• One launcher and context model across many coding agents.
• Task-level capabilities are easier to review than raw sandbox rules.
• Explicit global deny rules can protect production credentials from later capability expansion.
• Project configuration has a trust gate.
• SOPS and age support make encrypted configuration portable through Git.
• Per-context agent profiles separate history, plugins, MCP servers, and state.
• Status, preview, diagnostics, and isolation-tier output help users see effective protection.
• Linux and macOS support without requiring a VM runtime.

Limits and Risks

• Same-kernel sandboxing is weaker than a VM against kernel, sandbox-runtime, or policy-engine vulnerabilities.
• Outbound internet is allowed by default and domain filtering is not implemented.
• Linux support varies sharply by kernel. Older systems may lose port controls, fall back to filesystem-only bubblewrap, or run entirely unsandboxed.
• Fail-open unsupported-host behavior is dangerous for unattended yolo use.
• Landlock rules are directory-based and cannot provide every macOS per-file pattern.
• Capabilities can expose credentials that authorize production-impacting actions.
• No built-in project snapshot, copy-on-write checkout, rollback, or clean VM lifecycle.
• The agent edits the real project directory, so sandboxing does not prevent in-scope code loss.
• Configuration management covers agent settings, plugins, secrets, and capabilities, not a complete reproducible operating-system environment.
• Planned command-name denial is not current protection and can be bypass-prone unless enforced below the shell.

Activity and Maturity

• Repository created 2026-03-21.
• Latest release: v2.0.0, published 2026-06-22.
• GitHub showed 10 stars, 2 forks, and repository activity through 2026-06-22.
• Releases moved rapidly from v1.8.1 to v2.0.0 during May and June 2026.
• CI and security workflows are present, but no independent audit or published threat model was found.
• Version 2.0 indicates an intentional release milestone, while the small user base, young codebase, platform variation, and planned core controls still argue for careful testing.

Best Fit

• Developers wanting less approval fatigue without managing full VMs.
• Teams that need repeatable per-project agent, plugin, and credential profiles.
• macOS or modern Linux users who can inspect the active backend and accept same-kernel isolation.
• Workflows where only selected Docker, cloud, Kubernetes, GitHub, or toolchain access should be exposed.

It is less suitable for hostile code, strong exfiltration prevention, rollback-dependent work, unsupported Linux kernels, Windows, or unattended production access without another network boundary.

Comparison Facts

Fact	Aide	Clawk
Isolation	Seatbelt, Landlock, or bubblewrap	Dedicated local VM
Kernel	Shared host kernel	Separate guest kernel
Project writes	Real project directory	Project VM workflow
Agent support	Broad launcher abstraction	Agent-oriented VM environment
Network	Outbound default; optional mode/ports	Domain allowlist before dialing
Credentials	SOPS secrets and capability-exposed host credentials	Credentials inside project VM workflow
Configuration	YAML contexts, capabilities, profiles, plugins	VM/project configuration
Rollback	None built in	Disposable VM lifecycle
Startup	Native-process speed	VM startup overhead

Aide favors speed, configuration, and selective host integration. Clawk favors a stronger machine boundary and disposable workspace.

Hacker News Context

The Aide mention appeared under a critique asking sandbox projects about configuration management, policy, credential management, and the “lethal trifecta” of private data, untrusted content, and external communication. Contributor selvakn said Aide covers the need with YAML configuration and SOPS credential management.

That claim is partly supported: Aide provides YAML contexts, capabilities, trust, encrypted secrets, and operating-system rules. It does not fully break the lethal trifecta when outbound networking is open and decrypted credentials are passed to the agent. It also lacks endpoint-scoped application proxies and domain allowlists in the current release.

Unknowns

• Independent audit, formal threat model, fuzzing results, or known bypass history.
• Exact zero-configuration sandbox behavior given conflicting README wording.
• Whether diagnostics and status make fail-open Linux launches sufficiently visible in automated use.
• Windows plans and timing for domain/MIME filtering and command denial.
• Security impact of each built-in capability and whether all credential paths remain current across tool versions.

Sources

• Aide repository and README
• Aide sandbox documentation
• Aide capabilities
• Aide secrets
• Aide releases
• HN: Clawk discussion
• HN: Aide comment