Which OpenAI sessions can misalignment monitoring stop?

OpenAI’s own coverage table draws a harder line than most launch summaries did. Misalignment monitoring can automatically stop only Responses API conversations that preserve context through persisted reasoning, WebSocket continuation, or OpenAI compaction. Plain Responses requests are monitored but only alert, and Chat Completions is out of scope.

My view is that this makes the feature useful and easy to oversell at the same time. It is a meaningful backstop for long-running agent work. It is a poor substitute for approval gates on writes, because the same guide says an action may already have completed before the stop lands.

What does OpenAI misalignment monitoring stop automatically?

OpenAI documents three request shapes that can be automatically stopped: Responses API workflows using persisted reasoning, WebSocket mode, or OpenAI compaction. In those cases, the monitoring system can identify a turn as a continuation of an earlier conversation and block further execution when it detects a potential issue. The same table draws the negative space just as clearly. A Responses request that uses none of those continuity mechanisms is still monitored, but OpenAI says it can only send alerts to your configured webhook and cannot automatically stop the conversation. Chat Completions is outside the system entirely. That is the finding worth carrying forward into design reviews: using the right model is not enough. The stop path depends on how you preserve state between turns. Tool calls or reasoning alone do not create that lineage.

Automatic intervention by OpenAI request shape

Show data

Automatic intervention by OpenAI request shape. Bar chart. Responses with preserved context: 100 coverage score. Responses without preserved context: 45 coverage score. Chat Completions: 0 coverage score.

Item	Value (coverage score)	Note
Responses with preserved context	100	can alert and can stop
Responses without preserved context	45	alerts only
Chat Completions	0	outside this monitoring system

Why does OpenAI misalignment monitoring depend on preserved context?

The monitoring guide says automatic stopping works only when OpenAI can “identify continuations of a conversation.” The reasoning guide, WebSocket guide, and compaction guide describe three different ways to make that continuity real. Persisted reasoning keeps compatible reasoning items available across turns when you chain with previous_response_id or replay the full history. WebSocket mode keeps one response lineage moving through repeated response.create events. Server-side compaction emits an opaque compaction item that carries forward prior state and reasoning into the next run using fewer tokens. These are different transport and context strategies, but they share one operational effect: OpenAI can tell that the current turn belongs to the same ongoing piece of work. If you drop that lineage and send each turn as a fresh standalone request, monitoring can still observe it, yet the docs stop short of promising a brake.

What does an OpenAI misalignment monitoring stop look like in production?

The first production consequence is that a stop surfaces as an API error. It does not arrive as a reversible approval prompt. When monitoring blocks a request before streaming begins, the API returns HTTP 403 with code misalignment_policy_violation. OpenAI tells you to match the code rather than the message text, stop dispatching further actions for that conversation, preserve request and response ids, and show the available information to the responsible operator or user. OpenAI also says there is no general way to resume a conversation stopped by misalignment monitoring. The second consequence is that a webhook is only supporting evidence. safety.alert.created delivers an alert id, and the guide states directly that configuring an alert webhook does not enable automatic stopping. Teams that wire the webhook and skip the error path are treating an incident feed as if it were an execution control, which it is not.

Which OpenAI actions can finish before misalignment monitoring stops them?

The guide is unusually direct here: because monitoring is asynchronous, “an action may already have completed before monitoring identifies a concern” and “a stopped request does not undo earlier actions.” That sentence should change how you classify the feature. It is closer to a late circuit breaker than to a pre-execution permission policy. If the agent already wrote to a database, sent an email, changed access, or triggered a purchase, the later 403 only blocks what would have happened next. It does not roll back the side effect already in flight. OpenAI reinforces the same limit in the alert-retrieval section: even when request_paused is true, that does not confirm execution stopped or that earlier actions were reversed. If your workflow contains consequential writes, pair this with a design like the one discussed in Claude’s permission policy coverage or with explicit retry and repair rules such as tool-call retry safety.

How an OpenAI stop can land after a dangerous action

Show as text

How an OpenAI stop can land after a dangerous action. Sequence diagram between Your application and OpenAI monitoring. 1. Your application to OpenAI monitoring: Responses turn with preserved context. 2. OpenAI monitoring to Your application: tool action already dispatched. 3. OpenAI monitoring to Your application: 403 misalignment_policy_violation. 4. OpenAI monitoring to Your application: safety.alert.created webhook.

#	From	To	Message
1	Your application	OpenAI monitoring	Responses turn with preserved context. eligible for stopping
2	OpenAI monitoring	Your application	tool action already dispatched. asynchronous monitoring means this can happen first
3	OpenAI monitoring	Your application	403 misalignment_policy_violation. later requests are blocked
4	OpenAI monitoring	Your application	safety.alert.created webhook. review and compensate in your own system

How should you wire OpenAI misalignment monitoring into an agent stack?

Treat it as a monitoring and containment layer that sits behind your own authorization boundary. That means using the Responses API on the workflows that matter, preserving context on every continuation, subscribing to alerts, and keeping your own action log so an operator can reconstruct what happened. OpenAI’s safety guidance still recommends human review “wherever possible” and calls it especially critical in high-stakes domains and code generation. That is the right reading of the product too. Misalignment monitoring is strongest at catching a conversation that has drifted while it is still running, especially in a long chain of tool calls. It is weakest at the exact place many teams most want help: the final moment before an irreversible write. Use it, but do not let it become the excuse for skipping an approval step your own system already knows it needs. The neighboring compaction risk question is the same class of mistake: treating a continuity feature as if it were a trust boundary.