OpenCode Console breach: which API keys were exposed, and how to rotate them without an outage

On 17 October 2026 OpenCode said an attacker had reached "a legacy system that we were in the process of decommissioning", and that OpenAI, Anthropic and Google API keys saved in some OpenCode Console workspaces "may have been exposed" (Cyber Security News, OfficeChai). The company put the blast radius at about 1.4% of Console users — those who had linked their own provider keys — and called it part of "a large scale distillation attack" (OpenCode on X). Within a day, users were posting provider bills for traffic they had not sent.

This article separates what OpenCode has confirmed from what is still rumour, shows which of your machines and pipelines are actually in scope, and gives an order for rotating keys that does not take production down halfway through. It is for anyone who has pasted a provider key into OpenCode, or into any hosted tool that offers "bring your own key".

What happened in the OpenCode Console breach?

An unauthorised party got into an old OpenCode Console system and could read provider keys that users had stored there. OpenCode's public post said: "We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users", and added that "if you did not get an email you were not impacted" (OfficeChai, quoting OpenCode's posts on X).

OpenCode is built by Anomaly Innovations, the company formerly known as SST (Startup Fortune). The Console sits beside the open-source terminal agent: it is a hosted service where a workspace can hold model credentials, so a team can point OpenCode at one place instead of spreading keys across laptops. That convenience is exactly what made it a target — one database, many people's keys.

OpenCode said it was working with Anthropic, OpenAI and Google to remediate, had found no evidence "to date" that other data leaked, and could not share more while the incident was ongoing (Startup Fortune, Cyber Security News). Users reported their saved keys disappearing and workspaces being locked, which is consistent with OpenCode revoking access while it investigated (OrcaRouter).

What is confirmed, and what is still a rumour

Treat the official notice as the floor and everything else as unverified until a post-mortem appears. The useful split today:

• Confirmed by OpenCode: a legacy Console system was accessed; provider keys saved in affected workspaces may have been exposed; roughly 1.4% of Console users; affected users were emailed (Cyber Security News).
• Not disclosed: how the attacker got in, how long they were inside, how many keys were taken, and whether the stolen keys were the ones used for the "distillation" traffic (Cyber Security News).
• User-reported, not confirmed: individual losses quoted in the press range from a few hundred dollars to about $1,700 per person (OrcaRouter); one user says Google suspended a Cloud project and another that OpenAI closed an account (Startup Fortune).
• Disputed: the "distillation" label. OpenCode has published no evidence for the motive, and commenters on Hacker News point out that reselling stolen tokens would look much the same from the outside.

How a hosted key store turns one breach into many bills

A bring-your-own-key service holds credentials that are billed to someone else. When its store leaks, the attacker does not need to break into each provider: every key works as issued, and the cost lands on the key's owner until the key is revoked.

Two things make this worse than a leaked password. Provider keys are bearer tokens, so there is no second factor between a stolen key and a billable request. And keys tend to be broad: OpenAI's own service-account keys default to read and write on all of a project's resources (OpenAI Help). The fix is the same for both: short-lived, narrowly scoped keys with a hard spending ceiling, so the next leak is cheap.

Are you affected? Console users, CLI users and everyone else

You are in scope if you saved an OpenAI, Anthropic or Google key in an OpenCode Console workspace. OpenCode says affected users were emailed; if you got the email, assume the keys are compromised. If you did not, OpenCode says you were not affected — but one user on GitHub reports restricted workspace access without any email, so check your provider dashboards anyway (OrcaRouter).

The local CLI is a different store. OpenCode's documentation says saved API keys and OAuth tokens live in the local server's SQLite database, usually ~/.local/share/opencode/opencode.db, and that opencode debug paths db prints the exact path (OpenCode docs). Nothing published so far says that file was touched; the consensus on Hacker News is that the CLI was not involved, but that is commenters, not OpenCode.

Do not confuse this with CVE-2026-22812, an unauthenticated local HTTP server in OpenCode versions before 1.0.216 that let any local process or website run shell commands as the user (NVD). Upgrading the CLI fixes that bug. It does nothing for keys that were sitting in a hosted workspace.

$ opencode debug paths db$ opencode auth list

How to rotate OpenAI, Anthropic and Google keys without breaking production

