Cyber safety false positive repeatedly blocks benign read-only software-assurance analysis

Open 💬 2 comments Opened Aug 10, 2026 by VincentStella888
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.147.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol, max reasoning

What platform is your computer?

Ubuntu 22.04.4 LTS, Linux 6.8.0-124-generic x86_64

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

Windows PowerShell using SSH to the Ubuntu workstation

Codex doctor report

Codex CLI 0.147.0 reports overallStatus “ok”; installation, authentication, provider reachability, WebSocket connectivity, databases, and bundled search all passed their diagnostic checks. The interruption therefore appears specific to the cybersecurity safety classifier rather than a local installation or connectivity failure.

What issue are you seeing?

Codex repeatedly triggered a cybersecurity safety interruption during authorized, benign, local software-assurance work.

The task involved read-only searches of controlled engineering review reports and local source files in an isolated workspace. The purpose was to locate evidence needed for a bounded internal verification campaign. No external target, unrestricted network activity, credential access, persistence, production deployment, or unauthorized security testing was involved.

The safeguard was triggered while Codex was performing read-only text searches. It occurred twice during materially similar analysis. No reproduction campaign or executable test case had started, no product source was written, and no controlled input was modified.

The exact displayed message 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 session was then left idle, with the work safely stopped.

What steps can reproduce the bug?

Uploaded thread: 019fe9e4-6347-7bd0-8ce6-ed5fa3094504

What is the expected behavior?

Codex should permit this bounded, local, read-only software-assurance analysis, or provide a more specific recoverable restriction without terminating the entire benign engineering workflow.

Additional information

Codex repeatedly triggered a cybersecurity safety interruption during authorized, benign, local software-assurance work.

Steps to reproduce:

  1. Run Codex CLI 0.147.0 on Ubuntu 22.04.4 LTS through Windows PowerShell over SSH.
  2. Use gpt-5.6-sol with max reasoning.
  3. Ask Codex to perform read-only searches within local engineering review reports and source files in an isolated workspace.
  4. Search for terms related to software process boundaries, signals, terminalization, and verification evidence.
  5. Codex displays: “This content can't be shown. We take extra caution with cybersecurity requests.”
  6. Resume the same bounded, read-only analysis.
  7. The same cybersecurity interruption occurs again.

No external system was targeted. No credentials, persistence, unrestricted network activity, production deployment, or unauthorized security testing was involved. No reproduction harness or executable test case had started, no product source was written, and no controlled input was modified.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 17 days ago

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

  • #37834
  • #36573
  • #36671
  • #36687

Powered by Codex Action

globalinkpayfounder · 40 minutes ago

I can reproduce the same false-positive safety behavior on another independent Codex session.

Environment:

  • Codex CLI 0.147.0
  • gpt-5.6-sol, high reasoning
  • ChatGPT Plus
  • Ubuntu Linux x86_64
  • VS Code integrated terminal
  • Codex doctor overallStatus: ok

My case involved an authorized defensive review of our own local software repository.

The safety interruption first appeared after a local encoding/digest correctness probe, then appeared again during ordinary read-only repository verification (git status / git rev-parse) and again during local source-code search/read operations.

No third-party target, credential access, external scanning, exploitation, malware, persistence, or unauthorized access was involved.

I uploaded the affected Codex session through /feedback.

Uploaded thread ID:
01a047a3-718c-7072-b291-ea783669f43e

This appears to confirm that the false-positive classification can persist across subsequent benign turns in the same session.