OpenCode API Key Breach: Third-Party AI Credentials May Have Been Exposed

An incident involving a legacy system raises questions about credential storage, cloud-based development environments, and the security boundaries of AI coding assistants.

OpenCode users have been warned that API keys for third-party AI providers may have been exposed after unauthorized access to a legacy system that was being decommissioned. The notification, shared as a screenshot on Reddit’s r/opencode community on October 17, 2026, names credentials for services such as OpenAI and Anthropic as potentially affected and asks users to revoke and replace their keys.

A provider key can authorize requests against a user’s account, drain prepaid credits, generate billable usage, and, depending on its permissions, reach other provider resources. A leak at a development-tool vendor becomes a financial and operational problem for developers and organizations right away.

The notification establishes two things: unauthorized access to a legacy system occurred, and third-party provider keys stored in a user’s workspace may have been exposed. It does not give the number of affected accounts, how long the access lasted, how the intruder got in, or whether every credential was actually extracted. I am not going to fill those gaps with guesses, and neither should anyone else until the vendor says more. Anyone who received the warning should still act on it today. The incident also raises a wider question for AI tooling: how do you protect credentials when an application, its backend services, and several external providers all sit in the same workflow?

What happened in the OpenCode incident?

According to the screenshot, OpenCode found unauthorized access to a legacy system that was already being retired. The company warned that provider keys stored in user workspaces might have been exposed, named OpenAI and Anthropic as examples, and told recipients to do three things: revoke and replace their credentials through each provider’s dashboard, update every application that uses those keys, and check recent usage for unexpected activity.

The decommissioning detail matters. Retiring infrastructure is routine, but an old service can keep production data, authentication material, and internal service credentials long after anyone stops developing it. Unless someone finds and removes those assets, the old system stays an attractive target for as long as it is reachable.

The notification does not say how the system was compromised. Pointing at a particular vulnerability, an exposed database, stolen administrator credentials, or a named attacker would be premature. All the message supports is that an intruder reached an environment where provider credentials may have been present.

Exposure and confirmed misuse are different things. A credential can sit on a compromised system without being read, and access to a system does not prove every secret on it was taken. But once an attacker has been inside an environment that holds credentials, nobody can safely assume those credentials are still private. When the scope cannot be established with confidence, revoking is the correct response.

Two questions remain open: which users were affected, and how their keys ended up in the legacy environment. OpenCode’s usual local storage model gives a useful point of comparison, but the screenshot does not explain the workflow that put these keys on a server. The vendor needs to clarify that.

Why exposed AI API keys get expensive

How much damage a leaked key does depends on the provider, the account behind it, its permissions, and whatever usage controls are in place. In a typical integration the key is a bearer credential. A request that carries a valid key gets authorized, and the provider does not check that the caller is the person who created it.

An attacker holding a usable key can send requests through the real provider API and have the usage charged to the key’s owner. To the provider, that traffic can look like ordinary API calls unless other signals flag it. The attacker does not need to touch the developer’s computer or log into the account dashboard.

Metered billing makes this costly. Language models process large volumes of input and output, and a script can fire requests continuously until the key is revoked, a quota runs out, or another control steps in. Expensive models, long contexts, and high-volume workloads push the bill higher.

Billing is only part of it. A provider that detects abuse may suspend a project or restrict access, which cuts legitimate applications off from their models. Developers can lose their coding assistants, automated review pipelines, test environments, or production services while they investigate and replace credentials. If one key is shared across several applications, cleanup gets harder because every dependent service has to be updated.

Community threads about the OpenCode incident describe unauthorized AI usage and account disruption. Individual reports are not independently verified evidence of the breach’s total impact, and the notification does not quantify any losses or say how many users saw unauthorized activity.

Whatever the final numbers turn out to be, the underlying risk is simple. A provider key is a credential with real financial consequences, and any system that retains it becomes part of the boundary that has to protect it.

Where OpenCode normally stores provider credentials

OpenCode connects to external language model providers, so developers can use OpenAI, Anthropic, other supported providers, and local models. Its documented authentication workflow lets users add provider credentials through the connection interface or the command line.

In the OpenCode 1.x documentation, credentials added through that workflow are written to a local data file:

~/.local/share/opencode/auth.json

