What version of Codex CLI is running?
0.145.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Linux 7.0.11-xanmod1 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
Konsole
Codex doctor report
What issue are you seeing?
Codex displayed “This content can't be shown” twice during a benign local repository review.
The task was to review an experimental PHP extension that converts Zend’s internal PHP AST into nikic/php-parser objects. I asked Codex to inspect C resource ownership and object lifetimes, run local diagnostic tests, and add its findings to a Markdown review document.
I supplied the repository. The task did not involve accessing another system, credentials, malware, or harmful activity.
The exact banner was:
“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.”
The first block interrupted the repository review. The second occurred in the same thread while discussing how to report the first false positive. The Codex UI did not provide a thumbs-down, “report false positive,” or other feedback control.
The local session record also did not expose an HTTP request ID. For the first incident, it recorded an aborted turn without a normal assistant message. For the second, it retained a message ID even though the UI replaced the response with the block banner.
This makes an ordinary defensive C code-quality workflow unreliable, and discussion of the false-positive reporting process itself appears capable of triggering another block.
What steps can reproduce the bug?
Uploaded thread: 019fb199-8243-7ba3-b1f7-b9932cac4972
What is the expected behavior?
Codex should complete a benign, defensive review of local C source without blocking the response.
If an additional check does interrupt a turn, the UI should:
- clearly state whether the turn was cancelled, paused, or still running;
- preserve a stable incident or request identifier;
- provide a “report false positive” action;
- preserve the thread and any safe partial work; and
- allow discussion of the reporting process without triggering another block.
Additional information
Codex version recorded in the local session: 0.145.0
Session originator: codex-tui
Model: gpt-5.6-sol
Session ID: 019fb199-8243-7ba3-b1f7-b9932cac4972
No HTTP request ID was displayed in the UI or found in the local session record. Please correlate the incidents using the session, turn, and message IDs above.
Possibly related: #32225
The uploaded thread contains the full sequence. No proprietary source code needs to be copied into this public issue.
What version of Codex CLI is running?
0.145.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Linux 7.0.11-xanmod1 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
Konsole
Codex doctor report
What issue are you seeing?
Codex displayed “This content can't be shown” twice during a benign local repository review.
The task was to review an experimental PHP extension that converts Zend’s internal PHP AST into nikic/php-parser objects. I asked Codex to inspect C resource ownership and object lifetimes, run local diagnostic tests, and add its findings to a Markdown review document.
I supplied the repository. The task did not involve accessing another system, credentials, malware, or harmful activity.
The exact banner was:
“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.”
The first block interrupted the repository review. The second occurred in the same thread while discussing how to report the first false positive. The Codex UI did not provide a thumbs-down, “report false positive,” or other feedback control.
The local session record also did not expose an HTTP request ID. For the first incident, it recorded an aborted turn without a normal assistant message. For the second, it retained a message ID even though the UI replaced the response with the block banner.
This makes an ordinary defensive C code-quality workflow unreliable, and discussion of the false-positive reporting process itself appears capable of triggering another block.
What steps can reproduce the bug?
Uploaded thread: 019fb199-8243-7ba3-b1f7-b9932cac4972
What is the expected behavior?
Codex should complete a benign, defensive review of local C source without blocking the response.
If an additional check does interrupt a turn, the UI should:
Additional information
Codex version recorded in the local session: 0.145.0
Session originator: codex-tui
Model: gpt-5.6-sol
Session ID: 019fb199-8243-7ba3-b1f7-b9932cac4972
No HTTP request ID was displayed in the UI or found in the local session record. Please correlate the incidents using the session, turn, and message IDs above.
Possibly related: #32225
The uploaded thread contains the full sequence. No proprietary source code needs to be copied into this public issue.