OpenCode Console Breach: API Keys Exposed, Accounts Drained — How to Check If You're Hit and Lock Down Your Keys

By AICoderScope Team · 13 min read
opencodesecurityapi-keysbyokai-coding-agents

TL;DR: On the night of October 16, 2026, an intruder got into a legacy OpenCode system that was being decommissioned and reached provider API keys — OpenAI, Anthropic, and Google — stored in OpenCode Console workspaces. OpenCode says 1.4% of Console users were affected and all of them were emailed on October 17; no email means you’re clear. The open-source CLI and app were not touched — keys configured locally never reach OpenCode’s servers.

OpenCode Console (breached)OpenCode CLI / app (not breached)Cline / Claude Code
Where your key livesOpenCode’s servers, per workspaceYour machine (auth.json, env vars, .env)Your machine (VS Code secret storage / local keychain)
Blast radius of a vendor breachEvery key stored in affected workspacesZero — vendor never holds the keyZero — vendor never holds the key
What to do this weekRotate every linked provider keyNothing (set spend caps anyway)Nothing (set spend caps anyway)

Honest take: If you got OpenCode’s October 17 email, rotate every linked key today and check your provider usage dashboards for October 16–17 — real users reported hundreds of dollars in unauthorized charges before providers stepped in. If you didn’t get the email, the actionable lesson still applies to you: stop parking API keys in any tool’s cloud console when a local config does the same job, and put a hard spend cap on every key you own.

What actually happened

OpenCode disclosed the breach on October 17, 2026, in an X post: “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. If you did not get an email you were not impacted.” TechCrunch picked the story up on October 19 under the blunter headline “Hackers hit AI coding tool OpenCode, running up charges on users’ AI accounts.”

The entry point, per The Hacker News and the Cloud Security Alliance Labs research note, was a legacy system in the process of being decommissioned — not the current Console infrastructure, and not the open-source codebase. From there the attacker could reach provider API keys that Console users had linked to their workspaces: keys for OpenAI, Anthropic, and Google.

Three details matter for scoping this correctly:

  1. “1.4%” is 1.4% of Console users, not of OpenCode users overall. The Console is the web platform where Zen (OpenCode’s hosted, pay-as-you-go model gateway) handles billing and key management. Most OpenCode usage runs through the CLI with locally configured providers and never touches the Console.
  2. Only users who had linked external provider keys were in the affected subset. If you used the Console solely for Zen billing with no external keys attached, OpenCode’s statement puts you outside the blast radius.
  3. The CLI and desktop app were not breached. Co-founder Dax Raad was explicit that the incident hit “the OpenCode Console, not OpenCode itself” — keys you configure in the CLI “never come to us.” That architectural line is the whole story, and we’ll come back to it.

OpenCode’s own wording is that keys “may have been exposed.” The charges that followed say more than the hedge does: affected users reported unauthorized API usage almost immediately. One developer cited by press coverage found $281 burned on an OpenAI key and $168 on an Anthropic key; Notebookcheck relayed reports of roughly $400 on an Anthropic account and around €200 in Google charges. Whatever “may have been exposed” means legally, some of those keys were used.

The provider response was fast. Anthropic and Google blocked the keys they believed were exposed. OpenAI said it worked with OpenCode to restore access and refund API customers for credits consumed in the attack, and OpenCode says refunds for unauthorized charges are underway. We found no public refund commitment from Anthropic or Google as of October 25 — if you ate charges on those providers, open a support ticket and reference the incident.

How to check if you’re affected — 5 minutes

Step 1: Search your email for OpenCode’s October 17 notification. OpenCode’s position is binary: affected users were all emailed the morning of October 17; no email, not affected. Check spam before you relax.

