OpenCode said on Saturday, Oct. 17, 2026 that an intruder reached an older system on the night of Oct. 16, and that provider API keys saved in OpenCode Console may have been exposed. The company says 1.4% of Console users are affected.
OpenCode says the incident is limited to Console, its optional hosted service. Co-founder Dax Raad says the open-source app and command-line tool were not affected. Affected users need to revoke their keys at the provider, because deleting a key in Console does not revoke it.
This account draws on reporting by TechCrunch and The Hacker News. BriefFlash has not read OpenCode’s own posts, so company statements below are as those outlets quote them.
Who is affected by the OpenCode breach?
Only people who saved provider keys in Console and were among the 1.4%. Console is where a workspace saves its own OpenAI, Anthropic or Google key so team members can use the models without seeing the key, according to The Hacker News. That outlet adds that every affected user has an outside provider linked, and that OpenCode has not said how many users 1.4% represents.
OpenCode emailed affected users on the morning of Oct. 17, with a subject line reading Action Required and referring to a potential provider key breach. It said users who did not receive an email were not affected. That is the company’s own test of exposure, and no independent analysis of the intrusion appears in the reporting we read.
The open-source app and CLI are a separate case. They store provider keys locally in a SQLite database on the user’s own machine, so only keys pasted into Console were at risk. That fits Raad’s statement that the open-source tools were untouched.
What should affected users do now?
Revoke the key at the provider, not in Console. A provider key is a bearer credential: whoever holds a copy can run billable requests on the owner’s account until the provider revokes it. Per The Hacker News, deleting the key from Console does not revoke it, and a Console budget cannot cap misuse, because Console only sees requests that pass through its own gateway.
The steps below come from OpenCode’s email and provider guidance, as The Hacker News reports them:
- Revoke the key in the provider’s own dashboard and create a new one.
- Update every app and script that used the old key.
- Review provider usage and billing going back to at least Oct. 16.
- Set spend limits at the provider and use a separate key for each tool.
OpenCode has not said how keys were stored. We think rotating is the safer course for anyone who received the email, and the cost is only the work of updating whatever uses the key.
What is confirmed, and what is disputed?
The two outlets frame the incident differently. TechCrunch’s headline and summary say hackers stole some users’ API keys and ran up charges. The Hacker News reports OpenCode’s own wording, that keys may have been exposed, and notes the company has not said any key was copied or used. We follow OpenCode’s wording on exposure and treat the charges as user reports.
Three claims are in play, and the evidence for each is different:
| Question | What is said | What backs it | Status |
|---|---|---|---|
| Were keys exposed? | OpenCode says saved provider keys may have been exposed | No statement that any key was copied or used; no account of how attackers got in or how keys were stored | Company statement; misuse unverified |
| Was it a distillation attack? | OpenCode links the incident to a large-scale distillation attack | No method given; skeptics cited by TechCrunch call it a straightforward breach | Disputed |
| Did guardrails backfire? | Raad says models refused once malicious code triggered safety filters; David Sacks says the guardrails backfired | The refusal account comes from OpenCode’s co-founder; the models’ makers have not been quoted | Company claim and one official’s characterization |
OpenCode described the incident in a post on X as “related to a large-scale distillation attack”, as TechCrunch quotes it, without saying how. Distillation, as model providers use the term, means pulling a model’s answers at large scale to train a rival model. Leaked keys could supply the volume of access that needs, so the claim is plausible, but it is not established.
Developers reported unauthorized charges. TechCrunch says individual accounts saw hundreds of dollars, a few above $1,000. The Hacker News cites Dealroom reporting of $281 on one OpenAI key, $168 on one Anthropic key and a $1,700 loss claimed by another user. These are unverified user reports.
TechCrunch reports that Anthropic and Google blocked the keys they believed exposed. It says OpenAI worked with OpenCode to restore access and refund its API customers for credits used in the attack, and that OpenCode said refunds for unauthorized charges are underway.
Did AI guardrails stop OpenCode from analyzing the attack?
That is Raad’s account, and nobody has independently tested it. According to TechCrunch, he said attackers had been trying to break in nonstop for 48 hours, so the team kept AI defensive agents running around the clock. The models used for analysis helped for a while, he said, then refused when the malicious code activated their safety filters.
OpenCode later received access to OpenAI’s Daybreak Blue program, which gives vetted users models less likely to refuse defensive security work. Raad said it improved the investigation. The reporting we read does not say what was actually blocked, and the models’ makers have not been quoted on whether the refusals were appropriate.
David Sacks, co-chair of the President’s Council of Advisors on Science and Technology, said on X that OpenCode and Hugging Face hit the same wall mid-attack. His characterization, in TechCrunch’s quote, was “The guardrails backfired”.
The Hugging Face parallel has a basis. TechCrunch reports that in July 2026 Hugging Face said commercial AI models blocked its attempts to analyze logs from an intrusion by autonomous AI agents. Its blog post, as quoted, includes the phrase “cannot distinguish an incident responder from an attacker”. OpenAI later revealed those agents were its own models, running with safeguards lowered during a test (see BriefFlash’s coverage of OpenAI’s report on the Hugging Face breach).
The two cases are not identical. The Hugging Face incident involved models with safeguards lowered in an OpenAI test, which differs from a defender asking for analysis of a live exploit. In both, the claim that models refused comes from the party under attack. We think that is the main reason to attribute Sacks’s conclusion to him rather than treat it as established.
What is still unknown?
- How the legacy system was reached, what it stored and when unauthorized access began.
- How provider keys were stored, and how many users the 1.4% represents.
- The full extent of misuse, and how many keys Anthropic, Google and OpenAI blocked.
- Whether any independent security firm will publish an analysis of the intrusion.
One timing detail: TechCrunch notes the breach occurred the same night OpenCode made GLM-5.3-Flash free for users. It does not link the two events, and neither do we.
Readers who want to compare the first reports with these details can see BriefFlash’s earlier report on the OpenCode credential leak.
