Defensive vulnerability-writeup workers trigger repeated cybersecurity false positive

Open 💬 3 comments Opened Jul 19, 2026 by ElliottWW

What happened

Codex Desktop repeatedly blocked a dedicated report-writing worker during an
authorized, defensive review of a local iOS application's authentication state
machine. The task was to turn an already validated, fail-closed availability
finding into a source-backed remediation report. It did not request access to a
live target, credentials, persistence, exploitation, evasion, malware, or data
exfiltration.

The exact surfaced message was:

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber

One finding's writer was retried with a narrower prompt and received the same
block. A second defensive writer produced local artifacts but was blocked when
returning its completion response.

Reproduction shape

  1. Run a bounded Codex Security diff review against a local source checkout.
  2. Validate a state-machine availability defect with a deterministic simulator

unit test.

  1. Ask a dedicated worker to write one defensive report from the local source,

failing test, fixing diff, and remediation guidance.

  1. Explicitly prohibit live targets and physical-device activity.
  2. Observe the cybersecurity-risk block above.

The finding involved a locally mocked Apple App Attest lifecycle: an interrupted
assertion left a challenge-bound candidate unable to recover when a later
legitimate operation used a new challenge. The requested report emphasized
fail-closed behavior, bounded recovery, digest-only retirement metadata, and
regression testing. This context appears defensive and authorized.

Expected behavior

The worker should be allowed to prepare the defensive report, or the product
should expose which portion triggered the check so it can be narrowed without
losing the required source and remediation context. If the block remains, the
response should expose a request ID suitable for support escalation.

Why this matters

The block did not prevent the underlying fix or tests, but it broke the
one-finding/one-writer reporting workflow and forced an explicitly authorized
manual fallback. This can leave an otherwise completed security review without
its expected standalone audit artifact.

Environment

  • Product: Codex Desktop
  • App version: 26.715.31925
  • Codex CLI bundled environment: 0.145.0-alpha.18
  • macOS: 27.0 (26A5378n)
  • Date/time: July 19, 2026, approximately 12:30-12:55 PM PDT
  • Request ID: none surfaced

No proprietary source, secrets, account identifiers, device identifiers, or
customer data are included in this report.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