Step 2: Check each provider’s usage dashboard for October 16–17. Even if you trust the email check, usage data is ground truth:

  • Anthropic: Claude Console → Usage. Look for spikes you didn’t generate, then Settings → API Keys to see every active key.
  • OpenAI: platform.openai.com → Usage dashboard. OpenAI added per-key cost attribution in 2026, so you can trace a spike to the specific leaked key.
  • Google: AI Studio → usage for your Gemini API keys, or the Cloud Console billing report if your key is tied to a GCP project.

A distillation-style attack (more on that label below) looks like high-volume completion traffic — thousands of requests, sustained, often against the most capable model your key can reach. It is not subtle in a usage graph.

Step 3: If you ever stored a key in the Console, audit what else that key could touch. An API key scoped to your whole org is a bigger loss than one scoped to a hobby workspace. This is the moment to find out which kind you had.

Rotate your keys — the part people skip

Revoking at the provider is the only rotation that counts. Deleting the key from OpenCode’s Console removes OpenCode’s copy; the attacker’s copy still works until the provider kills it.

For each provider: create a new key first, swap it into your tools, confirm they work, then delete the old key.

  • Anthropic: Claude Console → Settings → API Keys → Create Key, then delete the exposed one. If you use workspaces, scope the new key to a single workspace — a leak then stays inside that workspace’s limits.
  • OpenAI: platform.openai.com → API Keys → Create new secret key, delete the old one. Prefer project-scoped keys over org-wide ones.
  • Google: AI Studio → Get API key → create a replacement, delete the exposed key. Keys created in AI Studio since May 2026 are restricted to the Gemini API by default, which caps what a thief can do with them — older unrestricted keys are worth replacing on principle.

Then update every place the old key lived. This is where people get burned twice: the key is in OpenCode’s Console, but also in a CI secret, a dotfile, a teammate’s .env. Rotation isn’t done until the old key returns 401 everywhere.

If you run the OpenCode CLI, your local credentials file tells you in ten seconds which providers you’ve configured locally (these were not exposed, but it’s the fastest inventory you have):

$ cat ~/.local/share/opencode/auth.json | python3 -m json.tool
{
    "anthropic": {
        "type": "api",
        "key": "sk-ant-..."
    },
    "opencode": {
        "type": "api",
        "key": "..."
    }
}

Every entry in that file stayed on your machine throughout this incident. Only keys you additionally linked in the Console web app were in scope.

”Stolen” vs. “may have been exposed” — and the distillation question

TechCrunch reported that hackers “stole some users’ API keys.” OpenCode has not confirmed theft, only potential exposure, and hasn’t said how the attacker got in, how long they had access, or whether stored keys were encrypted. Both framings fit the public facts; the unauthorized charges and OpenAI’s refunds establish that at least some keys were exfiltrated and used, which makes the distinction mostly academic for anyone deciding whether to rotate. Rotate.

The “large scale distillation attack” label is the contested part. Distillation means using stolen capacity on frontier models to generate training data for someone else’s model — it recasts the attacker as a model-building operation rather than an opportunistic credit thief. Skeptics quoted in the coverage called the framing an overstretch: what’s established is a breach and unauthorized usage; what the usage was for is OpenCode’s characterization, offered without published evidence. OpenCode says it’s working with all three providers on the investigation. Until someone publishes traffic analysis, treat “distillation” as a plausible hypothesis, not a finding.

To OpenCode’s credit: disclosure landed within a day, affected users got direct email, providers were looped in fast, and the co-founder answered questions in public instead of hiding behind a status page. Compare that to vendors in our earlier coverage who shipped silent patches. The transparency doesn’t erase the architectural mistake, but it’s the response you want when a vendor holds anything of yours.

The real lesson: never let a tool hold keys a config file can hold

This breach is the tenth-plus entry in our AI coding tool security series, and it’s categorically different from the ones before it. GitSpawn and OpenCode’s own RCE trio were code-execution attacks on your machine. This one never touched your machine. The attack surface was the vendor’s infrastructure, and the damage was financial — your key, their server, your bill.

That maps to a simple audit you can run on every AI coding tool you use: where does my key physically live?

