OpenCode's leak was Console, n... Note

OpenCode's leak was Console, not your CLI

On October 17, 2026, news broke that OpenCode Console, an optional hosted service, had been breached, leading to the exposure of user-stored third-party provider credentials. This incident sparked widespread confusion because many users initially mistook the breach for the local OpenCode CLI, due to the shared naming. The breach specifically affected provider keys (e.g., OpenAI, Anthropic) saved in the Console workspace, not keys stored locally by the CLI. Affected users were advised to revoke and replace these keys and review usage.The vendor's statement confirmed unauthorized access to a "legacy system" and urged users to revoke compromised keys. An OpenAI customer's email corroborated the incident, noting their affected key had already been disabled. The lack of clarity in the initial announcement about which specific product was compromised caused significant frustration.For users of the local coding agent, credentials are stored on their machine and requests are routed based on their configuration. This means that if their configuration pointed to a local gateway (e.g., 127.0.0.1:8787), their keys were not exposed through the hosted Console service. However, if their configuration directed to the vendor's hosted gateway, key revocation was necessary.The author performed four checks: verifying endpoint authentication, counting credentials on disk, scanning for duplicate keys, and checking for keys committed to a configuration repository. The endpoint check, identifying local routing, confirmed the author's keys were not directly impacted by the Console breach. However, local storage of plaintext keys still presents security risks.The author also noted that retired keys might still reside in backup files and that a public repository for config files poses a risk if credentials are accidentally committed. For anyone using a hosted key service, the author recommends five steps: identify the product used, revoke compromised keys at the provider, review usage graphs, scan for duplicate key copies, and ideally, use a setup where the agent never directly holds the key. The key takeaway is to remove credentials from the agent's direct reach to minimize the blast radius of a compromise.