Create the replacement first, cap it, deploy it, prove it works, then delete the old key. Deleting first is the instinct, and it is how a security fix becomes an outage.

1. 1

   Inventory every place the key lives

   A key pasted into the Console was usually copied from somewhere: a shell profile, a .env, a CI secret, a teammate's machine. Find all of them before you rotate, or the old key keeps working somewhere you forgot. This search prints only file names, so the keys themselves stay out of your scrollback:

   grep -rIlE 'sk-ant-|sk-proj-|AIza[0-9A-Za-z_-]{30,}' \  ~/.zshrc ~/.bashrc ~/.config ~/code \  --exclude-dir=node_modules --exclude-dir=.git 2>/dev/null # Keys that were committed and later removed are still in historygit log --all -p -S'sk-ant-' --oneline | head

   The prefixes are a heuristic, not a guarantee — the author of the DEV Community checklist this is adapted from could not confirm them all against provider docs, so a clean result does not prove absence.

2. 2

   Create a new key and cap its spend before it goes live

   Name it with today's date and scope it to one project. Then set the ceiling. On OpenAI, a project's monthly budget is a soft threshold by default; you have to enforce it as a hard limit for requests to fail when it is reached (OpenAI Help). On Google, set a Monthly spend cap for the project on AI Studio's Spend page — Google calls the feature experimental and warns usage can overshoot the cap before billing data catches up (Gemini API billing). On Anthropic, set usage and spend limits in the account settings, or for prepaid organisations be careful with auto-reload, which will happily top up a leaked key (Claude Help Centre).

3. 3

   Deploy the new key everywhere you found the old one

   Update CI secrets, hosting platforms and local environments, then restart long-running processes so they pick up the new value. For OpenCode itself, prefer an environment connection over a saved account, so the key never sits in a database you did not create:

   # Remove the saved Anthropic account from the local OpenCode storeopencode auth logout anthropic work # Give the shared background server the key from the environment insteadopencode service set env ANTHROPIC_API_KEY "$ANTHROPIC_API_KEY" # Update the GitHub Actions secret (prompts for the value)gh secret set ANTHROPIC_API_KEY

   Per the OpenCode docs, setting a service variable stops the running service, which restarts with the new value on the next command; and a saved account wins over an environment connection for the same provider, which is why the logout comes first.

4. 4

   Prove the new key works, then delete the old one

   Send one real request through each deployed path. Only then revoke the old key in the provider's dashboard — in Anthropic's Console, the key's menu has Delete API Key (Claude Help Centre). Go to the dashboards directly, not through links in any breach email.

5. 5

   Watch usage for the next two days

   Compare request counts, cost and model mix with your normal day, back to 17 October. Google's usage view is at AI Studio's Usage page (Gemini API billing); OpenAI and Anthropic show usage per project and per key in their consoles. Anything you did not send is a reason to contact the provider's support, not just to rotate again.

Provider spend controls compared

A spending cap is what turns a leaked key from an open-ended bill into a bounded one. The three providers in this breach do not behave the same way when the cap is reached:

Should you keep provider keys in a hosted coding tool at all?

Only if the tool is worth one more place your keys can leak from, and only with a capped, single-purpose key. Commenters on Hacker News suggested running a self-hosted gateway such as LiteLLM instead, so a vendor never holds the raw key; that moves the risk to infrastructure you control rather than removing it.

It is also worth remembering what OpenCode itself says about the agent: its documentation, as quoted by Startup Fortune, states that OpenCode "does not sandbox the agent" and that permission prompts are a UX feature rather than a security boundary, recommending Docker or a VM for isolation. A coding agent can read the .env in your project. Give it keys you would be comfortable seeing in a log.

Sources and further reading

• OpenCode's statement on X, 17 October 2026 (quoted in the reports below)
• Cyber Security News: OpenCode Security Breach Exposes Third-Party API Keys
• OfficeChai: OpenCode discloses security breach
• Startup Fortune: OpenCode breach exposes stored OpenAI and Anthropic keys
• OrcaRouter: OpenCode Console breach exposed users' AI provider API keys
• Hacker News discussion
• OpenCode docs: providers and credentials
• Claude Help Centre: API key best practices
• OpenAI Help: managing projects, keys and budgets
• Gemini API billing and spend caps
• NVD: CVE-2026-22812
• DEV Community: OpenCode Console breach rotation checklist