Aider, Continue, Open Interpreter securityArchitecture. Credential handling. Real tradeoffs.

Open-source coding agents did not converge on a single security model. Aider, Continue, and Open Interpreter each made different choices about what the agent can touch, where credentials land, and whether the agent runs code or only proposes it. Those choices have direct consequences for your security posture.

This is not a performance comparison. It is a security comparison. All three tools can write code. The question is what else they do while writing it.

The Knostic disclosures in early 2026 (Claude Code's settings.local.json leak, Cursor's .cursor/ directory issue) drew attention to a pattern that applies across the whole category: agents persist state to disk, and developers rarely know what is in that state. Knowing the security model of the agent you use is the minimum due diligence for 2026.

What to know in 60 seconds

• Aider operates on your git repo. It reads files within the repo, proposes diffs, and applies changes. It does not execute code unless you run the generated output yourself.
• Continue runs inside your IDE as an extension. It sends context to a configurable inference backend (local Ollama, your own API endpoint, or a cloud model). The scope of that context depends on which files the IDE has indexed.
• Open Interpreter executes code. It runs a Python process that can call shell commands, install packages, and interact with your operating system. The blast radius is your entire machine unless you containerize it.
• All three require credentials of some kind (API key, local model endpoint, or both). Where those credentials land differs by tool.
• None of the three has mandatory sandboxing in their default configuration as of Q1 2026.

Aider: git-aware and file-scoped

Aider's architecture centers on the git repository. You point it at a repo, it reads the files you add to its context window, and it produces diffs. Those diffs go through git. You commit or discard. The agent does not commit for you unless you pass --auto-commits.

Credential handling

Aider reads your API key from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.) or from a .aider.conf.yml file. The config file format is documented and predictable, which is a double-edged thing: it is easy to audit, and it is easy to accidentally commit. The .aider.conf.yml path does not appear in common .gitignore templates. Check your repo.

Aider does not write your API key to its own state files. Session history lands in .aider.input.history and .aider.chat.history.md, both repo-local. Neither file contains credential values, but the chat history includes every message you sent, which may include file contents with credentials embedded. If you pasted a .env value into the chat to ask a question about it, the answer is in that file.

File system scope

By default, Aider only reads files you explicitly add with /add. It does not index your whole repo on startup. This matters: a misconfigured context window in other agents can expose files you did not intend to share with the inference backend. Aider's explicit-add model avoids this class of problem.

The flip side is that Aider can write to any file you add, and the --yes flag suppresses confirmation prompts. Running aider --yes in a session with broad file additions is functionally equivalent to giving the model write access to those files.

Network access

Aider sends your prompt and file contents to the configured API endpoint. Nothing else. It does not call home, does not pull packages, does not open secondary connections. If you use a local model via Ollama or LM Studio, all traffic stays on your machine.

MCP support

Aider added MCP tool support in late 2025. MCP introduces a new attack surface: a compromised or malicious MCP server can inject instructions through tool results. Aider's MCP integration is opt-in and disabled by default. If you enable it, review the servers you connect with the same care you would give a third-party package dependency.

Audit and logging

.aider.chat.history.md is the closest Aider has to a session audit log. It is a markdown file you can read. There is no HMAC chaining or tamper detection. If you need to reconstruct what the agent did in a session for an incident review, the history file is what you have.

Continue: your backend, your context scope

Continue is a VS Code and JetBrains extension. Its threat model differs from Aider's because it operates inside the IDE, which has access to a broader surface than a git repo.

Architecture: local vs hybrid

Continue's value proposition is that you control the inference backend. You can point it at a local Ollama endpoint, a self-hosted vLLM server, or a cloud API. The extension itself does not send data anywhere except to the endpoint you configure.

This is meaningfully better than tools that lock you into one cloud provider. If your threat model includes "I do not want code leaving this machine," Continue with a local model is a viable configuration. The extension's source is auditable. The network destination is what you set.

The risk shifts to configuration error. The default config.json examples in the Continue docs include entries for cloud models. A developer who copies the example config and fills in an API key now has code leaving their machine, often without realizing the backend switch happened.

Credential handling

Continue stores configuration in ~/.continue/config.json. That path is outside any git repo, so it does not leak through git push or npm publish. This is a better default than tools that write config into the project directory.

The risk is IDE-level. VS Code settings sync can pull config.json into cloud sync if you have the wrong extension settings. Verify that ~/.continue/ is excluded from any settings sync you run.

API keys in config.json sit in plaintext. There is no encryption at rest in the default configuration. Anyone with read access to your home directory can read them. On a shared workstation or a developer machine where other processes run with your user permissions, that is a real exposure.

File system scope

Continue's context scope depends on the IDE's file indexer and which @-mentions you use in a chat. @codebase sends a large slice of your project to the inference endpoint. @file sends specific files. The scope is broader than Aider's explicit-add model by default.

In practice, Continue indexes the workspace your IDE has open. If your IDE workspace includes multiple projects, Continue's codebase index crosses those project boundaries. A query that triggers codebase search can pull in files from adjacent projects.

Network access

Continue with a cloud backend sends file excerpts, function signatures, and your prompt to that backend. The exact payload depends on context type selected. With a local backend, nothing leaves the machine. The extension itself does not phone home for telemetry by default, though the docs recommend disabling telemetry explicitly if that matters to you.