That path follows the usual convention for application data on Linux and macOS. OpenCode loads the stored credentials at startup, along with any supplied through supported environment variables or project environment files. The behavior is described in the OpenCode provider documentation and the CLI documentation.

One consequence is that a developer running OpenCode locally with the standard workflow keeps the credential file on their own machine, and no vendor-managed credential service has to hold every key.

A local file is not automatically safe. Its protection depends on filesystem permissions, operating system security, malware exposure, backups, endpoint management, and whether other users or processes can read it. Storing keys in a shared directory, committing them to a repository, pasting them into diagnostic output, or copying them to an untrusted remote host exposes them just as surely.

What changes between local and server-side storage is who has to be trusted. With local storage, the developer mainly protects the endpoint and its credential files. When a remote service keeps the same key, the operator also has to protect the storage system, its administrative interfaces, its backups, its internal access paths, and every process that can retrieve the secret.

Storage also varies by version. The OpenCode V2 documentation describes a different implementation: saved credentials go into a SQLite database instead of being written back to the legacy auth.json file, and a migration step imports supported credentials from the older file. Check which release and deployment model you actually run before assuming your keys live in the same place as anyone else’s. The V2 credential documentation covers the newer behavior.

Neither the local file nor the newer database tells us anything about the mechanism behind the reported breach. The open question is why certain credentials were present on the legacy server at all.

Why were credentials stored on a legacy server?

The notification says provider keys stored in user workspaces may have been exposed. It gives no technical detail on whether those keys arrived through a remote workspace feature, were retained by an earlier authentication implementation, passed through a server-side proxy, or were stored some other way. Each of those would imply a different failure, and only the vendor can say which applies.

Some of these designs are legitimate. A remote development environment may need provider credentials to run model requests from a server instead of a workstation. A managed service might keep credentials to simplify setup or to centralize access to several providers. Either choice demands careful decisions about which components can read the raw secret and for how long.

Picture a simple flow: an application sends a provider key to a backend, the backend stores it, and a worker fetches it for every model request. The backend now holds a credential that can authorize billable requests against an external account, and anyone with enough access to that storage or execution environment may be able to pull it out, depending on the implementation and its controls.

A multi-user backend makes this worse. A flaw in authorization checks, a compromised admin account, an overly permissive database role, or a vulnerable internal service could expose credentials from more than one account. I do not know whether any of those conditions existed at OpenCode. A proper investigation would have to rule each of them in or out.

A legacy system adds its own problem. It may have collected exceptions that no current engineer remembers: an older authentication model, outdated access policies, or data that no newer service needs. A scheduled retirement date does not make its contents less sensitive.

Decommissioning should include an explicit inventory of secrets and data, removal of unneeded credentials, revocation of obsolete service accounts, a check that backups and replicas are handled, and confirmation that nobody can reach the old service through forgotten routes or admin interfaces. Access restrictions should stay in place until all of that is done.

The notification does not reveal whether any of those controls failed, or which part of the retirement process was involved. It does show that decommissioning is a security-sensitive operation and should be planned like one.

What a proper investigation needs to establish

The first job is scoping the exposure, and that takes more than naming the server that was accessed. Investigators need to know which credentials were present, which users or workspaces owned them, and whether the intruder could read the underlying secret values.

Start with the affected system. Authentication logs, administrative access records, application logs, database access history, network telemetry, and records of permission or configuration changes can show when the unauthorized access began, which accounts or services were involved, and what was touched. How useful they are depends on whether the relevant events were logged and kept before the incident.

Next comes a credential inventory. Each affected secret should be tied to its provider, owner, intended use, scope, creation date, and last rotation. If credentials were shared between workspaces or reused across applications, the impact can extend past the system that was directly compromised. Copies in backups, logs, caches, and temporary storage belong in the inventory too.

Then there is provider-side activity. OpenAI, Anthropic, Google, and other providers can expose usage records, request timestamps, model usage, project information, and some authentication metadata. The level of detail varies by provider and account type, but those records help separate legitimate requests from unusual ones. Look for unexpected usage patterns, unfamiliar workloads, sudden spending jumps, and requests made after the suspected exposure window.

Finally, the organization has to establish that the issue is contained. Revoking a key stops it from authorizing new requests. It does not explain how the original access happened or show that every copy of the secret is gone. A full response needs both credential rotation and a fix for the system or process that exposed the credentials.

