Defensive vulnerability-writeup workers trigger repeated cybersecurity false positive
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
- Run a bounded Codex Security diff review against a local source checkout.
- Validate a state-machine availability defect with a deterministic simulator
unit test.
- Ask a dedicated worker to write one defensive report from the local source,
failing test, fixing diff, and remediation guidance.
- Explicitly prohibit live targets and physical-device activity.
- 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional recurrence on 2026-07-20 in Codex Desktop: a fresh independent sub-agent was asked to perform a read-only review of a bounded local software change. The prompt explicitly prohibited edits, live effects, external LLM/API use, and requested ordinary regression tests plus review of filesystem crash-safety and validation-contract compliance. The sub-agent terminated with the exact Trusted Access / possible cybersecurity risk message before returning any review.
This was normal defensive software-quality work on local controller state handling, not vulnerability exploitation, scanning, credential access, persistence, evasion, malware, or third-party activity. The parent task remained usable and its tests remained green, but a required independent review gate was lost and had to be retried. This recurrence suggests the false positive is not limited to vulnerability report writing; terms around safe files, atomic writes, and fail-closed state validation may also trigger it. No request/correlation ID was exposed in the child result.
Recurrence: completed artifact was visible from the subagent resource but hidden in the parent chat
I reproduced this again on August 10, 2026, using Codex Desktop 26.803.41515 (bundled CLI 0.147.0-alpha.6.5) on macOS 27.0.
The task was to draft a Markdown report about security advisories I had already filed on an open-source project. It involved no live target, credential access, exploitation, or external write.
Observed sequence:
The report was generated and persisted successfully, but the parent return path did not display it consistently. That matches this issue's earlier observation that a defensive writer can produce local artifacts and then be blocked while returning its completion response.
This appears related to #34945 and #36671, but the strongest evidence here is the side-by-side inconsistency within one task: the subagent resource displayed the full report while the parent chat hid it.