Used OpenCode? Should You Rotate Your API Key After the Console Breach?

If you only installed the open-source OpenCode command-line tool, the available evidence does not show that every local installation was breached. The incident disclosed by OpenCode concerns its Console service. The company says about 1.4% of Console users were affected and that some externally connected AI-provider API keys may have been exposed. It also says affected users were notified by email.

That distinction is the first thing to get right. “OpenCode was hacked” is too broad to be useful. A developer who ran only the local CLI has a different risk profile from someone who created a Console account and saved a provider key there. But anyone who connected a billable key should still treat uncertainty as a reason to check, not as proof that nothing happened. The difference matters because the two surfaces store secrets in different places: the CLI keeps credentials in local environment variables or configuration files on your machine, while Console stores them server-side so they can be synchronized across sessions and devices. A breach of the latter does not automatically touch the former, but the two are easy to conflate when a single product name covers both.

What is confirmed—and what is not

The official notice confirms a breach involving the Console service, a limited share of its users, and potential exposure of third-party provider credentials. OpenCode connected the event to a large-scale model-distillation attack and said it contacted affected accounts.

The missing detail matters just as much. There is not yet a full public postmortem explaining the initial entry point, how an attack associated with model extraction reached stored credentials, how long access persisted, or which controls failed. Without that timeline, outsiders cannot independently determine the complete blast radius. That gap is not unusual in early disclosure, but it changes how you should read the 1.4% figure: it describes the population the company believes was affected at the time of notification, not a ceiling that later investigation cannot revise upward.

An email from the company is useful evidence that an account was affected. The absence of an email is not an immutable security guarantee. Messages can be delayed, filtered, sent to an old address, or based on an investigation that later expands. The practical response should therefore depend on whether a key was stored and what that key could spend. A key that only reaches a free tier carries little downside; a key tied to a production billing account with no cap carries much more.

Who should act now

The highest-priority group is anyone who used OpenCode Console and connected an external API key for a model provider. That includes keys with broad access, no spending cap, long expiration, or permission to use expensive models. Shared team keys deserve special attention because one leaked credential can obscure which person or service generated the usage. When several engineers, a CI job, and a staging environment all authenticate with the same key, the provider dashboard shows aggregate traffic with no way to attribute a stray request to its source.

Users of only the local open-source agent should verify that they never signed into Console or synchronized credentials before assuming they are outside the incident. Local environment variables and configuration files are not automatically equivalent to a cloud-stored Console key, but agents can still leak secrets through logs, prompts, extensions, or shell history. This incident is a prompt to audit the whole path rather than panic about every installation. A local key that never left your machine was not exposed by a Console breach, but it may still be sitting in a shell history file, a committed .env, or a debug log that a coding agent printed during a failed request.

The five-step response

First, identify every provider key that was ever connected. Check the Console account, password manager, deployment configuration, and provider dashboard. Record the key identifier and services that depend on it before revoking anything, so production systems can be updated safely. The inventory step is the one people skip, and it is the one that prevents an outage: revoking a key you forgot was powering a nightly job turns a security cleanup into an incident of its own.

Second, revoke and replace exposed candidates. Rotation means creating a new credential, updating the legitimate service, testing it, and then invalidating the old key. If the old key can be revoked immediately without breaking critical work, do that first. Do not merely rename it or change an OpenCode password; the provider credential is a separate secret. Changing your Console password does not invalidate a key that was already copied out, because the key authenticates directly to the provider and does not consult OpenCode on each request.

Third, audit usage and billing. Review requests, model names, regions, timestamps, and cost spikes from the earliest plausible incident window through today. A small number of high-priced calls can matter more than a large count of cheap ones. Save evidence before dashboards roll older data out of view. Provider consoles typically retain detailed usage for a limited window, so export the relevant rows while they are still queryable; a screenshot of a cost graph is weaker evidence than a CSV of individual requests.

Fourth, report suspicious charges to the provider. Include the key identifier, timestamps, affected projects, and actions already taken. Do not publish the full key in a ticket, screenshot, or social post. If the account uses prepaid credit, check the remaining balance; if it uses postpaid billing, inspect pending as well as finalized usage. Pending usage often reflects the most recent hours, which is exactly the window an attacker would occupy before detection.

Fifth, reduce the next blast radius. Set project-level budgets and alerts, issue separate credentials per service, choose the narrowest available permissions, and remove unused keys. A single master key reused across a laptop, coding agent, server, and CI system converts one incident into four investigations. The goal is not to eliminate the possibility of leakage but to make any single leak small, attributable, and cheap to contain.

Why a spending limit is a security control

Developers often treat token budgets as finance settings. For externally billable AI keys, they are also containment. A leaked credential with a low project cap may still expose prompts or data, but it cannot silently generate an unlimited invoice. Usage alerts shorten detection time, while per-service keys make it possible to disable one integration without stopping everything. The mechanism is simple: a hard cap converts an open-ended liability into a bounded one, and a bounded loss is something you can absorb while you investigate rather than something that forces an immediate all-hands response.

Rate limits alone are not enough. An attacker can operate slowly, use an expensive model, or distribute calls across time. Combine a hard budget where the provider supports it, near-real-time alerts, separate projects, and automatic key expiration for temporary experiments. A rate limit constrains how fast requests arrive; a budget constrains how much they ultimately cost, and the two fail in different ways. Slow, steady traffic from an expensive model can stay under every rate limit while quietly accumulating charges.

The architecture lesson for coding agents

An AI coding tool sits close to source code, terminals, repositories, cloud credentials, and paid model APIs. Convenience encourages users to connect everything to one account, but that makes the control plane unusually valuable. The right question is not only whether the model is safe; it is where secrets are stored, who can read them, and how quickly they can be invalidated. A coding agent that can read your repository and call a paid model is, in effect, a trusted deputy holding two kinds of access at once, and a compromise of either path deserves the same scrutiny.

Teams should maintain an inventory of every AI tool that holds a credential. Prefer short-lived tokens or brokered access when available. Keep production secrets out of interactive agents, restrict network egress, and ensure logs redact authorization headers. If a product cannot explain its secret-storage and deletion model, do not give it a high-value unrestricted key. The test is concrete: ask where the key is stored, who can read it, how it is encrypted at rest, and what happens to it when you delete your account. A vendor that cannot answer those four questions in plain language is asking you to extend trust it has not yet earned.

Verdict

The confirmed incident does not justify telling every OpenCode CLI user that their key was stolen. It does justify immediate action from Console users who connected external provider credentials. Rotate plausible keys, inspect usage, contain spend, and wait for a detailed postmortem before accepting a confident root-cause story.

The durable lesson is broader than OpenCode: an API key entered into an AI tool is not merely a setup field. It is a financial and operational credential. Treat it with the same inventory, isolation, and rotation discipline as a production password.