OpenCode Hacked: What the Console Breach Means for Your API Keys

Last updated: October 17, 2026

If you stored an Anthropic, OpenAI or Google key in an OpenCode Console workspace, rotate it now, even if you have not seen an email yet. OpenCode disclosed on October 17 that it was breached, and the email it sent affected users says third-party provider keys saved in a workspace "may have been exposed."

The open source CLI running on your laptop with keys in your own environment is a different thing from the hosted Console. The distinction is the whole story, so it is worth getting precise about what was disclosed and what was not.

What OpenCode has said#

The OpenCode account on X posted that the team "had a security breach last night related to a large scale distillation attack" that impacted 1.4% of OpenCode Console users. A follow-up line in the same post says affected users were notified by email that morning, that anyone without an email was not impacted, and that it was "a subset of users who had external providers linked." The team says the incident is ongoing and that it is working with Anthropic, OpenAI and Google to remediate.

The email text was pasted into the Hacker News thread by the submitter. It says the team identified unauthorized access to a legacy system that was being decommissioned, that third-party provider keys saved in a workspace may have been exposed, and asks users to revoke and replace those keys, update applications that use them, and review recent usage. That email is a user-pasted copy, not a published advisory, so weigh it accordingly. Nothing here is confirmed beyond what the vendor wrote publicly: the number of keys, the attacker, and what "distillation attack" means in practice have not been explained.

Why a provider key was in their system at all#

This is the part that surprised many commenters. OpenCode's own Console providers documentation describes the feature: you connect a provider account you already pay for, enter its API key, and "Console stores the credential and serves each provider through its gateway, so members use the models without ever seeing the provider key."

That is a reasonable product for teams. It is also a design where a third party holds long-lived credentials with full spend authority on your provider account. The Console overview frames it as optional, with the same account also offering paid inference, usage tracking and budgets. If you never ran /connect against a workspace and only used the CLI with your own environment variables, you did not hand OpenCode a key.

What to do today#

1. Check whether you ever added a provider in the Console. Open the Providers tab of each workspace you belong to. Team admins should check on behalf of members, because members never see the key but it still lives there.
2. Revoke and replace in the provider dashboard first, then rotate inside the Console. Revoking at the provider is what actually kills a leaked key. The Console docs say a key is rotated by clicking the credential on the provider page and entering the new one, but that only replaces what the gateway holds.
3. Review usage on each provider account for the last several days: unfamiliar models, spikes in output tokens, requests from regions you do not use.
4. Set a spend cap or budget on the provider side. A cap you control stops a stolen key from running up an unbounded bill while you sort out the rest.
5. Search your repos and shell history for the same key pasted elsewhere. A rotated key that also lives in a .env file you committed is not fixed.

The angle: gateways are credential honeypots#

A hosted gateway that holds your provider keys concentrates risk the same way a password manager does, but with a weaker threat model attached. A coding agent harness is a developer tool, and the security work goes into sandboxing the agent on your machine, not into a multi-tenant credential vault. Our agent security checklist makes the same point from the other side: every integration you connect is a place a secret can leak from, so connect the fewest and give each the narrowest scope.

Who wins from this? Teams that keep keys in their own secrets manager and give agents short-lived, scoped credentials. Who loses? Anyone who used a gateway as a convenience to avoid exporting an environment variable. The convenience is real, and so is the blast radius.

The incident also lands next to OpenCode's own growth. The project has moved fast, with a version 2 rewrite and a very large user base described in our developer guide. A service that grew that quickly while a "legacy system" was still being decommissioned is a familiar failure shape: the old system is the one nobody is watching. The public wording makes that inference plausible, but it is an inference, not something the vendor has confirmed. For how other harnesses handle trust boundaries, see the coding agent security models comparison.

What people are actually saying#

Reaction on the Hacker News thread split into a few camps. One group wanted scope: users asked whether local-only CLI users were safe, and others replied that the affected product looks like the Console and OpenCode Zen gateway rather than the CLI, with one commenter suggesting the submission title should say "OpenCode Console." Another group questioned the wording, asking whether stolen credentials were used for a mass distillation campaign, and one commenter noted there is no public evidence of such a campaign and that a postmortem would be interesting. A third group pointed at earlier warnings about OpenCode's data handling, including a link to an older GitHub issue, which is a community claim and not something this post has verified.

On X, replies to the announcement mixed anger and skepticism about the framing, with some users saying a "distillation attack" is an odd label for leaked API keys and others asking about compensation for charges. Those are individual reactions, not confirmed losses.

The counter-case is worth stating plainly: the vendor disclosed quickly, said what to do, and says it is working with the providers. A same-day notice with actionable steps beats silence. Whether the fuller postmortem lives up to it is the open question.

One practical thread from the discussion: a commenter noted that GitHub's secret scanning partner program can get a provider to revoke a key when it appears in a public repository. GitHub documents that partner flow, but publishing someone's leaked key on purpose is a hack with real downsides. Rotate through the provider dashboard instead.

Continue Reading#

• The Agent Security Checklist I Use Before Connecting Tools - scoping every credential an agent can touch
• AI Coding Agent Security Models Compared 2026 - permissions and sandboxing across the major tools
• OpenCode Developer Guide - what the open source agent is and how it is configured
• OpenCode 2: How to Upgrade From v1 - the migration path and what changed

Sources#

• OpenCode security breach announcement - OpenCode on X
• OpenCode Hacked: User credentials leaked - Hacker News thread, includes the pasted email text
• OpenCode Console: Providers - OpenCode documentation
• OpenCode Console: Intro - OpenCode documentation
• Secret scanning - GitHub Docs