Trusted Access approval not recognized: account newly flagged and authorized security responses blocked after approval

Resolved 💬 2 comments Opened Jul 14, 2026 by Jump-Wang-111 Closed Jul 14, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

plus

Which model were you using?

gpt-5.6-terra max

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Windows Terminal(WSL)

Codex doctor report

What issue are you seeing?

After my Trusted Access for Cyber application was approved, my account began receiving additional cybersecurity-risk warnings and, more importantly, Codex started blocking legitimate security-research responses entirely.

I now encounter two related behaviors.

First, Codex displays the following account-level warning:

Your conversations have multiple flags for possible cybersecurity risk. Responses may take longer because extra safety checks are on. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber

Second, during legitimate and authorized firmware-security work, Codex sometimes stops the task and replaces the response with:

This content can't be shown We take extra caution with cybersecurity requests. If you’re a security professional, you may be able to apply for Trusted Access. Trusted Access: https://openai.com/form/enterprise-trusted-access-for-cyber/ Learn more: https://help.openai.com/en/articles/20001326

This is therefore not only a misleading warning or a cosmetic account-status issue. It actively prevents Codex from completing my authorized research tasks.

The important sequence is:

  1. I previously used ChatGPT and Codex for authorized academic cybersecurity research.
  2. I applied for Trusted Access for Cyber to reduce false positives affecting legitimate firmware and binary-security work.
  3. My Trusted Access application was approved.
  4. After approval, my account began showing the “multiple flags for possible cybersecurity risk” warning.
  5. Codex also began blocking responses with “This content can't be shown.”
  6. Both messages instruct me to apply for Trusted Access even though my account has already been approved.

The blocking message also points to the enterprise Trusted Access application form. I am using an individually approved ChatGPT account, so it is unclear whether Codex is failing to recognize individual Trusted Access, incorrectly expecting enterprise enrollment, or applying an unrelated account-level restriction.

My work consists of authorized academic cybersecurity research, including:

  • firmware security analysis;
  • binary analysis and reverse engineering;
  • firmware emulation;
  • fuzz testing;
  • vulnerability reproduction and validation;
  • analysis of firmware images, source code, binaries, and physical devices that I own or am authorized to test.

These requests are made in controlled research environments and are directed at local files, research samples, or authorized devices. They are not requests to compromise third-party systems.

I understand that Trusted Access does not remove all safety safeguards, and I am not requesting unrestricted access. However, an approved Trusted Access account should not be repeatedly directed to apply for Trusted Access, nor should normal authorized research be blocked because the approved status is not being recognized.

Could the team please verify:

  • whether my Trusted Access approval is correctly associated with the ChatGPT account used by Codex;
  • whether individual Trusted Access is supported and correctly recognized by Codex CLI;
  • whether Codex is incorrectly checking for enterprise Trusted Access instead of individual Trusted Access;
  • whether the approval has been correctly provisioned across ChatGPT and Codex;
  • whether an additional cybersecurity-risk classification was applied during or after the approval process;
  • whether this classification is overriding my Trusted Access status;
  • why the account began receiving hard content blocks only after approval; and
  • whether this is an expected limitation or an account-provisioning bug.

What steps can reproduce the bug?

Uploaded thread: 019f5bbb-4ff0-7901-bdd2-3762bc671970

What is the expected behavior?

After Trusted Access for Cyber has been approved:

  • Codex should correctly recognize the account’s approved status.
  • Codex should not instruct the user to apply for Trusted Access again.
  • Codex should not incorrectly redirect an individually approved user to the enterprise application form.
  • Legitimate and authorized security-research responses should not be completely hidden solely because the account’s Trusted Access status is missing or incorrectly provisioned.
  • If a specific request remains outside the permitted scope, Codex should explain the relevant limitation rather than showing a generic message that incorrectly states that the user still needs to apply for Trusted Access.
  • Trusted Access approval should not cause the account to be newly marked with multiple cybersecurity-risk flags.
  • The same account status should be recognized consistently across ChatGPT and Codex CLI.

I am not requesting the removal of all cybersecurity safeguards. I am requesting that the approved Trusted Access status be correctly recognized and that authorized research not be blocked because of an apparent account-state, provisioning, or classification error.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #31809
  • #32468
  • #32597

Powered by Codex Action

Jump-Wang-111 · 1 month ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate.检测到可能重复的问题。请核实并关闭您的问题。 Frequently got possible cybersecurity risk #31809 False-positive cybersecurity guard repeatedly hides authorized defensive local-repo work #32468 * Codex Security validation blocked on defensive review of personal repository #32597 _Powered by Codex Action由 Codex Action 提供支持_

Thank you for identifying these related reports. I reviewed all three, and my case appears related but is not an exact duplicate.

  • #31809 is the closest because the reporter had already completed cyber verification but continued to receive the cybersecurity-risk warning. However, it does not establish that the warning first appeared after Trusted Access approval, and it does not document the same post-approval hard-blocking behavior in detail.
  • #32468 reports false-positive “This content can't be shown” blocks during authorized defensive work, but it does not indicate that the affected account had already been approved for Trusted Access.
  • #32597 concerns a defensive review performed through the Codex Security plugin. It involves the same generic cybersecurity block, but it does not involve a confirmed Trusted Access approval or a change in account behavior following approval.

The distinguishing aspect of this issue is the sequence and combination of symptoms:

  1. My Trusted Access for Cyber application was approved.
  2. The “multiple flags for possible cybersecurity risk” warning first appeared after that approval.
  3. Codex then began completely hiding responses during authorized local firmware and binary-security research.
  4. Both messages continue to tell me to apply for Trusted Access, even though the account has already been approved.
  5. One of the blocks directs me specifically to the enterprise Trusted Access form, although my existing approval is associated with my individual ChatGPT account.

I am not claiming that Trusted Access approval necessarily caused the flag. I am reporting that the account behavior changed after approval and that Codex appears not to recognize, or is overriding, the approved status.

This may share an underlying safety-classification issue with #32468 and #32597, and an account-status issue with #31809, but none of them appears to cover the full post-approval provisioning or classification problem described here.