OpenAI cybersecurity classifier blocked Linux bug research, researcher says
Daniel Fox Franke says OpenAI’s filter blocked defensive debugging, so he used GLM 5.2 and Kimi K3 to investigate a possible Linux kernel bug.
By Dominic Okoye · Staff Writer
· 3 min read
The OpenAI cybersecurity classifier blocked security researcher Daniel Fox Franke from using GPT-5.6 Sol to investigate repeated ripgrep segmentation faults, Franke told The Register. He said the refusals pushed him to open-weight models from Z.ai and Moonshot AI, which helped him build the case that the crashes may involve a Linux kernel bug.
Franke said the work began during a long-running Codex session after he noticed ripgrep, the command-line search tool, had crashed more than once. He asked the main agent to create a subagent to find the cause. Within minutes, he said, the system reported that a subagent had triggered OpenAI’s classifier for an inappropriate security-related direction.
The researcher wrote on social media that OpenAI’s security filter made basic crash investigation difficult, including questions about which ripgrep entry points into musl could lead to allocations on the mallocng heap. In comments to The Register, he said attempts to reproduce the crash and inspect heap behavior appeared to trigger the filter most often.
Why did OpenAI's cybersecurity classifier block the bug hunt?
Franke said he tried to narrow the task to source-code review of ripgrep and musl, and explicitly told the model not to reproduce the crash or analyze core files. The classifier still intervened, he said, despite the model following those limits. At that point, Franke said he stopped trying to get useful work from GPT-5.6 Sol.
He distinguished the classifier from the model itself. According to Franke, GPT-5.6 Sol did not refuse on its own and appeared to understand that several classifier interventions were inappropriate. His complaint was aimed at a separate output-control system that, in his view, prevented benign defensive analysis.
Franke said he did not test Anthropic’s Claude models because he expected them to be more restrictive. OpenAI’s error messages pointed him toward its Enterprise Trusted Access program, he told The Register, but he believed he was not eligible. He later learned OpenAI also has a Trusted Access path for individuals, but said he has not applied because he objects to the verification process and will avoid it while open models remain usable.
Which models did the researcher use instead?
Franke said two open-weight Chinese models were useful in different ways: Z.ai’s GLM 5.2 and Moonshot AI’s Kimi K3. Open-weight models make their weights available for others to run or inspect under the terms set by the provider, giving researchers an alternative when hosted systems impose safety limits.
According to Franke, Kimi K3 produced the initial clue that shifted the investigation toward the Linux kernel, though he said its later work became unreliable as the context grew. He credited GLM 5.2 with reviewing Kimi K3’s output and assembling the stronger argument.
The Linux issue is not finished. Franke told The Register there is no patch yet, and the bug does not currently appear to be an exploitable vulnerability. He said he is confident the crashes are caused by a kernel bug and that he has identified a kernel bug, but he has not yet proven they are the same issue or prepared a submission for the Linux Kernel Mailing List.
The incident lands in a broader fight over open-weight AI. The Register reported that much of the U.S. tech industry recently supported open-weight models in response to positions from Anthropic and OpenAI that critics have described as protectionist. U.S. policy on open-weight models remains unsettled.
This story draws on original reporting from The Register.
