OpenCode is an open-source AI coding agent, and its hosted Console can hold model provider API keys on a team's behalf. In its incident notice on 2026-10-17 UTC, OpenCode said a security incident affected 1.4% of Console users — specifically those who had linked external providers — and that it emailed everyone in that group. It also said anyone who received no email was not affected. Don't read that as "everyone running OpenCode leaked a key."
If your Console held a third-party provider key, revoking it in the provider's own console is the only step that stops the bleeding. Deleting the connection in OpenCode, uninstalling the client, or lowering a budget won't touch a copy that has already left.
Revoke first or build the replacement first? That depends on whether you have confirmed unfamiliar usage. If you haven't, the question becomes whether you can tolerate a short outage.
If all you have is an expired Console key or a restricted workspace, that is a different problem: the error alone doesn't prove a provider key leaked. When you can't tell which key is involved, lack revoke permissions, or a fresh key still shows unfamiliar calls, hold off restoring automated tasks and take it to a workspace admin.
First, separate a provider key leak from a broken Console connection
Start with where the key lived and who issued it, not with the error code. The notice covers keys that were stored in Console and issued by an external provider. A failed Go key and a restricted workspace are two other problems; OpenCode hasn't said how they relate to this incident, and they need different handling.
OpenCode co-founder Dax Raad draws a clear line between Console and OpenCode itself: Console is the thing that was affected. Connecting a provider locally doesn't mean you ever stored that key in a hosted workspace.
| What you can confirm | What to do first | The usual misread |
|---|---|---|
| The key already shows unfamiliar usage, email or no email | Revoke it in the provider console, note the time, then work through billing | Deleting the Console connection leaves the provider key fully usable |
| You got a risk notice but see no unfamiliar usage yet | If downtime is expensive, build the replacement, verify it, then delete the old key; if downtime is cheap, revoke now | The notice itself is the signal to rotate — waiting until you see abuse is too late |
| The key was already dead before you acted, and the provider shows it disabled or deleted | Check its status in the provider console, then follow that provider's guidance on whether to leave it or delete it too; audit usage as well | A key can be revoked in bulk without anyone touching it — check provider-side status |
| You stored a provider key in Console but got no email | Check the workspace, the notification address, and provider usage; if exposure can't be ruled out, treat it as suspected | Having used Console doesn't mean you were in the affected set — look for unfamiliar calls |
| You only connect providers locally and never uploaded that key to Console | Verify the actual connection path; investigate separately if you see unrelated anomalies | A key that never reached Console isn't in this incident's scope |
You only hold an OpenCode Go key ($10/month model subscription) or a Console-issued key, and you get api_key_expired |
Check Console account status and tell support the error and when it started | This is a key Console issued itself, unrelated to any external provider |
The workspace shows Workspace access restricted |
Have the owner contact support and save the error and timestamp | A restriction may just be risk control — see what support says first |
Some keys may already have been disabled by the providers before you got to them. TechCrunch reported on 2026-10-19 that Anthropic and Google blocked the keys they believed were exposed, and that OpenAI said it worked with OpenCode to restore access and refund credits consumed in the attack.
Those are vendor actions as relayed by the press. What actually happened to your account is still whatever the provider console and support reply say.
Both the failed Go keys and the restricted workspaces have first-hand user reports. The author of GitHub #56833 says they had no external providers linked but their Go key stopped working; #56703 records a restricted workspace where the reporter says they never got the breach email. These are individual reports from 2026-10-18 onward, sitting alongside the notice's "no email means not affected," and OpenCode hasn't reconciled the two, and individual cases don't tell you the size of the affected group.
Support replies in that repo ask people to send account issues to [email protected]. Don't paste account details or payment information into a public issue.
Revoke or replace the old key, then clean up the Console connection
Check the provider, the organization or project, the key name, and the visible trailing characters before you act, so you don't delete a production credential. If that key is also shared with production services, loop in the service owner right away to disable and replace it. Once unfamiliar usage is confirmed, don't keep it live just to make the switch smoother.
If you can see the charges climbing and can't find the revoke control yet, drop the provider-side spend limit to roughly current usage first. A Console budget won't restrain calls that bypass the gateway; a provider-side cap will.
OpenAI and Anthropic will actually cut traffic: OpenAI's hard spend limit stops affected traffic once tracked spend hits the cap, and Anthropic lists spend limits as a safeguard against usage from leaked keys.
Gemini's equivalent is a Cloud billing alert, which only notifies and never stops a call (key documentation). It won't slow down an in-progress drain, so revoke directly.
A cap is a temporary tourniquet. It doesn't replace revocation.
The table below covers the three providers most Console users link, as documented on 2026-10-20. The same catalog also supports xAI, DeepSeek, Mistral, Groq, OpenRouter, plus Azure, AWS Bedrock, Google Vertex AI, Cloudflare AI Gateway, Databricks and custom providers (Console Providers documentation).
Those are revoked from each provider's own API keys page too. The buttons sit in different places; you're looking for the same thing.
| Key issuer | Official path and action | What to record afterward |
|---|---|---|
| OpenAI | Following the official safety guidance, go to Security settings in the Platform and revoke the exposed key, then create a replacement | Project, old key identifier, revocation time |
| Anthropic | Following the official key safety guidance, sign in and open platform.claude.com/settings/keys (the API keys page), open the menu beside that key, and choose Delete API key |
Workspace, deletion time; then check Logs and Usage |
| Google Gemini API | Following the Gemini key documentation, confirm the linked Google Cloud project and create a replacement in AI Studio's API Keys page; once it works, disable or delete the old key under APIs & Services > Credentials in the Cloud console |
Project and key ID, so you don't confuse same-named keys across projects |
Deleting a key in Google Cloud only marks it DELETED; it can be brought back with UndeleteKey for 30 days (Cloud key documentation).
The three vendors document different orders. Google's leak response checklist says create the new key, update the application, and only then disable or delete the old one, so the app doesn't go down. OpenAI's safety guidance and Anthropic's guidance both say revoke promptly and replace, with no step for verifying the replacement first.
Google's order assumes you'd rather not go down. If you're being drained right now and can survive a short outage, revoking first is the better trade — but that call belongs to the workspace owner.
Without permissions, ask an admin to revoke and report back the status and time. Never send a full key to a colleague, to support, or into an AI chat; the key ID or last few characters is enough.
Only owners and admins can open the Providers page in Console; regular members just see the enabled models after running /connect (Providers documentation). Not finding the entry point is expected — it isn't a misconfiguration.
Once the provider side is done, come back and deal with the old connection in Console. The Console Providers documentation separates Disable from Remove: the first hides the provider and its models but keeps the settings, the second deletes the connection and the models with it.
Both actions govern the Console side. Whether the old key still works is a question for the provider only.
Audit against provider usage, and treat Console records as a cross-check
A copied key can bypass Console entirely. So a Console with no matching request doesn't mean nobody is spending your money; do the audit on the provider side, and don't count Console balances or budgets as a stop-loss.
Money is only part of it. Gemini's key documentation is explicit: once a key leaks, someone else can burn through your project's quota, run up unexpected charges, and reach private resources. Exhaust the quota and your own service goes down first.
Since 2026-05-28, keys created in AI Studio default to auth keys bound to a service account, limited to the Gemini API by default — but what they can reach still depends on that service account's permissions. Check all three when you audit usage.
Per the Console documentation, calls through a provider you brought yourself are billed by that provider; Console just records the cost at the prices you configured. The limits described in the budgets documentation constrain requests that go through Console, and can't touch calls that bypass the gateway and hit the provider directly.
Work through the evidence in this order; you don't need a total loss figure first:
- Keep the notification email and note the risk window it gives. Use UTC throughout, or label the timezone on every entry. If the email gives no start point, work backward from the last usage you can confirm as normal — the official notice went out 2026-10-17 UTC and TechCrunch published 2026-10-19, and neither date is your account's exposure start.
- Check usage for the relevant project or workspace in each provider console, comparing models, call times, request volume and cost. If the console can't break usage down by key, note that limitation and ask an admin or the provider for a closer look.
- Compare against team task logs, scheduled jobs, and any other application sharing that key, and list the calls you can't explain. Mark them "unconfirmed" rather than counting every spike as attack cost.
- Save usage exports or redacted screenshots, and file the billing or account issue with the provider and with OpenCode separately. Whether anything is refunded, and which charges it covers, depends on the reply you get for that specific account.
Copy the sample record template below if it helps; don't fill in full keys or card details:
Provider / project / workspace:
Old key ID or trailing characters:
Risk window from the notice, with timezone:
Time the old key was revoked or disabled (UTC):
Unexplained call times, models and costs:
Whether quota or rate limits look abnormal, whether private resources were accessed:
Legitimate jobs ruled out:
Where the usage export or redacted screenshots live:
Support ticket number / owner / next review date:
Before you reconnect, decide who holds the new key
Once the old key is disabled or revoked you can restore approved business paths, but a working new key doesn't mean the Console incident is over. OpenCode's incident post from 2026-10-17 UTC says the incident is still being handled, while the status page only tracks whether services are reachable — it showed All systems operational on 2026-10-20. A green status page doesn't mean the notice has been closed out.
Whether to keep hosting external credentials in Console is a call for the workspace owner, based on later updates and what the team requires.
If the team doesn't approve continued hosting, leave the corresponding Console connection disabled. If it approves connecting providers directly, follow the official configuration for your OpenCode version; don't upload a key meant only for local use back to the online path that hasn't been cleared. Local access doesn't reset the risk to zero either — local permissions and credentials still need managing.
If the team approves restoring Console, an owner or admin can swap the credentials on the connection following the official Providers flow, after which members run /connect to pick the workspace and /models to check which models work.
Before swapping, confirm which workspace and which provider you're in, so you don't reconnect a configuration still pointing at the old key.
Verify authorized calls with a small task that carries no sensitive data before restoring scheduled or batch jobs. Check three things: who owns the new key, whether the provider shows new usage, and whether the logs still contain authentication errors from the old credential. If unfamiliar calls continue, stop and keep investigating; if the only problem is a restricted workspace, hand it to account support rather than creating keys until something works.
To rethink how subscriptions, coding plans and API billing should be split, see the AI coding pricing comparison. Changing plans is one thing; the old credential still has to be revoked.
When this round of handling is done
The round is done when the old credential is revoked or disabled, every affected application has been updated, and someone owns the abnormal usage. Anything still open on refunds or account recovery keeps its ticket.
- Every provider and project involved is listed, and each old key's status and disable time can be checked
- Every application that used the key has been updated, and none were "fixed" by restoring the leaked key
- Usage has been reconciled against provider records, and unexplained costs and data-visibility limits are written down
- Quota, rate limits and private-resource access were checked separately, not just the bill
- Where the new credential lives, who uses it, and how to recover it have been confirmed by the owner
- Any workspace still restricted, unfamiliar call still appearing, or charge still open has its own ticket and owner