OpenCode Told 1.4% of Console Users to Revoke Their OpenAI and Anthropic Keys

• Book: LLM Observability Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

The subject line was "Action Required: Potential provider key breach." On October 17, some OpenCode Console users opened an email that said: "We identified unauthorized access to a legacy system that we were in the process of decommissioning." Security researcher Matt Johansen posted a screenshot of it to X at 15:30 UTC with the line "Confirmed. OpenCode hacked. Keys stolen."

The next sentence in that email is the one that matters if you use OpenCode Console: "Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed."

At 18:08 UTC, OpenCode confirmed it on X: "We had a security breach last night related to a large scale distillation attack." The company put the impact at 1.4% of OpenCode Console users.

What OpenCode has said so far

OpenCode's own statements so far, from its X post and the customer email:

• The breach hit "a legacy system" that OpenCode was already decommissioning.
• Third-party provider keys saved in a Console workspace "may have been exposed." The email names OpenAI and Anthropic as examples.
• About 1.4% of Console users were affected. OpenCode says it emailed all of them, that anyone without an email was not affected, and that the affected group was users who had external providers linked.
• OpenCode says it is working with Anthropic, OpenAI and Google to remediate.
• "The incident is ongoing so we cannot share more details at this point."

The email asks affected users to "revoke and replace those keys through the relevant provider's dashboard, update any applications using them, and review recent usage for unexpected activity."

OpenCode hasn't said how many accounts 1.4% is, how the attacker got in, how long the access lasted, or whether every key was actually taken. OfficeChai notes that no technical details have been released, and Runtime Wire points out that the 1.4% figure "does not by itself measure either exposure or loss." Crypto Briefing reports that some affected users saw bills in the hundreds of dollars, and that it is not yet clear how those charges will be handled. Those are user reports, not figures from OpenCode.

Dax Raad, an OpenCode co-founder, posted at 18:41 UTC that his "personal accounts are being attacked now too."

What "distillation attack" means here

OpenCode chose the label. Anthropic, in a February 23 post, describes distillation as training "a less capable model on the outputs of a stronger one." On October 12, Anthropic wrote that distillers have used "proxy networks that control hundreds of thousands of fraudulent accounts."

My reading, and OpenCode hasn't confirmed it: a stolen provider key is free model output for whoever holds it. Someone pulling large volumes of frontier-model answers to train their own model has every reason to want keys that bill to somebody else. That would explain both the label and the reported charges. Treat it as a hypothesis until OpenCode publishes its follow-up.

The trade-off of saving keys in a gateway

OpenCode's Console providers docs say a workspace can connect provider accounts "you already pay for, such as Anthropic, OpenAI, or AWS Bedrock," and that Console stores the credential so members can "use the models without ever seeing the provider key."

That is how team gateways work, and it saves you from handing raw keys to every teammate. The catch is that the gateway now holds a live key that bills your card, and every system that ever touched it is part of your attack surface, including the one being retired.

Note the scope. The email talks about keys "saved in your workspace." The OpenCode CLI keeps keys you add with /connect on your own machine, in ~/.local/share/opencode/auth.json, per its docs. OpenCode hasn't said anything about local keys in this incident.

If you got the email: revoke, verify, review

1. Revoke and replace each key you saved in the workspace. Anthropic keys live on the API keys page, and its support article says to revoke a possibly compromised key "immediately." OpenAI keys are on the API keys page. For Gemini, Google's key docs say to create the replacement in AI Studio first, then disable the leaked one.
2. Update every app and CI secret that used the old key, including the Console workspace itself.
3. Check that the old key is really dead. Anthropic returns 401 for a revoked key, and OpenAI returns 401 for an incorrect one:

# Prints the HTTP status. 401 means the key is dead.
curl -s -o /dev/null -w "%{http_code}\n" \
  https://api.anthropic.com/v1/models \
  -H "x-api-key: $OLD_ANTHROPIC_KEY" \
  -H "anthropic-version: 2023-06-01"

curl -s -o /dev/null -w "%{http_code}\n" \
  https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OLD_OPENAI_KEY"

1. Review usage for traffic you don't recognize, going back at least to October 16 and further if your provider's logs allow. OpenCode hasn't said how long the access lasted. Anthropic points you to its usage and logs pages. Google's docs say to check billing and usage logs after a leak.

If you didn't get the email, OpenCode says you weren't affected. If you saved keys in a workspace anyway, rotating them costs a few minutes while the investigation is still open.

Before you paste a key into the next console

This won't be the last tool that asks you to save a provider key. Three habits limit the damage when one of them leaks:

• One key per third-party service. If a key only ever lived in one gateway, you know exactly what to revoke and whose usage spike it is.
• A spending ceiling on that key. On Anthropic, you can set custom spend and rate limits per workspace, though not on the default workspace. Give the gateway's key its own workspace and a low limit.
• The narrowest scope the provider offers. Google's docs say to "Restrict to Gemini API only" so a leaked key can't call other Google APIs.

Watching usage per key is the part teams skip. The email told users to "review recent usage for unexpected activity," which only works if you know what normal looks like.

Where Hermes IDE fits

I build Hermes IDE, so weigh this with that in mind. Hermes runs OpenCode, Claude Code, Codex and other agents side by side, each in its own terminal. Each agent uses its own CLI sign-in, and Hermes never asks for your tokens, so you don't hand Hermes itself a provider key. Since 2.3.2, commands that hold a secret, such as setting an API key, are never shown as terminal suggestions.

The ⌘N New task sheet's agent picker: Claude Code and Codex installed, and OpenCode, Antigravity CLI, Gemini CLI, GitHub Copilot CLI, goose, Hermes Agent, Aider and Kiro CLI listed, plus Custom agent.

That doesn't protect a key you paste into any hosted console, OpenCode's or anyone else's. Hermes is free, source-available (BSL 1.1), and runs on macOS, Windows and Linux. It is not affiliated with OpenCode, Anthropic, OpenAI, Google or Nous Research.

Do you keep provider keys in a hosted gateway, or only on your own machines? Tell me in the comments.

If this was useful

Most of the advice in OpenCode's email comes down to one question: do you know, per key, what normal usage looks like? The LLM Observability Pocket Guide is about picking the tracing and evals tools that give you that baseline from your own traffic, so a spike on the provider's usage page stands out the day it starts. If you run several agents at once, Hermes IDE keeps each one in its own terminal with its own sign-in.