Stored* (*means someone else holds it)

OpenCode says a breach hit 1.4% of OpenCode Console users who had external AI providers linked. The useful question is not about OpenCode. It is where your own keys sit tonight.

A ring of dark keys hanging from a hook. One clay-colored key in the middle carries a small paper tag marked with an asterisk.
A key you paste is a key you share.

Every AI tool that asks for your API key is asking to hold your credit card. Most of us paste it in and forget.

What happened

On October 17, OpenCode posted on X: “We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users.”

The same post sets the scope and the notice: “We have notified them all this morning via email. If you did not get an email you were not impacted, it was a subset of users who had external providers linked.” On remediation, it says: “The incident is ongoing so we cannot share more details at this point but we are working with Anthropic, OpenAI, and Google to remediate.”

The scope is narrower than the headline. Dax Raad (@thdxr), who builds OpenCode, replied that the incident was in “the OpenCode Console, not OpenCode itself,” and that for the local app, “those keys never come to us.”

The providers moved next. Lydia Hallie, who works on Claude Code at Anthropic, posted that Anthropic has “revoked Claude API keys we believe were affected,” and added: “If you saved a key in OpenCode and want to be extra careful, please create a new one!”

On refunds, Raad wrote on October 17 that “refunds are already underway.” On October 19, Tibo Sottiaux, whose X bio reads “Codex & ChatGPT @OpenAI,” posted that OpenAI’s team “worked with OpenCode to have their users who are also OpenAI API customers back in business and any credits refunded which would have been drawn in the attack.” We did not find a matching notice on OpenAI’s help center or status page.

The asterisks

1. The official statement is short. OpenCode’s post gives a percentage, a timeframe (“last night”) and a list of partners. It gives no user count, no cause beyond “distillation attack,” and no list of what data was taken. BleepingComputer reported on October 19 that OpenCode’s email to affected users gives the earliest possible exposure of their keys as October 17, 2026, 00:30 UTC, and that “no data appears to have been exposed,” wording that sits oddly next to exposed keys. We have not seen that email ourselves.

2. Console is not the app. Per Raad, keys used with OpenCode locally “never come to us.” The exposure, as described, involves keys linked to the hosted Console.

3. Refunds are promised, not documented. The refund statements come from OpenCode’s builder and an OpenAI employee on X. Neither is a formal policy page. If your bill moved, keep your own records.

What this means if you ship

For a solo operator, a stored key is an open tab. Every console, plugin and agent that holds one is a place your bill can grow without you.

Most of us have keys in more places than we can name. Each one is fine until the place holding it is not. As described, the affected users did nothing unusual. They linked a provider to a service built to hold that link.

The lesson is not “never trust a tool.” It is to know where each key is, limit what each key can spend, and make losing one cheap.

What to do Monday

  1. List where your keys live. Check tool config files, shell environment variables and .env files, and every vendor console or dashboard where you pasted a key so it could call a model for you.
  2. Scope each key to one job. Give each tool its own key so you can revoke it alone. On OpenAI, projects can carry their own spend limit. On Anthropic, organizations can set custom spend and rate limits per workspace.
  3. Set hard spend caps. OpenAI’s docs describe a monthly hard spend limit for an organization or a project that makes requests fail once reached, and note that “recorded spend can slightly exceed the configured amount.” Anthropic lets you set your own spend limit below your tier’s cap. Add spend alerts too, so you hear about a spike before the cap does.
  4. Rotate after any incident. If a service that held your key reports a breach, create a new key, update the tools that use it, then delete the old one. Do this even if usage looks normal. Then review usage for the window the vendor names.
  5. Prefer sign-in over pasted keys. Where a tool offers an OAuth or subscription login, use it instead of a long-lived key. Raad noted that logging in through OpenCode “defaults to oauth tokens not long lived api keys.”

Store less. Cap the rest.

Sources

Next: Bookmarked* (*not tested)