OpenCode Console Breach: What Is Claimed, What Is Verified, and Which Keys to Rotate

Update, October 22, 2026: Railway confirmed attackers read customer environment variables to reach AI provider keys, and OpenRouter was named in an unconfirmed breach claim. See the Railway breach and the OpenRouter claim.

OpenCode's maker, Anomaly Innovations, has told roughly 1.4% of OpenCode Console users that third-party provider keys saved in their workspace "may have been exposed" after "unauthorized access to a legacy system." If you linked an OpenAI, Anthropic or Google key in the Console and received the email, rotate those keys at each provider now. This post separates what the company has stated from what is still unconfirmed.

TL;DR

What is claimed and what is verified

OpenCode posted on X on October 17 that the incident was "a large scale distillation attack that impacted 1.4% of OpenCode Console users," per Cyera's write-up, which reproduces the statement. We could not retrieve the post ourselves, so quotes here come from secondary coverage of it.

Stated by the company (via coverage):

• The notice said it identified unauthorized access to a legacy system, reportedly one being retired.
• Third-party provider keys "saved in your workspace may have been exposed," per Startup Fortune.
• It is working with Anthropic, OpenAI and Google, has found no evidence of other data leaking "to date," and cannot confirm whether exposed keys were used maliciously.

Not confirmed:

• How attackers got in, when it was first detected, and what 1.4% equals in accounts.
• How the keys were stored, for example whether they were encrypted.
• Whether keys in local config files were touched.
• Reports of bills "climbing into the hundreds of dollars" and of suspended provider accounts are user claims on social media and in press; the outlet could not verify them.
• The "distillation" label. Harvesting model outputs does not explain how keys were obtained, so the confirmed fact is the legacy-system access, not the attack category. explainx.ai has the news timeline.

Console keys versus local keys

The distinction that matters most for readers is where a key lived. Cyera describes the OpenCode Console as "the hosted layer where teams share models from a workspace, set budgets, and connect their own model providers." A team lead pastes an OpenAI, Anthropic or Google key into the workspace, and developers then use models through that workspace. The key therefore sits in the vendor's storage, not on any developer's laptop.

That changes the threat model in three ways:

1. Your endpoint hygiene does not help. A key in a vendor database can leave without anything running on your machine. No process monitor on a developer laptop would have seen it.
2. Deleting the key in OpenCode does not revoke it. Cyera makes this point directly: removing a key from OpenCode "doesn't stop someone who already copied it." Only the provider can make the key stop working.
3. Console budgets do not cap the damage. Cyera notes that Console budgets cover only spend that runs through OpenCode, so a stolen key used directly against the provider is outside them. The only brake is a spend limit set at the provider.

The open-source app and CLI are a separate case. Co-founder Dax Raad said, as quoted by TechCrunch, "this is the OpenCode Console, not OpenCode itself, those keys never come to us." If you run OpenCode locally with a key in your own environment, nothing published so far says that key was exposed. Cyera reaches the same view and still calls rotation "cheap insurance."

Timeline of what is documented

All times are as published by the sources named.

• Night of October 16 to 17. TechCrunch reports that attackers broke into an older system overnight. OpenCode says the breach happened "last night" relative to its post, and Cyera advises checking provider usage from October 16 onward.
• October 17, 17:56 UTC. OpenCode posts on X that 1.4% of Console users were affected and that it had already emailed them. Cyera's write-up appeared the same day and says the email attributed the intrusion to a legacy console system the company was retiring.
• October 17 to 18. The incident is discussed on Hacker News and Reddit, covered below.
• October 19. TechCrunch reports that Anthropic and Google blocked the keys they believed were exposed, that OpenAI worked with OpenCode on refunds, and that OpenCode says refunds are underway. It also reports Raad's statement that attackers had tried to break into its systems "nonstop for 48 hours."

TechCrunch adds one detail the other sources do not: the breach occurred the same night OpenCode made a model called GLM-5.3-Flash free for users. The article presents this as coincidence of timing, not as a cause, and so do we.

The distillation label

