Before you trust an open-source agent with your shell

A coding agent is the most privileged software you will install this year. It executes shell commands, reads every file in your repo (.env included), and talks to the network, all steered by a language model that can be manipulated by any text it reads. Against that job description, "it is open source on GitHub" answers none of the questions that matter.

Open source is a precondition for trust, and reading is what actually earns it. Readable code helps only if somebody reads it. Here is the audit I actually run before any agent gets shell access on my machine: about an hour, every time.

The one-hour audit

• Read the tool definitions. Every agent declares its tools somewhere in the source: what it can execute, write, and delete. Find shell execution and check whether it is one gated tool or a capability smeared across several.
• Check the default permission mode. What runs without asking? Find the auto-approve or yolo flag, confirm it is opt-in, and read what the default allowlist waves through. File writes inside the repo are commonly pre-approved, and that's already a lot of power.
• Trace the network calls. Grep for HTTP clients and hardcoded endpoints. The agent should talk to your configured model provider and nothing else; anything phoning home deserves a written explanation.
• Find the telemetry. Opt-in or opt-out, what is collected, and whether it is documented anywhere a user would actually look.
• Inspect the update channel. Auto-update is remote code execution by the maintainer, on a schedule. Know whether it exists, and know how to pin a version you have read.

The supply chain is the scarier half

The agent's own code is usually the smaller problem. An npm-installed agent pulls in hundreds of transitive dependencies, each one an author you have never vetted, shipping code that runs with the agent's privileges. That means your shell, your credentials. Registry compromises and typosquats are routine at this point, and install-time scripts mean malicious code can run before you ever launch the tool.

The defenses are boring and they work: pin exact versions, install with lifecycle scripts disabled where practical, review lockfile diffs when you upgrade, and prefer agents that ship as a single static binary (fewer strangers to trust). Upgrading a week behind the bleeding edge is a security control, not negligence.

Open is an invitation to verify, one almost everyone leaves on the table.

Auditable is not audited

The comforting story is that open source means many eyes have already checked. For a coding agent with one maintainer and a modest star count, assume the true number of people who have read the permission logic end to end is close to zero. Diffusion of responsibility guarantees it: everyone assumes someone else did the reading. Stars are not an audit. A big install count is not an audit. Your read-through may genuinely be the first.

So layer defenses that do not depend on the code being clean. Run agents inside a sandbox with least-privilege API keys and no ambient cloud credentials. And assume prompt injection will eventually steer your agent, because an attacker who can get text into its context (a README, an issue, a scraped web page) does not care how clean the agent's own source is.

Open agents remain the right call. The open CLI ecosystem is where the most interesting work is happening, and auditability is a real advantage over closed tools you cannot inspect even in principle. Spend the hour anyway. Read the tool definitions, check the defaults, pin the versions, sandbox the rest, and re-run the audit when the version bumps. Trust the agents you have read; contain the ones you have not.