This is a developer-tooling incident rather than a Windows flaw. OpenCode runs on Windows, though, and a stolen AI key is a billing problem on any platform.
What OpenCode has said
According to BleepingComputer, OpenCode announced on Saturday, October 17, that it had suffered a breach "related to a large-scale distillation attack." It said it had emailed the affected users that morning. It added that anyone who didn't get an email wasn't affected.
Several details come from the project and from the reporting around it:
- Entry point: The Hacker News reports that an intruder reached a legacy system at OpenCode on the night of October 16. The notice, as quoted by Expert Insights, described unauthorized access to a legacy system the company was decommissioning. It said third-party provider keys saved in a workspace may have been exposed.
- Timing: BleepingComputer says the email put the earliest possible exposure at October 17, 2026, 00:30 UTC. The email also said no data appeared to have been exposed. That is the company's own assessment, and nobody has independently verified it.
- Duration: Co-founder Dax Raad said attackers had been targeting OpenCode's systems for at least 48 hours, using AI agents. The Hacker News reports he said on X that attackers were still trying on October 18.
- Response: OpenCode said it was working with Anthropic, OpenAI and Google. Raad said the situation stabilized once the team began using OpenAI's Daybreak cybersecurity model for defensive work. He also said its investigation was blocked at first because the AI models it was using refused some requests under built-in safeguards.
What "distillation attack" means here
Distillation is a legitimate technique. A smaller, cheaper model is trained on the outputs of a stronger one. BleepingComputer notes it becomes an attack when it relies on large-scale unauthorized queries.
Console is OpenCode's optional hosted service. A workspace saves its own OpenAI, Anthropic or Google key there, and Console uses that key to call the provider. A stolen key would let an attacker send those queries on the victim's bill.
Treat the label with some caution. OpenCode has not publicly said how the attackers got in, what the legacy system was, how many keys it held, or how many users 1.4% represents. Notebookcheck reported unauthorized usage on users' accounts, but OpenCode's own wording is only that keys "may have been exposed." It has not said any key was copied or used. "Distillation" is the company's characterization, not an independently confirmed finding.
Who is and isn't in scope
The distinction that matters is where your key lived.
| How you use OpenCode | Where the provider key sits | Relationship to this breach |
|---|---|---|
| Key pasted into a Console workspace | OpenCode's hosted Console | Potentially exposed, if you received the email |
| Key added in the local CLI or desktop app | On your own machine | Not part of the reported breach, per Raad |
Raad wrote that the breach involves "the OpenCode Console, not OpenCode itself," and that those keys "never come to us." OpenCode's documentation says Console adds the provider credential before forwarding a request, so the secret stays in the workspace during normal gateway use. That is also why a Console-stored key is a bigger risk than one held locally.
The same documentation says local OpenCode data can include API keys and OAuth tokens. On Windows that is %USERPROFILE%\.local\share\opencode, in a file called auth.json. Nothing in the reporting ties those local files to this incident. They do hold secrets, so treat that folder like any credential store regardless.
Two more boundaries from the evidence:
- No affected OpenCode version or operating system has been named. The changelog shows releases on October 15 and 16, but nothing links any of them to the breach, so don't treat updating as a fix.
- The 1.4% figure covers Console users only. It is not a share of all OpenCode users, and it is not a share of keys.
What to do if you got the email
Deleting a key from Console does not revoke it at the provider. The Hacker News also points out that a Console budget can't cap abuse, because Console only sees requests that pass through its own gateway. Work at the provider instead:
- Revoke the key in the provider's own dashboard (OpenAI, Anthropic or Google), then create a new one.
- Update everything that used the old key. That means every application, script and CI job.
- Review usage and billing for requests you didn't make. The Hacker News advises going back at least to October 16, because OpenCode hasn't said when the unauthorized access began.
- Set a spend limit or alert at the provider. Give each tool its own key, so a copied key does less damage and is easier to trace.
- Check Google Cloud projects for suspensions. Some users report Google suspended projects after detecting "abusive activity consistent with hijacked resources." The reporting doesn't describe a standard reinstatement route, so use Google's account and billing support channels.
If you didn't get an email, OpenCode says you weren't impacted. That is the company's stated scope, not an audit result. A cautious admin might still rotate any key that ever sat in a hosted workspace. That is general good practice, not something OpenCode has asked for.
The money
User-reported losses vary. BleepingComputer cites several hundred dollars up to $1,700 overnight. The Hacker News relays reports of $281 on one OpenAI key and $168 on one Anthropic key. It also relays $400 on an Anthropic account and about €200 of Google usage. These are individual claims, not a verified total.
OpenCode's email mentions possible reimbursement. The conditions, process and amounts haven't been published. BleepingComputer says OpenCode hadn't responded to its request for more details as of publication.
The bigger lesson
Hosted agent platforms are now credential vaults, whether or not they meant to be. Convenience features like team workspaces mean a provider's bearer key sits in someone else's database. Here the exposure came through a legacy system that was supposed to be going away. Old infrastructure that lingers is a familiar way for breaches to happen. That is general industry observation, not a finding from this incident.
For developers and IT admins, the habits are standard:
- Use one key per tool.
- Use provider-side spend caps.
- Rotate quickly.
- Prefer short-lived credentials where a platform supports them. OpenCode's own Console documentation lists service-account keys with permissions and optional expiry dates.
Whether OpenCode's disclosure holds up will depend on the technical follow-up it has not yet given. For now, the practical advice is the same for everyone with a Console-stored key: revoke it, replace it, and watch the bill.