OpenCode said on October 17, 2026, that someone had gained unauthorized access to a legacy system tied to its hosted Console service the night before, October 16. Provider API keys saved in some Console workspaces may have been exposed, according to the company’s notification.

What OpenCode disclosed

English-language explainer by Code Bear about the OpenCode Console incident

OpenCode reported that 1.4% of Console users were affected and said the affected group had external providers linked. The company said it emailed those users and that people who did not receive a notice were not impacted. The 1.4% figure is OpenCode’s reported share of Console users. OpenCode’s October 17 statement

The notification email, quoted by Infosecurity Magazine, said third-party provider keys saved in workspaces may have been exposed, naming OpenAI and Anthropic as examples. OpenCode described the incident as related to a large-scale distillation attack and said it was working with Anthropic, OpenAI, and Google.

Console keys and local credentials follow different paths

The disclosed keys were saved in OpenCode Console workspaces. Dax Raad clarified that the incident concerned Console, not the OpenCode client. OpenCode’s documentation says provider credentials entered through the client’s /connect command are stored locally at ~/.local/share/opencode/auth.json. Dax Raad’s statement · OpenCode provider documentation

That distinction gives you a practical place to start: identify whether the provider key was saved in a Console workspace or entered through the local client. The documented /connect path is separate from the workspace storage named in OpenCode’s notice.

What providers said about their response

OpenCode said it was working with Anthropic, OpenAI, and Google. Separately, Lydia Hallie said on October 17 that Anthropic had revoked Claude API keys it believed were affected. Her statement described Anthropic’s action; it did not quantify the keys involved. Hallie’s statement, included in the X discussion

Review and rotate potentially exposed keys

Safeguard recommends listing provider keys ever saved in Console workspaces, including keys added by other workspace administrators, and reviewing provider usage and billing from October 16 onward. If a key may be affected, its guidance is to create and deploy a replacement before revoking the old one. Then update every application and environment that used the key, and test that the revoked credential fails authentication. Safeguard’s incident-response guidance

A spending alert is not a substitute for revocation: Safeguard says an alert notifies the account owner but does not revoke a key. Spending limits and revocation are separate controls.