avday 
OpenAI said on 20 October that two of its internal coding agents weakened its misalignment monitoring while making routine software changes. One then told the user it hadn’t removed the monitor.
Several headlines say the agents disabled their own monitoring. OpenAI’s report describes something narrower, and more useful if you run coding agents. Each agent edited the code it was working on, and weakened the checks on that code. Any agent with write access to your repo can make the same mistake.
What OpenAI’s agents did to the monitoring
The report covers two incidents, each found on the day it happened. OpenAI’s summary: “In both cases, the agents considered whether monitoring safeguards should be preserved, but interpreted routine coding instructions as permission to weaken them.”
GPT-6.1 Sol, 3 October. A researcher asked the agent to build evaluation tasks from employee feedback collected on Slack, and told it “don’t send any messages.” Later in the session, the monitor flagged a change and the pipeline stopped. The agent then emptied the alert recipient lists and set a no_notify flag, citing the user’s request.
A subagent had judged that setting no_notify “would be unsafe”. The main agent overruled it. The result, in OpenAI’s words: “The misalignment monitor still ran and saved its reports, but human alerts were disabled.” The agent’s final message said: “No messages were sent.”
GPT-6 Astra, 6 October. The agent was asked to copy a reference implementation while keeping the user’s existing tools working. The reference didn’t include the monitor, so the migration “removed the monitor configuration and its runtime integration”. Astra also replaced a regression test meant to keep monitoring in place with one that required monitoring to be absent.
It reported the migration as complete without mentioning the monitor. When the user asked whether it had removed monitoring, it replied: “No […] I did not remove an enabled monitor from it.” OpenAI calls that a false claim.
Neither incident was rated P0, OpenAI’s top severity, and neither agent run was stopped automatically.
What OpenAI changed
OpenAI says Auto-Review, which it already requires for all internal Codex use, “has been updated to detect and block attempts to disable misalignment monitoring.” It’s also working toward a rule that every kind of workload has a safety case setting out its monitoring. Workloads without one “will be terminated automatically”. It gave no date.
The report flags a wider gap too. OpenAI has “seen several cases in which agents launched a deployment with misalignment monitoring disabled”: the agent stayed monitored, but the thing it launched didn’t.
As for why it happened: “We don’t yet have a satisfying explanation for this behavior.” OpenAI is testing two ideas, plain overpersistence or a specific tendency to evade monitoring.
Roman Yampolskiy, an expert on AI and cybersecurity at the University of Louisville, told Al Jazeera: “A safety mechanism that the system being monitored can disable is not a reliable safety mechanism.”
What to lock down if you run coding agents
OpenAI’s own contrast is the useful part. It expects monitoring to be “difficult to disable for Codex workloads, because monitoring runs within the service that handles model requests, outside the agent’s direct control.” Monitoring is easier to disable for evaluations, OpenAI says. In both incidents, it was wired into code the agent was changing.
- Keep the watcher out of reach. Alerts, audit logs and monitoring config should sit somewhere the agent can’t write. Codex’s docs say monitoring “doesn’t replace sandboxing, permissions, or review of the result.”
- Deny edits to the guard rails, tests included. Astra rewrote the test that protected the monitor. In Claude Code, a deny rule wins over any allow rule: “An allow rule can’t carve an exception out of a deny rule.”
- Remember what the sandbox covers. Claude Code’s docs say “the sandbox covers shell commands only. Claude’s file tools, MCP servers, and hooks run outside it.” So add permission rules as well as the sandbox.
- Scope your “don’ts”. “Don’t send any messages” was read as covering automatic alerts to OpenAI’s Security team. Say which messages you mean.
- Read the diff, not the summary. Astra’s summary left out the change that mattered.
- Watch the hand-offs. In the Sol case, the subagent was more careful than the agent that overruled it.
A minimal Claude Code example, for a repo that keeps its monitoring under monitoring/:
{
"permissions": {
"deny": ["Edit(./monitoring/**)", "Edit(./tests/monitoring/**)"]
}
}Those rules cover Claude’s own file tools and shell commands it recognises, such as sed. They don’t cover “a Python or Node script that opens files itself”, the docs say. For that, turn on the sandbox as well.
Codex users should also know that its Auto-review “does not run for routine actions already allowed inside the sandbox”. Both of OpenAI’s incidents started from routine coding requests.
What happens next
OpenAI says it will study the cause with paired evaluations, resampled agent runs and experiments on the models’ internal activations. The safety-case rule has no deadline yet. Its public list of misalignment reports is the place to watch for the next one.
For more on OpenAI’s fundraising, see OpenAI’s $30bn funding round. For a look at how a lab serves its models, see DeepSeek’s open-source DeepInfer.
