OpenCode's Console breach: what leaked, and how to stop pooling your agent API keys

The CLI was fine. The keys people parked in a hosted dashboard were not.

Published . Over the weekend of October 17, OpenCode disclosed that attackers had broken into a legacy system behind the OpenCode Console, its hosted web platform. Third-party API keys that users had stored in their Console workspaces may have been exposed. OpenCode put the affected share at 1.4% of Console users and emailed the people involved. Notebookcheck reported the first disclosure on October 17, and TechCrunch followed on October 19, describing unauthorized charges across OpenAI, Anthropic, and Google accounts.

If you use OpenCode only as the open-source terminal agent, this incident didn't touch your keys. Co-founder Dax Raad was explicit, as quoted by TechCrunch: “this is the OpenCode Console, not OpenCode itself, those keys never come to us.” The broader lesson still applies to everyone running coding agents. Every place you paste a provider key becomes part of your attack surface, and agent tooling encourages pasting keys everywhere.

What we know, and what we don't

Here is what the reporting supports:

  • Scope: the hosted Console, specifically an older system OpenCode was in the process of decommissioning. It did not affect the CLI or the open-source app.
  • What was exposed: provider API keys that users had linked to Console workspaces. OpenAI and Anthropic keys are named explicitly. Users also reported unexpected Google charges.
  • Impact: according to TechCrunch, some individual accounts saw charges in the hundreds of dollars and a few topped $1,000. These figures come from users' reports, not an audited total.
  • Provider response: TechCrunch reports that Anthropic and Google blocked the keys they believed were exposed, and that OpenAI worked with OpenCode on restoring access and refunding credits used in the attack. OpenCode says refunds for unauthorized charges are underway.

What we don't know matters just as much. OpenCode hasn't said how the attackers got in, how the keys were stored, or how much misuse there was in total, and it describes the incident as ongoing. It calls the attack a “large-scale distillation attack,” meaning the stolen keys were used to generate bulk model outputs. TechCrunch notes that this framing is disputed and unproven. Be cautious with any write-up that claims more certainty than that, including this one.

If you got the email: do this now

OpenCode's guidance, as reported, is to revoke and replace keys directly with each provider. Don't rotate them inside the Console. In order:

  • Revoke, don't just add. Create a new key in the provider's own dashboard, then delete the old one. A key you've stopped using but haven't revoked is still usable by whoever has it.
  • Read the usage logs before you dispute anything. Check the provider's usage page for activity since roughly October 16, and screenshot it. Users reported getting spend alerts before they got OpenCode's notice, so an alert you dismissed may have been the attack.
  • Update every consumer of the old key. That includes CI secrets, .env files on other machines, and other agents that shared the key. If you don't know every place it lived, treat that as a separate problem (see below).
  • Check social logins. Some users reported failed Google or GitHub sign-ins to the Console during the incident. If you used either, check that provider's list of authorized apps and sessions too.

If you didn't get an email, OpenCode says you weren't affected. Still, if you ever stored a key in the Console, rotating it costs five minutes and is cheaper than trusting a scoping statement from an incident that's still open.

The real problem: one key, everywhere

The common pattern looks like this. A developer creates one Anthropic key and one OpenAI key early on, then pastes them into Claude Code's environment, an OpenCode or Cline config, a hosted dashboard for team sharing, two CI pipelines, and a weekend side project. When any one of those leaks, the blast radius is all of them, and the bill arrives on the same account.

The fixes are boring, and they work:

  • One key per tool, per environment. Name them so you can tell where each is used (opencode-laptop, ci-nightly-evals). When one leaks, you revoke one key, and you can see from the usage page which one is being abused.
  • Separate projects or workspaces for agents. Most model providers let you group keys under projects or workspaces with their own limits. Put agent traffic in its own bucket so a runaway agent or a stolen key can't drain the budget your production app depends on. Check your provider's docs for what limits it actually enforces. A notification is not a cap.
  • Prefer local key storage for CLI agents. A terminal agent that reads a key from your shell environment or OS keychain keeps the key on your machine. Pasting the same key into a hosted dashboard so a web UI can use it adds a third party to your trust chain. Sometimes that's worth it for team features. Make it a deliberate decision.
  • Keep an inventory. A plain list of which key lives where turns the first step of this incident into five minutes of work instead of an afternoon of grepping across machines.

Two GitHub changes from this week that help

Model keys aren't the only credentials coding agents hold. Most of them also hold a GitHub token. Two recent GitHub changes reduce the damage when one leaks:

  • Expiring gh tokens. As of October 21, GitHub CLI v2.103.0 can store a short-lived OAuth token with a rotating refresh token. GitHub says a leaked token then “becomes unusable within hours instead of lasting indefinitely.” If you're already signed in, run gh auth login --expiring to sign in again. That replaces your existing non-expiring token. gh config set expiring_credentials enabled only sets the default for future sign-ins and leaves your current token alone. Then run gh auth setup-git so git uses the refreshing credential. One catch for agent setups: scripts that cache the output of gh auth token will break when it expires, so read it fresh each time.
  • Anthropic keys blocked at push. Since October 13, secret scanning push protection blocks both Anthropic key types, anthropic_service_api_key and anthropic_user_api_key, by default in repositories with secret scanning enabled, including free public ones. That catches the agent that helpfully commits your .env. It does nothing about keys stored in someone else's database, which is how this breach happened.

Verdict

Don't read this as “OpenCode is unsafe.” The open-source agent wasn't involved, and plenty of hosted AI dashboards hold the same kind of keys. Read it as a reminder that bring-your-own-key products pool many people's keys in one place, and that place is now a target. Keep keys local where you can and give each tool its own key, so the next breach costs you one revocation instead of a weekend spent hunting down every place a shared key lived. Separate keys limit what you have to rotate, not what an attacker can spend. Only a spending limit enforced by the provider caps the bill, so set one on the project those keys belong to.

We haven't tested OpenCode's Console or reproduced anything here. This piece is based on the reporting and first-party GitHub changelogs linked below, and we'll update it if OpenCode publishes a root cause.

Sources