OpenCode's wording is "a large scale distillation attack." Distillation, in this context, means using a model's outputs at scale to train another model. Cyera links the term to a September report in which, it says, Anthropic described campaigns by China-based AI labs that pulled roughly 190 million exchanges from Claude, partly through "illegally harvested API keys." We have not checked Anthropic's report ourselves, so treat that figure as Cyera's account of it.

TechCrunch frames it more carefully. It notes that leaked keys can help users in countries with restricted access to American models produce the high volume of output distillation needs, and that "some skeptics called the framing an overstretch, arguing that the incident was a straightforward breach whose use for distillation remains unproven." No one has publicly attributed the attack, according to Cyera. For a defender the label changes nothing about the response: a key that left your control has to be replaced, whatever it was used for.

What developers are saying

The main Hacker News thread had 54 points and 28 comments when we read it. A few comments are worth recording as the commenters' own views and reports:

• nl quoted the company's statement and asked why it was being called a distillation attack, which is the same question skeptics raised elsewhere.
• cdurth wrote that the company recommends rotating keys after a breach while, in the commenter's account, also disrupting access for existing keys, and said they would not use the service. That is one user's reading, and we have not confirmed what happened to access.
• On a later thread about the refunds, sixothree said the intrusion timeline did not look fully honest, because they had begun getting unusual account-recovery phone calls about a month earlier that leaked two pieces of information they tied to OpenCode. This is a single unverified report, and the company has not said anything that supports or contradicts it. We include it because it is a reason to check your own account activity over a longer window than the past few days.

What the providers advise

The incident fits the general key hygiene that providers already document. OpenAI's API key safety guide recommends a unique key for each team member, keys created with an expiration date, and a rotation routine: create a replacement, update your applications, and revoke the old key "once you've verified that the replacement works." It also says administrators can enforce a maximum key lifetime at the organization or project level, and recommends workload identity federation for supported workloads, where a workload exchanges an identity from a trusted provider for a short-lived access token instead of storing a long-lived key.

Two of these directly limit a repeat of this incident. Short-lived keys shrink the window in which a stolen key works, and per-person keys mean a leak identifies whose key it was and does not take down a shared one.

A separate lesson: defenders and refusals

TechCrunch reports that OpenCode's team used AI models to analyse the malicious code, and that the models "started refusing to work" when the code tripped safety filters. Raad called this "a bit frustrating." The team later gained access to OpenAI's Daybreak Blue program, which provides vetted users with models less likely to refuse defensive security work. TechCrunch notes that Hugging Face reported something similar in July; Beam covered that case in our Hugging Face autonomous agent breach post. This is a point about incident response tooling, not about the Console keys, but it is a reminder to plan how your own team will analyse hostile code if general-purpose assistants decline.

What this means if you run AI coding agents

1. Check your inbox first. An email from OpenCode is the company's own signal of impact. Do not click links in it; go to the dashboards directly.
2. Rotate at the provider. Revoke and reissue in the OpenAI, Anthropic and Google consoles, update the tools and CI jobs that use the key, and confirm the old one fails.
3. Review usage from October 16 onward for spikes, unfamiliar models and odd hours.
4. Set hard spend limits and alerts on every provider account, and use one key per project so a leak has a small blast radius.
5. Remove providers from the Console you no longer use, and reset your OpenCode password.
6. Consider rotating anyway. If you never received an email but pasted keys into the Console, rotating costs little, even though the company says you were not affected.

OpenCode has had other security trouble this year: Datadog Security Labs documented a remote code execution flaw in its upgrade endpoint (GHSA-632h-h47v-g4x4), fixed in 1.18.22. That is a separate issue from the Console breach and unrelated by anything published, but it affects the same readers, so here is how to check it.

Datadog says the flaw is exploitable only if all three of these apply:

• You use OpenCode 1.14.30 through 1.18.21, inclusive.
• You run opencode serve or opencode web without password authentication, or your browser has cached credentials from a recent authentication.
• You installed OpenCode through npm, pnpm or Bun. Datadog suggests confirming the install method with ls -l "$(command -v opencode)".

