A useful update here, because there is now both official documentation and native trace evidence for what this banner can mean.
OpenAI now documents additional automated safety checks for biological and cybersecurity requests and says those checks can make a response take longer. If the response can be provided safely, it continues after the check; otherwise content may not be shown. The help article also says seeing the notice does not by itself mean OpenAI determined that the user violated policy:
https://help.openai.com/en/articles/20001326
I have now captured this at the native turn-stream level on several ordinary GPT-5.6 Max workers.
Two completed same-account specimens are especially clean:
- one BIO review stayed active for about 16m08s;
- during that review the backend created 52 turn nodes, including 25 tool outputs;
- every one of those nodes was first delivered to the browser only after the review cleared;
- the largest measured server-create → client-delivery delay was about 16m10s;
- the turn then completed normally.
A separate CYBER review on another worker lasted about 10m04s:
- 50 nodes were created during review, including 26 tool outputs;
- again, all were withheld from the client until review cleared;
- the turn completed normally afterward.
So at least in those specimens, the apparent “nothing is happening” period was not idle worker compute. Productive work continued behind the review gate while the client saw little more than worker heartbeat traffic.
Today I also captured something that may be relevant to the “sometimes almost none, sometimes everywhere” experience: multiple separate conversations on the same account entered native safety review in overlapping windows. Three different current conversations entered CYBER review around 10:51-11:04 UTC, while predecessor turns on two of those conversations had already entered BIO review.
That is real temporal clustering on one account. I would not turn it into “OpenAI has a documented account security cycle” or claim a hidden account flag from this alone. The server predicate is unknown, and Community reports are not enough to establish causation.
But the intermittency is independently reported here too: users have described the warning appearing once in a while, becoming much more frequent after a period of normal use, disappearing temporarily and then returning in new/existing chats, or becoming a “constant nuisance lately.”
One important negative control: not every reviewed turn recovers. I also have a current specimen where BIO remained active, fresh worker heartbeats eventually stopped, resume became unavailable, and the canonical tree stayed frozen even though stream_status kept reporting IS_STREAMING. I classify that state as wedged / not proven alive, not as a normal completed review.
So my current boundary is:
additional safety review can absolutely create long, misleading periods where the UI looks stalled while the worker is still executing; the review behavior can cluster in time on one account; but an account-level flag/cycle or exact trigger is not proven.
Raw HAR/session material stays private because it contains authentication/session data. No deliberate safety-trigger rerun requested.