Technology

OpenCode Had a Security Breach That Copied How Its AI Works

Martin HollowayPublished 2w ago2 min readBased on 2 sources
Reading level
OpenCode Had a Security Breach That Copied How Its AI Works
source:opencode.ai

OpenCode said on Oct. 17, 2026, that it had a security breach tied to a large-scale distillation attack, affecting 1.4% of OpenCode Console users. OpenCode on X A distillation attack copies how a system behaves by asking it many questions through normal channels, like learning a recipe by tasting the dish many times.

The company said it notified all affected users by email in the morning after the breach. OpenCode on X

OpenCode described the incident as ongoing and said it cannot share more details at this point. OpenCode on X It said it is working with Anthropic, OpenAI and Google to fix the problem. OpenCode on X

OpenCode describes itself as an open source AI coding agent for writing code in the terminal, IDE or desktop. OpenCode Those are the text command window, the code-writing program, and a separate app. The project lists over 208,000 GitHub stars, 950 contributors and over 13,000 commits, and says it is used by over 16 million developers every month. OpenCode

On architecture, OpenCode says it supports 75+ LLM providers through Models.dev, including local models. OpenCode That means it can connect to many AI companies, or run the AI on your own computer. It also says it does not store any user code or context data. OpenCode

The broader context here is the difference between the Console account system and the tool that actually runs the code. This kind of attack does not look like normal theft. It copies behavior slowly through regular use. The scope is small. The method still matters.

In my view, the detail worth watching is the joint cleanup. Logs, keys, traffic patterns and rate-limit signals will need to be compared across company lines. That is hard to do. It is also the right setup when one tool connects developers to several large AI systems.

Looking at what this means for teams, the questions are practical. How Console accounts, tokens and usage limits were set. How attack traffic was told apart from normal busy use, with its retries, repeated requests and backup models. How updates will be shared while the incident is still active. None of those can be answered from the current statement. The statement is purposely short.

That shortness is understandable during an active fix, and it puts weight on what comes next. Engineers will want to know which Console parts were affected, what passwords or keys to replace, and what safety checks will change. Clear, updated guidance will matter most.

The longer arc remains constructive. Open tools that work with many providers give developers choice and flexibility. Problems like this force better thinking about limits, warning signs and careful access. Systems that learn those lessons tend to become stronger and easier to trust.