codex://threads/... continuation request unexpectedly triggers Trusted Access / cybersecurity restriction

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?

Your control is unusually clean:

  • same project;
  • ordinary message works;
  • 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.

Hey @nono2, thanks for documenting the issue so clearly. Thanks also to @krasnik for sharing the relevant Help Center guidance.

Are you still running into this when trying to continue the Codex thread? If so, which ChatGPT model were you using, and what did the warning say exactly? Please leave out any private details.

- Moizz