Hi, I’m seeing what appears to be a reproducible false-positive cybersecurity restriction when trying to continue an existing Codex thread from ChatGPT.
In the same ChatGPT project, normal messages work correctly. For example, sending hello? receives a normal response.
However, when I send:
codex://threads/<thread-id> look and continue
ChatGPT consistently returns a Trusted Access / cybersecurity warning saying that some cybersecurity requests require additional security protections and asking me to visit Trusted Access.
I reproduced this twice with the same result and stopped further testing because I did not want to repeatedly trigger a security-related check unnecessarily.
Since normal prompts still work in the same project, this does not appear to be a general project or agent failure. The behavior seems specifically related to the codex://threads/... continuation request, or to how that request is routed or classified when ChatGPT tries to access the referenced Codex thread.
If codex://threads/... references are not supported in ChatGPT, I would expect a normal unsupported-link or unavailable-thread response rather than a cybersecurity / Trusted Access restriction.
I also found several recent reports of benign Codex workflows being interrupted by cyber_policy, including continuation attempts involving codex://threads/... references. My case may or may not have the same root cause, but the symptoms appear related.
Is this expected behavior for codex://threads/... references in ChatGPT, or is this an unintended routing or safety-classification issue?
the codex://threads/… continuation shape triggers the cybersecurity/Trusted Access warning;
you reproduced it twice and stopped instead of repeatedly poking the guardrail.
That last part was the right call.
OpenAI now has an official Help article for these additional biological/cybersecurity checks:
For a repeatedly blocked clearly benign/authorized request, it specifically asks for the exact safety message, model/surface, date/time/time zone, request ID if available, and a short redacted task description.
So if you already preserved the timestamps/request IDs from those two attempts, I would send exactly that to Support. No new reproduction is necessary.
I also opened a separate evidence thread today for the additional-safety-review reliability path:
I would keep one distinction clear: your current specimen is a hard cybersecurity/Trusted Access block on the continuation request. The thread above also contains cases where a native BIO/CYBER review stays active for minutes, withholds delivery, then either recovers or fails post-review continuity. Those may be adjacent safety paths, but I would not call them the same mechanism without native evidence.
If a future natural occurrence gives you the “thinking a bit more” review notice rather than a hard block, the review start/clear timing would be especially useful. Otherwise your existing A/B already stands on its own.