ToolKey storageVendor breach exposes your key?
OpenCode CLILocal auth.json, env vars, .envNo
OpenCode Console (external providers)OpenCode’s serversYes — proven Oct 16, 2026
ClineVS Code extension secret storage, localNo
Claude CodeLocal keychain / configNo
Cursor (BYOK)Stored with your account for cloud featuresYes, in principle
Any web-based “connect your API key” consoleVendor’s serversYes, in principle

The pattern: terminal-native and extension-based tools keep BYOK keys client-side because requests go straight from your machine to the provider. Web platforms store keys server-side because their servers make the calls. Every server-side key is a standing bet that the vendor’s security — including legacy systems mid-decommission — holds forever. OpenCode users just saw how that bet settles.

Two defenses work regardless of which tool leaks next:

Hard spend caps on every key. OpenAI shipped enforced organization and project spend limits in July 2026 — requests return 429 once you hit the cap, which turns a $1,700 incident into a $50 one. Anthropic’s Claude Console supports per-workspace monthly spend limits (workspace Limits tab), and workspace-scoped keys inherit them. Google AI Studio has a monthly spend cap setting rolling out. Interfaces move — verify the current path in each console — but the principle is stable: a key with a hard cap has a bounded blast radius.

One key per tool, scoped as narrowly as the provider allows. When the next vendor breach lands, you rotate one key and audit one integration instead of untangling which of five tools shared the leaked credential.

And if your threat model has no room for cloud-held keys at all, the zero-egress route is a local model: OpenCode against a local Ollama backend or Cline with a local-first privacy setup involves no API key that can be stolen, because there is no API key. Hardware requirements and what quality you give up are covered in our cloud-vs-local privacy analysis and in runaihome.com’s local-inference hardware guides at runaihome.com.

Should you stop using OpenCode?

No — and the architecture is the reason. The thing that got breached is the optional hosted layer, not the open-source agent we reviewed. Run the CLI with providers configured locally and this incident never had a path to you. OpenCode’s disclosure speed was better than most of the vendors in this series.

What you should stop doing is linking external provider keys into the Console — or any vendor console — when a local config achieves the same thing. Zen’s own billing is a different trade: that’s OpenCode’s service with OpenCode’s keys, and a breach there is their liability, not your Anthropic bill.

FAQ

I got the October 17 email. Is rotating my keys enough? Rotate at the provider (not just in OpenCode), check October 16–17 usage on every linked provider, and request refunds for anything unauthorized — OpenAI is refunding affected customers, and OpenCode says broader refunds are underway. Then set hard spend caps on the replacement keys.

I never used the Console, just the CLI. Am I exposed? No. Locally configured keys never reach OpenCode’s servers, which both OpenCode and the independent coverage confirm. The breach was confined to the Console platform.

Were Zen gateway credentials stolen too? OpenCode’s statement scopes the exposure to external provider keys linked by a subset of Console users. It hasn’t reported Zen-side payment or account data as affected. Watch their disclosures — the investigation was still described as ongoing at publication.

Is this related to OpenCode’s RCE CVEs from earlier in 2026? Different class entirely. The January and September issues were vulnerabilities in the local OpenCode server on your machine (patch guide here). This was a breach of OpenCode’s own cloud infrastructure. Patching your CLI does nothing for this one; rotating keys does nothing for those. Do both.

How do I know a “distillation attack” won’t recur against my new keys? You don’t — but a new key that exists only in your local config and carries a hard spend cap removes both the exposure path and the unbounded cost. That combination is the durable fix.

Sources

Last updated October 25, 2026. Incident details verified Oct 25, 2026 via cross-referenced reporting from the outlets above (several primary domains are unreachable from our publishing environment; facts were confirmed across 4+ independent write-ups plus OpenCode’s own statements). Provider console interfaces change frequently — verify spend-limit and key-management paths in your own account.

Was this article helpful?

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.