The mechanism was a content-type confusion in the /global/upgrade endpoint: a malicious web page could send a cross-origin form post to the local server, and the version string was passed to npm install -g opencode-ai@VERSION, which also accepts a remote tarball URL. Datadog reports that the 82 vulnerable versions had more than 647,000 downloads from September 17 through 23, 2026, and says the web interface requires no authentication by default. Setting OPENCODE_SERVER_PASSWORD enables basic authentication, and updating to 1.18.22 or later fixes the flaw.

Update (October 18, 2026): the company's own post is now confirmed

We have now retrieved OpenCode's original post on X, published October 17 at 17:56 UTC. It reads, in three short paragraphs: "We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users", "We have notified them all this morning via email", and "The incident is ongoing so we cannot share more details at this point but we are working with Anthropic, OpenAI, and Google to remediate".

That confirms the 1.4% figure, the email notification and the work with the three providers directly from the company. It adds nothing on how attackers got in, how keys were stored or whether any were misused, so the "not confirmed" list above stands. The company describes the incident as ongoing, so keep rotating keys and watching provider usage rather than waiting for a final report.

Update (October 19, 2026): providers blocked keys and refunds are under way

TechCrunch's follow-up adds several facts beyond the company's X post. Anthropic and Google reportedly blocked the keys they believed were exposed, and OpenAI said it worked with OpenCode to restore access and refund credits used in the attack. OpenCode says refunds for unauthorized charges are underway. Developers reported spending alerts from all three providers, with some single charges in the hundreds of dollars and a few over $1,000; those figures are user reports.

Co-founder Dax Raad said the open-source app and CLI were not affected because "those keys never come to us". That supports the narrower reading above: the exposure was limited to keys saved in Console workspaces. The company still has not explained the entry method, how keys were stored, or why it calls the incident distillation, and describes it as ongoing. If a provider blocked a key of yours, you still need to issue a new one and update CI; a blocked key is not a rotated key.

What Beam can and cannot do here

Beam did not see this attack: the keys were taken from a vendor-side system, not from your machine. What Beam can do is shrink what is lying around locally. It flags credential exposure in agent tool calls on Claude Code and Codex, and redacts known credential formats before storage, all on-device. It does not rotate keys, cannot see a vendor's servers, and its detection is heuristic. See how Beam works and the local-first design.

Beam's documentation lists OpenCode only for config and artifact discovery, with hook installation not implemented, so Beam cannot deny actions inside OpenCode the way it can for Claude Code and Codex.

For related reading, see the criminal AI API key reseller supply chain, agents harvesting credentials from loot folders, fake Claude Code installers, our incident timeline and the vibe coding security checklist.

Related reading: Claude session-bridge tokens and artifact uploads, another case of bearer tokens reused outside their intended surface.

Frequently asked questions

Was I affected by the OpenCode Console breach?

OpenCode says it emailed every affected account and that users who received no email were not impacted. Only Console users who had linked external providers such as OpenAI, Anthropic or Google were affected, about 1.4% of Console users by the company's count.

Are keys stored only in my local OpenCode config exposed?

Unknown. The company's notice refers to provider keys saved in a Console workspace. It has not said whether keys in local config files were involved, so treat any key you ever pasted into the Console as suspect.

How should I rotate the keys?

Revoke and reissue each key in the provider's own dashboard by going there directly, not through an emailed link. Update your tools and CI, confirm the old key no longer works, and review usage from October 16 or 17 onward.

Was it really a distillation attack?

That is OpenCode's label. Distillation means harvesting model outputs, which does not by itself explain how keys were obtained, and the company has not published technical detail. Judge by the confirmed fact: unauthorized access to a legacy system.

Does this affect Claude Code or Codex users?

Only if you also used OpenCode Console and saved a provider key there. The wider lesson is that a key stored in any third-party service is only as safe as that service.

Separately, OpenCode the agent had its own flaw: see OpenCode MCP OAuth flaw: remote code execution on Windows and WSL, which is unrelated to this breach.

Related reading

• API keys in logs and env vars: how they leak and how to catch it
• Your first 24 hours after a vendor breach: a rotation and monitoring runbook
• What app monitoring can and cannot catch when your platform is breached

Details reflect public statements as of October 20, 2026 and may change as OpenCode's investigation continues.