Cybersecurity block message is non-actionable when content cannot be shown

What issue are you seeing?

When a cybersecurity safeguard blocks output, Codex displays only:

ⓘ 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 message is non-actionable, especially when the classification is a false positive or the user is not a security professional. It does not tell the user:

• which request, operation, or broad category caused the block;
• whether rephrasing, narrowing the scope, removing a particular operation, or retrying is appropriate;
• how to report a suspected false positive with the relevant session/feedback identifier;
• whether the current run can continue safely or must be restarted; or
• whether Trusted Access is actually applicable to the account and request.

The links explain policy/access at a high level, but they do not provide an in-product recovery path. This is a message/UX bug distinct from whether the underlying safeguard classification was correct.

What steps can reproduce the bug?

1. Use Codex App or CLI for a request that triggers the cybersecurity safeguard (including a false positive during legitimate development or defensive work).
2. Wait for the run to be interrupted.
3. Observe the message above.
4. Attempt to determine from the message what specifically can be changed or how to report the false positive.

The UX problem is reproducible whenever this block message appears; reproducing any particular classifier decision is not required to evaluate the error copy.

Related exact-message report: #40949. Other issues report false-positive classifications, but this issue concerns the lack of actionable diagnostics and recovery guidance in the message itself.

What is the expected behavior?

The block should remain appropriately cautious without exposing sensitive classifier internals, while still giving a concrete next step. For example, the UI could:

• identify the affected request or broad operation category;
• say whether the user may retry after narrowing/rephrasing and provide a safe example;
• provide a “Report false positive” action that automatically includes a feedback/session ID;
• state whether the thread/run can continue and how to resume it;
• show Trusted Access status when relevant, rather than presenting the application link as the only remedy; and
• preserve enough context that the user does not have to guess which action caused the interruption.

At minimum, the message should distinguish “this request cannot be fulfilled” from “this wording/context may be revised” and provide a direct feedback path.

Additional information

The official OpenAI model guidance acknowledges that safeguards may sometimes intervene on legitimate dual-use work, including code review, vulnerability research, patch development, debugging, security education, and defensive testing. That makes a usable false-positive and recovery path important even when the safeguard itself is operating as designed:

https://developers.openai.com/api/docs/guides/latest-model#safeguards

Observed on Codex App 26.707.72221 on macOS (Darwin 25.6.0 arm64), but the same exact message has also been reported from Codex CLI in #40949, so this likely applies across surfaces.