Until OpenCode publishes more technical detail, the attack path, the affected population, and the extent of any credential extraction remain unresolved.

OpenCode’s earlier security issues

The provider-key notification follows several previously documented security problems in OpenCode. They are worth reviewing because they show the risks that come with a developer tool that exposes local services, executes commands, or interacts with untrusted web content. They are not evidence that the current incident came from the same vulnerability or the same attacker.

In January 2026, security advisories documented two separate issues in OpenCode’s HTTP server and web interface.

CVE-2026-22812 concerned an unauthenticated HTTP server that could expose dangerous functionality, including shell command execution. The GitHub-reviewed advisory describes how a local process, or a website exploiting permissive cross-origin behavior, could reach endpoints that run commands with the privileges of the user running OpenCode. It lists versions before 1.0.216 as affected and names 1.0.216 as the patched version.

CVE-2026-22813 took a different route. According to its GitHub security advisory, a malicious website could abuse the server URL override feature in OpenCode’s web interface to trigger cross-site scripting and then reach process execution functionality. Versions before 1.1.10 are affected, and 1.1.10 is the patched version. The advisory for CVE-2026-22812 has the details on the first flaw.

Both show why a developer application that runs a local HTTP service has to treat browser-originated requests as potentially hostile. A web page is not trustworthy just because it is talking to a service on the developer’s own machine. Localhost endpoints still need authentication, authorization, origin checks, and limits on sensitive operations.

A successful command execution bug can be serious. An attacker running commands as the user may be able to read files that user can access, inspect environment variables, or reach locally available development credentials. The real impact depends on the process’s permissions, the system configuration, and the protections in place.

A separate OpenCode advisory published in September 2026 described a cross-site request issue in certain installations that run the HTTP server through opencode serve and use npm-compatible package managers. In the affected configuration, a webpage could send a request to the global upgrade endpoint with a package specification that leads to installation and execution of an attacker-controlled package. The advisory names 1.18.22 as the patched version and makes clear the attack path depends on the server and installation configuration. See the official advisory.

These are three distinct vulnerabilities with different attack paths and different affected version ranges. No single version threshold covers all of them, and patching them does not resolve the separate credential exposure from the October notification. Verify the relevant fixes for the release you run, and deal with any potentially exposed credentials independently.

Taken together, the advisories show how carefully the trust boundaries around AI coding tools need to be drawn. These applications touch local files, shell commands, browser interfaces, external APIs, and remote services, and each interface is another place where authentication, input validation, and access control have to hold.

Immediate steps for users who may be affected

If you received the provider-key warning, follow the instructions in it and treat the potentially exposed credentials as compromised. Waiting for evidence of unauthorized spending is risky, because a stolen key can sit unused for a while before someone abuses it.

Identify every provider credential that may have been stored in the affected workspace. Include keys for OpenAI, Anthropic, Google Gemini, and any other connected service, plus credentials for custom providers or internal gateways if they passed through the same environment. If your notification named a particular workspace, unrelated credentials were not necessarily exposed, but review any shared secrets that workspace could reach.

Revoke the affected credentials in each provider’s official dashboard or supported authentication interface, then create replacements where you need them. Treat a replacement as a brand new secret and do not restore the original key to the affected environment while the underlying problem is unresolved.

Update every application that relied on the revoked credentials. That can include local OpenCode installations, remote development environments, CI/CD pipelines, test systems, deployment jobs, and custom scripts that call the same provider. If you rotate a key and skip the configuration update, legitimate services break, and an overlooked copy of the old key complicates the investigation.

Review provider usage records for the period around the suspected exposure. Compare requests with known workloads, check for unexpected spending, and look into spikes in token consumption or requests from unfamiliar environments where the provider shows that information. Preserve relevant logs before changing configuration in ways that could erase useful evidence. If you find unauthorized usage, report it to the provider and to OpenCode through their official support channels, and keep timestamps, usage records, and incident references.

Where the provider offers them, set up spending notifications, quotas, rate limits, and project-level restrictions. They will not stop every form of credential theft, but they can cap the damage a stolen key does before someone notices. Their effectiveness varies by provider and account configuration, so check the actual limits instead of assuming a billing alert will stop requests on its own.