MCP support

Continue has first-class MCP support in 2025-2026 releases. Same caveat as Aider: MCP servers are a trust boundary. A Continue session connected to MCP servers is more complex to audit than one without.

Open Interpreter: code execution, biggest blast radius

Open Interpreter is in a different category from Aider and Continue. It does not just write code. It runs it.

The default behavior: you type a request, the model generates Python (or bash, or JavaScript), and Open Interpreter executes that code locally. The output feeds back to the model, which can generate and execute more code. The loop continues until the task is done or something breaks.

What this means for your threat model

The blast radius is your full user account. Open Interpreter can:

• Read files anywhere on your filesystem (not just the repo)
• Install packages via pip or npm without additional prompts
• Make network requests from generated code
• Write files to arbitrary paths
• Execute shell commands

This is by design. Open Interpreter positions itself as a local code execution environment, not a code editor. The use case is "do this task on my machine," not "propose a change to this file."

The problem is that the threat model for a shell agent is much larger than the threat model for a code editor. A malicious prompt injection in a file the agent reads can chain into arbitrary code execution. The February 2026 MCP GitHub prompt-injection disclosure (documented by Snyk researchers) showed how instruction injection in structured data leads to code execution when the consuming agent has execution capabilities. Open Interpreter without sandboxing is the worst case for that attack.

Safe mode and sandboxing

Open Interpreter provides --safe-mode flag values (off, ask, auto). With --safe-mode ask, the agent prompts before executing each code block. With --safe-mode auto, it applies static analysis and blocks obviously dangerous patterns.

Neither mode is a sandbox. They are guardrails on top of a full-capability execution environment. For production or team use, containerize Open Interpreter. The project documentation includes Docker examples. Running it bare on a developer machine is reasonable for personal automation; running it on a machine with production credentials in the environment is not.

Credential handling

Open Interpreter inherits your full shell environment. Every exported variable in your current session is available to generated code. There is no isolation between the agent's environment and your shell. A model that generates import os; print(os.environ) and executes it reads every credential you have exported.

This is the starkest difference from Aider, which reads credentials only to call the API endpoint, and Continue, which reads credentials from a specific config file. Open Interpreter's generated code can read all of them.

Audit and logging

Open Interpreter logs conversations to ~/.openinterpreter/conversations/ by default. Logs include generated code and execution output. If generated code printed a secret to stdout, that output is in the log. Check what your logs contain before assuming they are safe to retain.

Security comparison matrix

What actually gets underestimated

The common framing compares cloud model privacy (which company sees your code) while ignoring local execution risk (what runs on your machine). Open Interpreter with a local model is sometimes marketed as "private" because your code does not leave your machine. That is true. The reverse is also true: code from the model runs on your machine with your permissions. Local execution is a different risk category from remote inference, not a safer one.

Another pattern that goes unexamined: MCP server trust. Continue and Aider both support MCP, and the OX Security report from early 2026 counted roughly 7,000 MCP servers in the wild with about 150 million downloads and no signature requirement. Connecting an agent to an MCP server is a trust decision. Most developers make it by checking whether the server exists and has a plausible README.

The .aider.conf.yml in-repo risk is also underestimated. The file exists specifically to hold per-project config, which makes developers treat it like a project file. It is not ignored by default in git or npm, and it can hold API keys in plaintext. Knostic's scan methodology, applied to .aider.conf.yml files in public repos, would likely find a similar pattern to what they found in Claude Code's settings.local.json.

A checklist you can drop into a PR

## Coding agent hardening audit

- [ ] .aider.conf.yml and .aider.*.history in .gitignore and .npmignore
- [ ] ~/.continue/config.json excluded from IDE settings sync
- [ ] Open Interpreter only in containerized env or --safe-mode ask if run bare
- [ ] API keys for all three agents held in env manager, not hardcoded in config files
- [ ] MCP servers reviewed: read source or audit traffic before connecting
- [ ] git log --all -- '.aider.*' clean (no secrets in chat history)
- [ ] Open Interpreter conversation logs at ~/.openinterpreter/ checked for secret leakage
- [ ] Continue codebase index excludes directories with .env or credential files
- [ ] --auto-commits disabled in Aider unless every commit is reviewed before push
- [ ] Open Interpreter not running with production credentials in shell environment

What this means for your stack

The three tools map cleanly to three job types. Aider for proposing and committing code changes to a git repo, with explicit file scope and no code execution. Continue for IDE completions where you want to own the inference backend and keep data on-premise. Open Interpreter for local automation tasks where you need real code execution and you have containerized the environment or accepted the risk of running it bare.

The harder problem across all three is credential hygiene. Any agent that reads your shell environment or project config files is a potential path from ambient credentials to an external endpoint. The durable fix is to stop storing credentials as long-lived environment variables and start injecting them per-process at runtime.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent gets a process-scoped reference instead of a persistent key. Hasp has first-class profiles for Aider (aider), plus claude-code, cursor, and others. The audit log is HMAC-chained and verifiable with hasp audit --verify. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

The choice of agent matters less than the credential model you run it under. An Aider session with a long-lived API key in OPENAI_API_KEY and an Open Interpreter session with a process-scoped grant have the same risk level reversed from what most developers assume.