OpenCode’s defensive AI agents stopped analysing malicious code during an active attack after that code activated model safety filters, TechCrunch reports. The models had initially helped the company’s response, but later began refusing the material they were asked to inspect while the attack continued.
The incident exposes a specific limit for teams using coding agents in incident triage. A model may be available and capable of analysing ordinary software, yet become unavailable when the input itself resembles prohibited activity. In this case, the hostile code was both the object requiring analysis and the trigger for the refusal.
The response agents stopped at the hostile code
OpenCode co-founder Dax Raad said attackers had been trying to enter the company’s systems continuously for 48 hours, requiring defensive AI agents to run around the clock, according to TechCrunch’s account. The models helped for a period before their safety filters reacted to the malicious code and they started refusing the analysis work.
The available evidence does not identify the models, the exact requests submitted to them or the safety policies that intervened. It also does not establish whether every defensive agent failed at the same point. What it does establish is narrower: refusal behaviour interrupted at least part of an AI-assisted response while the team remained under pressure.
That distinction matters because the safety system did not merely limit code generation. It affected analysis of code supplied as evidence. A team assessing an AI tool for defensive work therefore needs to examine whether the tool can process adversarial material, not only whether it can explain normal application code.
Conceptual illustration, not a photograph, of hostile code activating a model’s refusal mechanism.
Safety policy became an availability constraint
Safety filters are intended to prevent models from assisting harmful activity. During incident response, however, defensive and offensive inputs can contain similar commands, exploit patterns or credential-handling logic. The OpenCode report shows the operational outcome without explaining how the models classified the requests: the filters activated and the analysis stopped.
For a commercial operations team, the relevant use case is bounded. Consider a hypothetical compromise of a script that moves information between a sales platform and a billing system. If an AI coding agent is assigned to inspect the altered script, a refusal can delay understanding of the modification even though the requested task is defensive. The OpenCode incident does not prove that every agent would refuse that script, but it shows that successful analysis of routine code is not evidence that hostile code will remain processable.
TechCrunch characterises access to vetted models with fewer safety restrictions as a problem for companies confronting AI-driven attacks. The report does not provide a comparison of such models or show that reducing restrictions would have resolved OpenCode’s case. Choosing a less restricted model is therefore not an established remedy from the available evidence.
The affected surface was narrower than OpenCode itself
The breach and the model refusals should not be merged into a claim that every OpenCode installation was compromised. According to Raad’s statement reported by TechCrunch, the exposed keys were confined to workspaces in OpenCode Console. The open-source application and command-line tool were not affected because their keys were not sent to the company.
Provider actions addressed the credential layer separately. Anthropic and Google blocked keys they believed had been exposed, while OpenAI worked with OpenCode to restore access and refund affected API credits; OpenCode also said refunds for unauthorised charges were underway, TechCrunch reports. The immediate credential response is covered in our separate analysis of the OpenCode key exposure.
These are two distinct operational problems. Revoking an exposed key can stop further use of that credential. It does not ensure that an AI agent assigned to investigate the attack will accept the evidence it needs to analyse.
Conceptual illustration, not a photograph, of the Console exposure remaining separate from local OpenCode tools.
Test the refusal path before assigning incident triage
The practical decision is whether an AI coding agent is being treated as an optional assistant or as an essential analysis path. If the workflow depends on it, the team needs to know what occurs when a malicious sample triggers a refusal: whether another approved analysis route exists, whether the rejected material can be isolated differently and whether the incident can proceed without the model.
OpenCode’s experience supports testing that refusal path with representative adversarial material before relying on an agent for live triage. It does not support assuming that a particular provider, prompt or safety configuration would have avoided the interruption. The source does not disclose enough technical detail to make that comparison.
The element to watch is OpenCode’s account of which models and filters intervened, if the company publishes it. Until then, the demonstrated limit is precise: AI agents that assist with ordinary code analysis can stop at the moment hostile code becomes the evidence under investigation.
