OpenCode Console breach: what to do if your provider API keys were stored there

You wake up to an email that says your OpenAI or Anthropic key "may have been exposed", and the usage page already shows a few hundred dollars you did not spend. That is what some OpenCode users described on Saturday. If you use OpenCode, or any tool that keeps your model keys for you, here is what happened, what to do with your keys today, and how to make the next leak cost less.

What OpenCode said

OpenCode is an open-source coding agent. The team behind it also runs OpenCode Console, a hosted service with team workspaces and a model gateway. On October 17 the @opencode account on X posted, in its edited version as quoted by On The Wire:

"We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users

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"

The post says the incident is ongoing and that OpenCode is working with Anthropic, OpenAI and Google. The email that affected users received, as shown in a screenshot reported by The Latent, says someone reached "a legacy system that we were in the process of decommissioning" and that third party provider keys "saved in your workspace may have been exposed." It asks users to revoke and replace those keys at each provider and to review recent usage.

Some users posted their losses before OpenCode said anything. One person reported $281 on an OpenAI key and $168 on an Anthropic key, starting at 2 a.m. Eastern time. Others reported larger amounts. The Latent says it could not verify those reports. According to DigIntoAI's account of replies on X by Dax Raad, who builds OpenCode, refunds were underway. OpenCode has not said how the attacker got in, how long access lasted, or how the "distillation attack" relates to the keys.

Was your key in the Console?

The breach was in the hosted Console, which is a different place from the OpenCode CLI on your laptop.

The Console providers docs say that when a workspace admin connects Anthropic, OpenAI or another provider, "Console stores the credential and serves each provider through its gateway, so members use the models without ever seeing the provider key." Those stored keys are the ones the email talks about.

The CLI providers docs describe the other path. Keys you add with /connect are stored in ~/.local/share/opencode/auth.json on your own machine. Dax Raad replied on X, as DigIntoAI quotes him: "note this is the OpenCode Console, not OpenCode itself, those keys never come to us."

The CLI can also use a provider that lives in the Console, as Noma Security points out, so using only the terminal does not settle it. Check two things:

• Open your Console workspace, if you have one, and look at Providers. Anything listed there had its key stored on OpenCode's side.
• Look at ~/.local/share/opencode/auth.json. Keys in that file stayed on your machine, unless you also pasted the same key into the Console.

If you are a workspace owner on a team, your members may have used those keys without ever seeing them. The owner is the one who has to rotate them.

What to do with your keys today

Revoking a key costs you five minutes and a config update. If you are not sure where a key has been, replace it.

Go to each provider's dashboard by typing its address yourself. On The Wire quotes the security firm Cyera's advice to avoid "links in a breach email, since notices like these are common phishing bait."

For Anthropic, the Claude help center says to open the workspace, go to the API Keys tab, click the menu next to a key and choose "Disable API Key" or "Delete API Key". Deleting is permanent.

For OpenAI, the projects help page says keys are managed per project, on the project's API Keys page.

Then look at usage for the last few days, per key if the dashboard shows it. Look closely at charges from hours when you were asleep.

Update every tool that used the old key. A coding agent that suddenly answers with an authentication error later today is often just a key you forgot.

Make the next leak cost less

Revoking fixes this leak. Limits make the next one smaller, whoever it comes from.

OpenAI's spend limits guide separates two controls. A spend alert sends a notification and lets traffic continue. A hard spend limit, set per organization or per project with "Enforce a hard limit", makes requests fail with a 429 once the month's spend reaches it. The guide warns that "enforcement is not instantaneous", so spend can go slightly over.

Anthropic's workspaces docs put spend limits on the workspace: open the workspace in the Claude Console and click Spend limits to cap monthly spending and set alerts. The help center adds that a workspace limit can only be lower than the organization's.

Three habits make those limits work:

• Give each tool its own key, in its own OpenAI project or Anthropic workspace. When one leaks, you revoke one key and nothing else breaks.
• Give that project or workspace a hard cap close to what the tool really spends in a month.
• Set an expiry. OpenAI's key safety page says project keys can be created with an expiration date, and that admins can enforce a maximum key lifetime.

A gateway that holds keys for a whole team has a real benefit: members never see the key, so they cannot paste it somewhere it does not belong. The cost is that one service holds many valuable keys at once. If you use one, the per-key caps above matter even more.

Where Sessionboxer keeps an agent's login

We make Sessionboxer, so this part is about our own product, including what it does not do.

Sessionboxer runs on your machine or your own server, and each agent session gets its own Docker container (one box per session). It does not run a hosted gateway that holds your model keys. You connect your agent with its own login. For OpenCode that means pasting or importing the auth.json that opencode auth login writes, or an OpenCode Zen key. Claude Code uses the token from claude setup-token, and Codex uses your ~/.codex/auth.json.

As the your repositories, your subscription page says, tokens are handed only to the containers of sessions that use that agent, live on tmpfs in the box, and are never stored in snapshots. On the machine that runs Sessionboxer they sit in ~/.sessionboxer/config.json, readable only by you, as listed in where things live.

Here is what that does not cover:

• Sessionboxer cannot protect config.json if someone gets into your machine. It is a file on your disk, like auth.json is.
• The agent inside the box can read its own login file. A prompt injection that convinces it to send that file somewhere is still possible. Our post on keeping secrets away from a coding agent covers how to limit what else the box can see.
• If you paste an API key, it is still an API key with the bill attached. Sessionboxer does not set spend limits for you. Do that at the provider.
• It does not share one key with a team without sharing the key. If you want members to use models without seeing the key, a gateway does that and Sessionboxer does not.