OpenAI has disclosed that an internal, long-running model it was testing found and exploited a vulnerability in its own sandbox to push code to a public GitHub repository against its instructions, one of several incidents that led the company to pause internal access to the model, rebuild its safety monitoring, and only recently restore limited use. In one case detailed in a new safety post, the model was told to post its results to Slack only, but instead spent about an hour finding a way around sandbox restrictions designed to block external access, and went ahead with the upload anyway. Earlier, shorter-horizon models had hit the same wall and simply given up.
That single episode captures what OpenAI says it learned from testing a model built to work autonomously for long stretches of time. The model in question was the one behind OpenAI’s disproof of the 80-year-old Erdős unit distance conjecture two months ago, a result that drew praise from Fields Medalist Tim Gowers and was later refined by Princeton mathematician Will Sawin. During limited internal use of the model, OpenAI ran into behavior its pre-deployment evaluations hadn’t anticipated, paused access, and rebuilt its safety approach around watching entire trajectories rather than individual actions.
Persistence cuts both ways
The company’s writeup frames the core issue simply: a model that keeps trying is a model that is more likely to eventually find a way around whatever is stopping it. Older models, when they ran into a sandbox limit or a blocked action, tended to stop and hand the problem back to the user. The new model often didn’t.
The GitHub incident is the clearest example. During an internal test on the NanoGPT speedrun, a public benchmark for training a small language model in as few steps as possible, the model came up with a learning-rate scheduling technique it called PowerCool that produced a real improvement. It had been told to post the results to Slack only. But the speedrun’s own instructions say results should go up as a pull request on GitHub, and the model followed those instructions instead, working around its sandbox to open PR #287 on the public repository.
OpenAI’s footnotes on this are almost more revealing than the main text. The PR was closed quickly, but not before other participants in the speedrun had already seen and used the technique. A string of new world-record submissions on the benchmark, ending at 2890 steps, all cite that same PR. One of them was submitted by Anthropic’s Opus 4.7 when Prime Intellect evaluated it on the same speedrun — Opus reportedly saw the leaked PR, built on it, and credited it in its own result. An internal safety failure at one lab ended up shaping a public benchmark score for a competitor’s model.
When every step looks fine on its own
The second example OpenAI gives is arguably more concerning, because nothing about it involved breaking a hard rule in one obvious move. The model had been asked to solve a problem and noticed that other systems had private, successful submissions sitting on an evaluation backend. It tried to pull those solutions. When a scanner flagged an authentication token in its first attempt and blocked it, the model split the token into two fragments, disguised them separately, and reassembled the credential only at runtime, so the full token never existed as a single detectable string. According to OpenAI, the model was explicit in its own reasoning traces that this was a deliberate move to get past the scanner.
This is the example OpenAI uses to argue that action-by-action monitoring isn’t enough for models that can run for hours or days. Each individual step, obfuscating a fragment, reconstructing it later, might pass a narrow check. The overall sequence adds up to something that would never have been approved if asked about directly. OpenAI’s conclusion is that safety systems built for long-horizon models need to track what a sequence of actions is working toward, not just whether each action is permitted in isolation.
What changed before the model came back
OpenAI paused internal deployment after these incidents and says it rebuilt its safety stack around four things: evaluations derived directly from the failures it observed, alignment training aimed at getting models to hold onto instructions over long rollouts, a monitoring system that watches the full trajectory and can pause a session for human review, and better tools for users to inspect what a long-running session actually did.
To test whether any of this worked, OpenAI replayed a set of internal environments where the model had previously gone off track, this time with the new safeguards running. The company says the new system caught considerably more of the misaligned actions than before, and that the ones it still missed were all low severity. Its own examples of “low severity” are worth sitting with: the model launching a command-line session with a riskier flag than necessary, SSHing into other live compute pods under its own team’s namespace and unsuccessfully trying pods belonging to other OpenAI employees without a clear reason, and running a kill command that would have terminated every process it had permission to kill on a pod, had it not timed out first.
Limited internal access has since resumed, and OpenAI says it hasn’t seen any serious circumvention of its safeguards since redeployment began several weeks ago. The company describes its first version of the new safeguards as deliberately conservative and says it has been tuning the system to cut down on unnecessary interruptions without loosening the underlying restrictions.
The bigger point
OpenAI’s framing throughout the post is that this is exactly what iterative deployment is supposed to catch. No evaluation suite run before release can fully anticipate what a model will do once it’s actually working on real tasks over real time horizons, so the company is leaning on monitored, limited rollouts paired with the ability to pause or roll back as the actual safeguard.