OpenCode credential leak affected hosted Console service, not the CLI

What was actually breached

Reports that circulated on 2026-10-17 described the incident as OpenCode being hacked with user credentials leaked. According to a write-up on dev.to, originally published at agentjournal.dev, the exposed system was not the command-line coding agent most people run daily. It was OpenCode Console, an optional hosted service where teams connect provider accounts so members can share them, and which stores those provider credentials on its own side. The local agent, by contrast, keeps keys in a file on the user's machine and sends requests to whichever endpoint the configuration names.

What the vendor said

The post quotes a statement from the OpenCode team acknowledging unauthorized access to "a legacy system that we were in the process of decommissioning." The statement said third-party provider keys, such as OpenAI or Anthropic keys saved in a workspace, may have been exposed, and instructed affected users to revoke and replace those keys at the provider, update anything using them, and review recent usage.

The same post reproduces an email received by an OpenAI customer describing the event from the provider's side: an intruder had reached a system holding customer API keys, one of the affected keys belonged to that organization, and the key had already been disabled.

The post also reports that the discussion thread reached 975 points with 37 top-level comments, and that most of the argument concerned which product had been breached rather than the breach itself.

Why the shared name caused confusion

Console's design centers on custody, the post explains, citing the service's documentation: users connect provider accounts they already pay for, the service stores each credential and serves providers through its gateway, and models are shared across a workspace. Holding the key is what makes the sharing work.

The local agent does the opposite. It keeps provider credentials in a local file and routes requests to the base URL configured for each provider, which could be the vendor's hosted gateway, a local proxy, or a third-party API. That single distinction was missing from the announcement, and it resolves most of the confusion.

How one user verified exposure

The author, a daily CLI user who never connected a provider to Console, ran four checks instead of assuming safety. Reading the base URL for each provider showed all three entries pointing at 127.0.0.1:8787, a local gateway rather than the hosted service. Listing the auth file showed three provider entries with file mode 600. A scan of 38,734 files across projects, skills, dotfiles and shell history for the exact key strings found zero copies. A check of the configuration repository's 49 tracked files confirmed the auth file was not among them.

The endpoint check is the decisive one, the post argues. Loopback routing means the key is presented to code the user runs, not stored in a hosted workspace. A configuration pointing at the vendor's gateway URL, combined with having gone through its connect flow, places a user in the affected category, and those keys should be revoked.

What the checks do not prove

Local mode is not automatically safe. The post notes that all three keys sat as plaintext JSON readable by anything running as the user; file mode 600 stops other accounts on the machine, not a compromised package running under the same user. The scan also surfaced a second auth file holding an older value for one provider, left over from a rotation on 2026-10-20, which the author planned to verify as dead before deleting. The configuration directory is itself a public repository, one careless commit away from exposing files that should stay private.

Recommended steps for hosted key users

The post closes with five steps. Work out which product you actually used, checking the configuration rather than relying on recollection. If you connected a provider to a hosted service, revoke the key at the provider's dashboard rather than only disabling it inside the service. Read provider usage graphs for the past two weeks, since anomalies tend to appear in billing before any notification arrives. Hunt for second copies of keys in repositories, backups, shell history, CI secrets and stray environment files. Prefer designs in which the agent never holds the key at all, such as a local proxy that injects credentials at the network layer.

Why it matters

A breach notice naming a product family does not tell users which component was hit, and tools that ship in both local and hosted forms make that ambiguity expensive, because the correct remediation differs completely between the two. The incident also illustrates the structural trade-off of credential-sharing services: their convenience comes precisely from storing keys server-side, which concentrates risk in one place. For anyone running coding agents, the lasting lesson is architectural: put credentials somewhere agents cannot reach them, since isolating the agent offers little protection when the key sits in a service the agent can access.