OpenAI and Anthropic Keys Stored in OpenCode Console Leaked, the Local CLI Is Not Affected

Anomaly Innovations, the company behind the open-source coding agent OpenCode, disclosed a security breach on October 17. An outsider reached an old system that was in the middle of being decommissioned, and OpenAI, Anthropic and Google API keys saved in user workspaces may have been exposed. The blast radius is roughly 1.4% of the users of OpenCode Console, the company's hosted service.

If you only run open-source OpenCode in a terminal, this incident does not touch you. The official docs say a key added through /connect is written to ~/.local/share/opencode/auth.json on your own machine. You can also point opencode.json at an environment variable, as in {env:ANTHROPIC_API_KEY}. Keys travel to OpenCode's servers only when you connect your own provider account to Console, which is a separate product.

That distinction got lost for a while because the Hacker News submission was titled "OpenCode Hacked." In that thread, which reached 435 points and 75 comments, the submitter and several other participants repeatedly asked for "Console" to be put in the title. One commenter asked whether local CLI users bringing their own keys were out of scope. The OpenCode repository showed 215,127 stars as of October 18. At that size, a lot of people were always going to misread the blast radius.

Where the keys were sitting

OpenCode Console is optional, and nothing in the agent requires it. The docs describe Console as an AI gateway and list four ways to start: the Go subscription at $10 per month, Go Plus at $40 per month, buying credits, or "connecting your own provider accounts through the Console gateway." That last path is the one that broke. To skip paying OpenCode and keep billing your own OpenAI or Anthropic account, you have to store that account's key in your Console workspace.

This arrangement is usually called BYOK, bring your own key. In plain terms, the middleman service calls the model on your behalf and bills your account instead of charging you its own subscription. For that to work the middleman has to hold your key, so key custody is not an option in this design, it is the premise. Commenters in the HN thread pointed out that OpenRouter offers the same feature. This is not an OpenCode invention. Keeping keys local in an open-source binary and keeping keys on a server in that company's hosted service are two separate trust decisions. An MIT license and 215,000 stars say nothing about how the hosted side stores secrets.

Here is what applies today.

What "large scale distillation attack" does not explain

The company's notice on X called this "a security breach related to a large scale distillation attack." Distillation normally means pushing a large volume of queries at one model, collecting the answers, and training a different model on them. Running models on someone else's stolen key to feed that process is a coherent motive. But a motive does not explain how stored keys left the building.

That explanation was the single most repeated demand in the HN thread. One commenter wrote that the two framings, a security breach and a distillation attack, do not line up. The submitter asked for detail on how a distillation attack leads to credential exposure. The company answered only that "the incident is ongoing so we cannot share more details at this point." As of October 18 there is no public status page and no postmortem on opencode.ai. The newest changelog entry is v2.0.32 from October 16, with nothing about the breach.

Collected, the unanswered questions are: which system was breached, what the flaw was, how long the access lasted, how many people 1.4% is, whether the exposed keys were actually used (the company says it cannot tell), and who pays for unauthorized usage. Users reported charges they did not make, one over $400 in a single night, but neither the company nor the providers have confirmed any of those cases.

This is not a company that ignores security reports. GHSA-632h-h47v-g4x4, published September 24, covered a flaw where a malicious web page could call the upgrade endpoint on OpenCode's local server and get an arbitrary npm package installed. Datadog Security Labs reported it on August 11. Anomaly shipped the fix in 1.18.22 two weeks later. Affected versions ran from 1.14.30 through 1.18.21 for installs via npm, pnpm and Bun. The pattern of a coding agent's local server becoming the attack surface also came up in our piece on SHA pinning in coding-agent plugins.

Anomaly did not request a CVE for that one either. Without a CVE, vulnerability scanners and dependency audit tools cannot flag the flaw automatically. Fast fixes paired with narrow disclosure is this company's established pattern, and handling this breach through two posts on X is the same choice.

You can hand over a key and still cap what it can do

For readers who do not use Console, there is one thing worth taking from this. When you give a provider key to a third party, narrow what that key is allowed to do before you hand it over. Both providers already document the mechanism.

Anthropic attaches a scope object to every API key. Issue it with {"type": "workspace", "workspace_id": "wrkspc_..."} and the key works only inside that workspace. {"type": "organization"} reaches every workspace the account can touch. Keys can also carry an expires_at timestamp. OpenAI issues keys per project. Its production best practices guide tells you to set custom rate and spend limits per project, and documents setting an expiration date when you create a project API key alongside a monthly hard spend cap.

The difference shows up on the day of the incident. Hand a middleman one organization-scoped key and the moment it leaks the whole account is open. A key pinned to a dedicated workspace or project with a spend cap of a few tens of dollars a month takes the same hit and stops there. The reason a $400 overnight bill stops at $400 is a single limit setting. The HN thread also produced a call for every key system to ship a revocation endpoint, and a suggestion to pull keys out of the agent entirely and put a proxy in front.

If you have ever connected a provider account to OpenCode Console, revoke that key now and issue a new one whether or not you got the email. The company itself says it cannot verify whether the keys were used, and 1.4% is a figure from an investigation that is still running. Do the revocation in each provider's own console rather than through a link in the email, and scan your usage records from October 16 onward while you are there. When you mint the replacement, pin it to a dedicated workspace or project and attach a spend cap and an expiry, so the next time some middleman gets breached the bill stops at a number you picked.