Claude Code vs OpenCode: security posture compared

Choosing between Claude Code and OpenCode is, in part, a security decision, and it is easy to make it badly. The marketing comparison is about models and features. The security comparison is about one thing: what happens to your credentials while the agent works. Both tools put an LLM in front of your terminal with permission to read files and run commands. Their security posture is defined less by their differences than by the exposure surface they share.

The shared exposure surface

Both agents read environment variables, config files, and .env files when they start. Both spawn subprocesses that inherit the agent’s environment. Both assemble a context window from everything they read, and both persist session history locally. That means the same three failure modes apply to each: a key in the environment ends up in context, a subprocess echoes a variable to stdout and the transcript, and a session file keeps the value around in plaintext. Permission systems do not change any of this, because permissions gate commands, not reads. Reading a file is not an action that triggers approval — it is the agent’s job.

Where they genuinely differ

There are real differences, and they are worth stating precisely. Claude Code is a closed-source product: you cannot audit the binary, and you rely on the vendor’s release process and incident response. OpenCode is open-source: the code can be audited, but the auditing burden is yours, and you are responsible for supply-chain hygiene across its dependency tree. On approvals, both prompt for permission on risky actions, and both support non-interactive modes where approval is bypassed — which is exactly when secrets need the most protection. On model routing, OpenCode is provider-agnostic, which means the API that receives your context is something you select and should scrutinize.

None of these differences changes the fundamental property: whichever agent you run, the things it reads become model input. The vendor’s posture is a factor worth weighing; your secret-handling posture is the dominant one, and it is the one you actually control.

What actually determines your risk

Three controls matter more than the choice of agent. First, credential injection: can you run the agent so that secrets are resolved at subprocess spawn time and never exported into the shell it inherits? Second, egress filtering: is outbound traffic scanned for secret patterns before it reaches the model API, and does the filter handle encoded variants of known values? Third, session hygiene: when history is written to disk, can it be scrubbed, and does scrubbing rebuild indexes so the values are truly gone?

These are the same controls regardless of which agent you pick, which is good news: you can decide on merits other than security, then fix the exposure with tooling that wraps either one. trustless runs alongside Claude Code or OpenCode — trustless run wraps the agent invocation with injection and output sanitization, trustless serve puts a DLP reverse proxy in front of the model endpoint, and the audit log records every access. It reads your existing pass or Bitwarden store, so adopting it does not change where your secrets live. See the architecture docs for how the layers fit together.

Which of the two agents would you trust with a production API key in its context window — and what would you change to make that answer feel safe?