OpenCode Console breach may have exposed users' stored OpenAI and Anthropic keys

What happened

OpenCode, an open-source AI coding agent that developers run from a terminal, told affected users on 17 October 2026 that an attacker had reached a legacy system the company was in the middle of decommissioning. In an email sent under the subject line "Action Required: Potential provider key breach", quoted in a write-up published on dev.to, the company warned that third-party credentials, including OpenAI and Anthropic keys, saved in a Console workspace may have been exposed.

The hosted Console is the part of OpenCode that handles accounts, workspaces and the provider keys some users link to it. OpenCode put the impact at 1.4 percent of Console users, a subset of those who had connected external providers, and described the incident as a large-scale distillation attack, a label the write-up treats as unexplained until the company publishes a follow-up. OpenCode said it emailed everyone affected, that users who received no email were not affected, and that it was working with Anthropic, OpenAI and Google on remediation.

What the notice leaves open

OpenCode has not said whether the exposed keys were actually stored in the legacy system, how the attacker got in, how long the access lasted, or how many accounts the 1.4 percent figure represents. As the dev.to write-up observes, the percentage measures neither exposure nor loss.

The write-up's broader argument is that decommissioning is most dangerous in the middle: traffic moves off a system first, while its credentials can stay in place after the attention has gone. A system in that state keeps the access that made it a target but loses the scrutiny a production system receives. OpenCode has not described its own retirement plan, so this remains the author's reading rather than a confirmed account of events.

The remedy OpenCode gave users is telling: revoke and replace the keys through the provider's dashboard, update any applications using them, and review recent usage. That instruction describes where the control actually lives. The customer's credential could only be invalidated at the provider, by the customer, and every hour between the breach and the user reading the email was an hour in which the key still worked.

Why the bill lands on the customer

A provider key saved in a vendor's workspace still belongs to the customer's provider account. It carries that account's identity, quota, payment method and guardrails, which is why this class of breach tends to resurface as an invoice. The write-up notes user reports of bills running into the hundreds of dollars, while labelling them as unverified, with no figure from OpenCode behind them.

The mechanism is simple: to a provider's billing system, an attacker holding a valid key is the customer, and nothing in the request distinguishes a distillation run from a legitimate batch job.

The write-up also prices the two custody models at stake. When a vendor resells model traffic, the keys in its systems are its own and a leak draws on the vendor's account. When you link your own key, you keep the direct provider relationship but take on the identity risk: your provider account becomes the blast radius of someone else's perimeter.

The status page carried no signal

On 19 October, two days after the notice, OpenCode's status page listed the Console API, the component covering the dashboard, workspaces and keys, as operational. The only open item was a slow-response incident that began at 16:44 UTC and was still marked ongoing nearly seven hours later. The security signal travelled elsewhere: a researcher posted a screenshot of the customer email at 15:30 UTC, and the company confirmed publicly at 18:08 UTC. A status page tracks availability, and teams monitoring one for evidence of a security event are watching a channel that was never built to carry it.

Why it matters

Anyone using an AI coding tool that accepts linked provider keys is running the same arrangement that failed here: the credential ties the vendor's perimeter to your provider account, your quota and your payment method. The write-up recommends four controls that survive a vendor breach: one key per tool, a spend limit at the narrowest scope the provider offers, log retention long enough to reconstruct usage, and a revocation runbook that does not wait for the vendor's confirmation.

The incident is also a lesson in decommissioning hygiene. A legacy system that stays reachable while being retired can hold live credentials long after it stops earning operational attention, and a single compromise there can put keys tied to customers' own accounts at risk.