--- title: Which OpenAI sessions can misalignment monitoring stop? url: https://deepthinkingai.org/openai-misalignment-monitoring-coverage/ published: 2026-09-26 author: Shekhar Singh topic: AI Engineering tags: openai, safety, agents, responses-api, monitoring site: DeepThinking AI --- # Which OpenAI sessions can misalignment monitoring stop? **Summary:** OpenAI's misalignment monitoring can automatically stop only Responses API conversations that preserve context through persisted reasoning, WebSocket continuation, or server-side compaction. Other Responses requests are still monitored but only emit alerts, and Chat Completions sits outside the system. Treat it as a backstop. It is not a permission control. ## Key takeaways - OpenAI misalignment monitoring can block continued execution only when a Responses workflow preserves conversation context. - OpenAI says alert webhooks do not enable automatic stopping, so an alert pipeline alone is not an execution brake. - Chat Completions requests are outside misalignment monitoring coverage even when they use the same model family. - OpenAI documents that earlier actions may already have completed before monitoring identifies a concern. - OpenAI still recommends human review and application safeguards for consequential actions. 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** | 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 | The numbers express operational coverage. They do not measure model quality. The important line is whether OpenAI documents a stop path, an alert-only path, or no path at all. ## 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](/auto-permission-policy-intent-channel/) or with explicit retry and repair rules such as [tool-call retry safety](/mcp-tool-call-retry-safety/). **How an OpenAI stop can land after a dangerous action** ```mermaid sequenceDiagram participant Yourapplication as Your application participant OpenAImonitoring as OpenAI monitoring Yourapplication->>OpenAImonitoring: Responses turn with preserved context OpenAImonitoring->>Yourapplication: tool action already dispatched OpenAImonitoring->>Yourapplication: 403 misalignment_policy_violation OpenAImonitoring->>Yourapplication: safety.alert.created webhook ``` - Responses turn with preserved context: eligible for stopping - tool action already dispatched: asynchronous monitoring means this can happen first - 403 misalignment_policy_violation: later requests are blocked - safety.alert.created webhook: review and compensate in your own system OpenAI's own guide warns that earlier actions may already have completed before the stop lands. A stop blocks continuation. It does not reverse side effects you already sent. ## 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](/compaction-summary-injection/) question is the same class of mistake: treating a continuity feature as if it were a trust boundary. ## Wire OpenAI misalignment monitoring as a backstop instead of a gate The order matters because each step closes an assumption the next one would otherwise rely on. 1. **Put consequential writes on the Responses API rather than Chat Completions**: Chat Completions sits outside this monitoring system, so there is no OpenAI stop path to wire up there. If the workflow can spend money, move data, or change state, start from the API that can at least emit the relevant signals. 2. **Preserve conversation context on every continuation**: Use previous_response_id with persisted reasoning, WebSocket continuation, or server-side compaction. Automatic stopping depends on OpenAI being able to identify the request as part of the same ongoing conversation. 3. **Keep human approval in front of irreversible actions**: OpenAI says monitoring can miss issues, can flag legitimate activity, and may identify a concern only after an action completed. Approval belongs before the write. Do not wait for the alert. 4. **Subscribe to safety alerts and store your own action log**: The webhook gives you an alert id. It does not give you a full incident history. Keep request ids, response ids, tool calls, and business object ids on your side so an operator can see what already happened. 5. **Treat 403 misalignment blocks as terminal for that conversation**: OpenAI says there is no general way to resume a conversation stopped by misalignment monitoring. Stop dispatching actions, preserve evidence, and hand the case to an operator or a fresh workflow. 6. **Build compensating actions for any side effect that matters**: A stopped request does not undo earlier work. If a tool can write, message, purchase, or change access, design the rollback or manual repair path before relying on monitoring in production. ## Frequently asked questions ### Does OpenAI misalignment monitoring cover Chat Completions? No. The coverage table in the misalignment monitoring guide says Chat Completions requests are not covered by this monitoring system. Other safety checks can still apply, but this specific stop mechanism does not. ### Does adding a webhook make OpenAI stop more requests? No. OpenAI states directly that configuring an alert webhook does not enable automatic stopping. Webhooks help your own systems react to alerts. They do not widen the set of requests OpenAI can pause. ### Can misalignment monitoring undo a tool action that already ran? No. OpenAI warns that an action may already have completed before monitoring identifies a concern, and that a stopped request does not undo earlier actions. You need your own compensating path for writes. ### Is misalignment monitoring the same thing as a human approval checkpoint? No. OpenAI's safety guidance still recommends human review for consequential actions. Misalignment monitoring is asynchronous monitoring and stopping. It is not a user-facing approval workflow. ### Which Responses integrations get automatic stopping? The guide names three ways to preserve enough context for automatic stopping: persisted reasoning, WebSocket mode, and OpenAI compaction. If your integration uses none of them, OpenAI can alert but not automatically stop the conversation. ## Sources - [Misalignment monitoring](https://developers.openai.com/api/docs/guides/safety-checks/misalignment-monitoring). OpenAI - [OpenAI API changelog](https://developers.openai.com/api/docs/changelog). OpenAI - [Reasoning models](https://developers.openai.com/api/docs/guides/reasoning#preserve-reasoning-across-calls). OpenAI - [WebSocket mode](https://developers.openai.com/api/docs/guides/websocket-mode). OpenAI - [Compaction](https://developers.openai.com/api/docs/guides/compaction). OpenAI - [Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices). OpenAI --- Canonical HTML: https://deepthinkingai.org/openai-misalignment-monitoring-coverage/