every single chat thing i’ve done today has gotten this message. Why? Has anyone else gotten this message for every chat? Because none of it is connected to what the article says, like at all
I had it happen rarely in the past, mind you I only work on game dev mostly
A few days ago I was working on a browser extension, had AI prepare review prompts, during a review window it trigger a few cyber abuse warnings and I was told that from now on all my prompts will be extendedly checked
I contacted support but they said nothing can be done
Did you get any cyber abuse warnings? My suspicion when the prompts are getting suspicious due to false flags you’re on a fine line where if you don’t sanitize your work you might be hit with perma checks
no. no cyber abuse warnings. it just misunderstood what i was talking about for a single prompt.
but thing is, that was yesterday. it only started today
Same here, but that happened to my account some time ago. Everytime i use 5.6 sol xhigh or even high, if it thinks long enough, the chat will be flagged. I mostly prompt pure math problems, and sometimes about codes, which i think involves no bio or cyber security. the worst thing is that, there will always be no responses from the flagged chat except the short reports (so i need a script to export them!). from my observation, the process is that after you submit a prompt, within like twenty minutes, it will be flagged via “our systems are thinking a bit more…”. and if keep waiting, eventually it will report “connection interrupted. Waiting for the complete answer”, and shortly after that there will be an error “request timed out”, and refreshing the webpage will get nothing but the short reports.
I guess this is actually an account level flag, since the same bug is reproducible in temporary chat mode with a single research level math problem; while i don’t know any criteria. using 5.6/6 pro will less likely to trigger the flag, and will have higher successful response rate (6 pro currently responses 100%). Maybe this problem is caused by potential bio/cyber security related contents recorded in the past chats, or even a kind of QoS, but i don’t know.
Just a quick update what helped me is nuking all my chats and library. Probably some red flag inside. I still get a few here and there but for most part is much better
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.
I think this can occur when the chat session is waiting a long time for a sandbox reply. In my case, the problem seemed to correlate with ChatGPT running long wall-clock performance tests during development work. I’ve since prohibited those and switched to short, bounded tests, and the issue has improved significantly.
So it may be worth checking whether the warning tends to appear when a session is blocked waiting on a long-running sandbox/tool call, rather than simply because the model itself is “thinking” for a long time or because some separate policy/safety review has been triggered.
An example, to fix my long running performance test issue, the instruction I now use is:
“Do not run long wall-clock performance tests. Keep performance measurements to short, bounded runs of only a few seconds where practical, use representative subsets and extrapolation, and do not wait minutes for benchmarks to complete. If a useful measurement cannot be obtained within the bounded time budget, stop and report that rather than extending the run.”