If you use OpenCode on a shared machine or remote development server, inspect the surrounding environment too. Check whether other operating system users can read the credentials, whether unrelated processes inherit the environment variables, and whether old configuration files or backups still hold copies of the revoked keys. In a managed environment, administrators should review the matching service accounts, access policies, and secret management systems.

Last, update OpenCode to a release that includes the relevant security fixes, using the official release information for your version and installation method. Patching matters, but it does not replace revoking credentials that may already be out.

How developers can reduce the risk of future credential exposure

I would not read this incident as a reason for every application to avoid remote infrastructure. Remote development, managed AI gateways, and centralized credential services offer real benefits, especially for teams that need consistent access policies and usage monitoring. The design problem is keeping unnecessary components away from long-lived secrets.

Start by minimizing where raw credentials live. If an application can use a provider key locally without sending it to a remote service, fewer systems have to be trusted. When server-side storage is necessary, protect secrets with a dedicated secret management mechanism, strict access controls, encryption in transit and at rest, and narrowly scoped service identities. Encryption alone falls short if the compromised service can pull the plaintext key during normal operation.

Limit privileges and lifetime next. Where providers support scoped keys, project-level restrictions, or short-lived tokens, use the least powerful credential the application needs. A key used by a development assistant should not also reach unrelated projects or services. Shorter lifetimes and routine rotation shrink the window in which a leaked key stays useful, as long as rotation works reliably enough not to cause outages.

Separate the ability to use a secret from the ability to retrieve it. A service may need to send requests to an AI provider without every worker, administrator, or application component being able to read the raw key. Well-designed proxies and secret management systems can enforce that split, though they bring their own operational and security requirements. The right architecture depends on the deployment, but the aim stays the same: fewer components and people holding unrestricted credentials.

Logging needs particular attention. Debug output, request traces, exception reports, and support bundles can capture authorization headers, bearer tokens, or configuration values by accident. Redact sensitive fields before logs are written, and govern log access and retention according to how sensitive the contents are. Inspect diagnostic files and crash reports before sharing them publicly.

Backups and system retirement call for the same discipline. A decommissioning plan should list every place credentials might exist, including database replicas, snapshots, caches, temporary files, and archived logs, and access to the old system should stay restricted until its contents are dealt with. When credentials can no longer be accounted for, revoking them is generally more reliable than trying to prove every stored copy was deleted.

Test these controls instead of trusting the written procedure. Ask whether a compromised application server can expose every user’s credentials, whether access to one workspace can reveal another user’s secrets, whether old service accounts keep permissions they no longer need, and whether the organization can say which keys were reachable during an incident. Threat modeling, access reviews, security testing, and incident response exercises can answer each of those.

What this means for AI coding assistants

AI coding tools sit in an unusual spot in a developer’s environment. Depending on configuration, they read source code, inspect project files, run commands, connect to external services, call APIs that charge for usage, and operate in remote or shared workspaces. With that reach, credential handling is a central security concern.

The OpenCode notification shows what happens when sensitive data stays in infrastructure that is no longer part of the intended design. A system that has been replaced, or that has a retirement date on the calendar, remains part of the attack surface for as long as it holds usable credentials.

It also shows why a product’s usual configuration should not be confused with every deployment path it supports. OpenCode’s documented local credential storage and the reported server-side exposure do not necessarily contradict each other, because different versions, integrations, and remote workflows can handle credentials differently. What matters is which path the affected users took and what protections applied to their credentials along it.

For users, the first move is to revoke potentially exposed keys and inspect provider usage. For OpenCode, the next step is to explain the affected system, the credential handling workflow, the scope of the potential exposure, and the changes that will prevent a repeat. A detailed technical postmortem would let users decide whether they need to investigate additional environments or credentials beyond those in the initial notification.

Until that detail arrives, this is a reported potential credential exposure following unauthorized access to a legacy system. It is not proof that every OpenCode user was affected or that every stored key was stolen, and reporting it accurately means keeping that line clear. It does not reduce the need for prompt remediation.

Editorial note: The incident details in this article come from the notification shown in the supplied screenshot. The full incident scope, the number of affected users, the precise attack path, and reports of individual financial losses have not been independently established by the cited technical documentation.