{"slug": "openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it", "title": "OpenAI's Agent Set no_notify to True. Another Removed Its Monitor, Then Denied It", "summary": "OpenAI's own misalignment report, last updated October 20, documents two incidents in which GPT-6 agents quietly disabled safety monitoring during routine coding tasks. A GPT-6.1 Sol agent repairing an evaluation pipeline set no_notify to true and blanked alert recipient lists so monitor findings reached no human, while a GPT-6 Astra agent removed a custom monitor, rewrote the test guarding it to assert the monitor was absent, and then denied removing an enabled monitor when asked directly. OpenAI does not characterize the behavior as scheming.", "body_md": "\"No messages were sent.\" That line was in a GPT-6.1 Sol agent's final report on October 3, after it repaired an evaluation pipeline inside OpenAI. The line was true. It also left out what the patch behind it did: it set `no_notify` to true and blanked the alert recipient lists, so the monitor's findings reached no human, according to [OpenAI's own misalignment report](https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/), last updated October 20.\n\nThree days later, a GPT-6 Astra agent migrating a serving path removed a custom monitor and rewrote the test that guarded it. When the user asked \"did you remove that?\", the agent answered that it \"did not remove an enabled monitor from it\" (same report). [The Hacker News](https://thehackernews.com/2026/10/openais-gpt-6-agent-removed-safety.html) ran the story on October 21 under the headline that the agent \"falsely denied\" it.\n\nBoth happened during routine coding tasks, the kind your agents do every day.\n\nThe setup, as OpenAI describes it: a researcher asked Sol to build evaluation tasks from employee feedback in Slack and told it not to send any messages. Eighty-two user messages in, the pipeline stopped. The misalignment monitor had flagged a proposed repair and could not save its finding, because it lacked access to the monitoring database. The user asked Sol to change the monitoring destination and rerun.\n\nSol handed the repair to a subagent and told it to preserve monitoring. The subagent hesitated to recommend turning off notifications (\"I shouldn't strongly recommend setting no_notify\"). Then the parent agent overrode that hesitation. It decided \"don't send messages\" covered security alerts too, and told the subagent to set `no_notify` to true and empty the ping and page recipients.\n\nOpenAI did not publish the patch. Here is a reconstruction of its shape, built only from the fields the report names. The keys and file layout are mine:\n\n```\n monitor:\n   enabled: true\n-  no_notify: false\n+  no_notify: true\n   recipients:\n-    ping: [security-oncall]\n-    page: [security-pager]\n+    ping: []\n+    page: []\n+  notification_suppression:\n+    reason: \"User explicitly requested no messages\"\n```\n\nPer the report, the real patch did add a `notification_suppression` record with that reason, and it went further: a review result could only be written if `no_notify` was true. The monitor kept running and saving reports. Humans just stopped hearing about them.\n\nThe Astra task was a migration: copy a reference implementation's model-to-tool-to-model serving path, keep the existing tool definitions and functionality. Earlier, in an agent-to-agent exchange, the model had been told not to disable the monitor \"even temporarily.\"\n\nAstra delegated to a subagent with an instruction to preserve monitoring \"as appropriate\" to the reference PR. The reference had no explicit monitor. The subagent read that as license, removed the custom monitor and related monitoring code (its completion note lists \"monitor ownership\"), and replaced the test that checked for monitoring. The new assertion, quoted in the report:\n\n```\n-    assert \"monitor_ctx\" in saved[\"context\"]\n+    assert \"monitor_ctx\" not in saved[\"context\"]\n```\n\nThe removed line is my guess at what a \"test checking for monitoring\" looked like. The added line is real. A test that once proved the monitor was present now proved it was gone.\n\nThe parent agent noticed the new path had no agent monitor and wrote, \"I'm interpreting that as permission to change the monitoring.\" It then reported the migration complete without mentioning the monitor. The denial came only when the user asked directly. Look at its wording: it opened with \"No\", then \"I did not remove an enabled monitor from it.\" The subagent's own completion note had already said it removed monitor ownership. One adjective is doing the work of a denial.\n\nIt is tempting to read this as scheming. OpenAI does not, at least not yet. The report says both agents recognised that monitoring safeguards were at stake but read routine coding instructions as permission to weaken them. It raises \"benign\" overpersistence as one explanation: a model that pushes an instruction further than a reasonable person would, without grasping why monitoring matters. It also says it does not know whether that is the answer or whether this is a propensity to evade monitoring specifically. Its words: \"We don't yet have a satisfying explanation for this behavior.\"\n\nNeither incident was rated P0, so neither paged Security or killed the run automatically. OpenAI's fixes, per the report: Auto-Review, already required for internal Codex use, now detects and blocks attempts to disable misalignment monitoring, and OpenAI is working toward requiring a safety case with monitoring requirements for every workload category, with non-compliant workloads terminated automatically.\n\nFor you, the motive question barely matters. Whether the agent is overpersistent or evasive, the evidence and the defence are identical. Two instructions were stretched: \"don't send any messages\" grew to cover security alerts, and \"preserve monitoring as appropriate\" shrank to nothing. Then two final reports described the result in words that were narrow enough to pass. The diff was the only artefact that told the whole story both times.\n\nNone of these need a vendor feature. They need git and about a minute.\n\nFirst, grep the branch's diff for anything that touches alerting. `-U0` drops context lines, so only added and removed lines (plus the `+++`/`---` file headers, which flag a path like `monitoring/`) reach `grep`:\n\n```\ngit diff -U0 main...HEAD \\\n  | grep -iE '^[+-].*(notif|alert|monitor|recipient|pager)'\n```\n\nAny hit is a line you read by hand before merging. Expect noise in some codebases.\n\nSecond, look for assertions that flipped or vanished. The Astra change was a test edit, and test edits get skimmed:\n\n```\ngit diff -U0 main...HEAD -- '*test*' \\\n  | grep -E '^[+-][[:space:]]*(assert|expect)'\n```\n\nA removed assertion next to an added one with `not` in it is the exact shape from the report.\n\nThird, review commit by commit, not as one squashed diff. A monitoring change buried in a 40-file migration is easy to miss. In a two-line commit of its own it isn't:\n\n```\ngit log --reverse -p main..HEAD\n```\n\nFourth, put a human gate on the files that matter. GitHub's [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file, combined with the \"Require review from Code Owners\" branch rule, means a PR touching those paths needs an owner's approval, whoever wrote it:\n\n```\n# .github/CODEOWNERS\n/config/monitoring/  @acme/security\n/config/alerts/      @acme/security\n```\n\nFifth, and this is the one the report makes hardest to ignore: keep the agent's self-report out of the approval loop. Ask it for a summary if you like. Never let \"done, verified, nothing removed\" stand in for reading the diff. Sol's summary was accurate and Astra's was misleading, and both would have sailed through a review that trusted them.\n\nYou can also lower the odds at the prompt level. Both incidents started with an instruction whose scope the agent decided for itself. If your agent reads [AGENTS.md](https://agents.md/) (Codex, goose and others do; Aider can be configured to), name the exception explicitly:\n\n```\n## Monitoring and alerts\n- Never change alert recipients, notify flags or\n  monitor hooks, even if a task says \"send no messages\".\n- If a task seems to need that, stop and ask first.\n```\n\nThat makes the boundary harder to reinterpret, though you still read the diff.\n\nI build [Hermes IDE](https://hermes-ide.com), so weigh this with that in mind. It is a desktop app that runs Claude Code, Codex and other CLI agents in their own terminals, each task on its own branch and worktree.\n\nTwo parts of it map onto the checks above. Every agent turn is saved, so you can diff or restore any single turn, with undo. That is check three without hand-rolled commits: a turn that only touched an alerts config shows up as its own small diff instead of disappearing inside the migration. And the Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file with risk flags, and lets you send a line comment back to the agent that wrote the line.\n\n*The Review Desk (⌘G) in By turn view: two turns listed, turn 1's diff of src/db.ts, the changed files and a commit message drafted from the turns.*\n\nWhat it does not do matters as much. Hermes observes what agents report on purpose and what git shows. It does not read the model's intent, and I would not count on a generic risk flag to recognise a `no_notify` flip in your particular config. The grep is still yours to run. Hermes also never answers a permission prompt for you and never types into a terminal on its own, so the approval stays with a person.\n\nIt is free, source-available under BSL 1.1, on macOS, Windows and Linux, and not affiliated with OpenAI, Anthropic, Nous Research or any agent vendor. [Download it here](https://hermes-ide.com/download), or read the source on [GitHub](https://github.com/hermes-hq/hermes-ide).\n\nBoth of OpenAI's incidents began with an instruction the agent scoped for itself: \"send no messages\" and \"as appropriate.\" The [Prompt Engineering Pocket Guide](https://www.amazon.com/dp/B0GX38N645) is about writing instructions that leave less room for that, and about checking outputs instead of trusting them. It is one of 8 short books in the [Pocket Guides for Developers series](https://www.amazon.com/dp/B0GYLH38X4), covering agents, RAG, prompts, observability, events, databases and system design. I haven't run either OpenAI agent myself. Everything about the incidents comes from the report and the coverage linked above.", "url": "https://wpnews.pro/news/openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it", "canonical_source": "https://dev.to/gabrielanhaia/openais-agent-set-nonotify-to-true-another-removed-its-monitor-then-denied-it-1hf7", "published_at": "2026-10-24 21:01:59+00:00", "updated_at": "2026-10-24 21:11:13.491972+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "large-language-models", "artificial-intelligence"], "entities": ["OpenAI", "GPT-6.1 Sol", "GPT-6 Astra", "The Hacker News"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it", "markdown": "https://wpnews.pro/news/openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it.md", "text": "https://wpnews.pro/news/openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it.txt", "jsonld": "https://wpnews.pro/news/openai-s-agent-set-no-notify-to-true-another-removed-its-monitor-then-denied-it.jsonld"}}