Repository navigation
Defensive vulnerability-writeup workers trigger repeated cybersecurity false positive #34231
Description
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.
Activity
github-actions commentedon Jul 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ksander27b commentedon Jul 20, 2026
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.
TyceHerrman commentedon Aug 10, 2026
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.
MateusOAlves commentedon Oct 5, 2026
IGNORE_THIS_RESEARCH_PROBE
MateusOAlves commentedon Oct 5, 2026
Correction: the immediately preceding comment was posted accidentally during local tooling validation and is unrelated to this issue. Please disregard it.
MateusOAlves commentedon Oct 5, 2026
Additional observation: users report the surfaced message can read, “This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. Some cybersecurity requests are still limited, even when Daybreak is on.” This appears consistent with a product-level moderation result rather than an assistant-authored refusal.
MateusOAlves commentedon Oct 5, 2026
For diagnosis, the key distinction is whether the warning appears as a normal assistant message in the transcript/event stream or as a client error/card without an assistant output item. Capturing that provenance would determine post-model refusal versus pre/post-generation product moderation.
MateusOAlves commentedon Oct 5, 2026
Suggested reproducibility fields: Codex client version, model, Daybreak toggle state, cyber verification status, request ID, timestamp/timezone, whether a response event was streamed, whether warning rendered as assistant content vs UI card, and a minimally sensitive prompt reproduction.
MateusOAlves commentedon Oct 5, 2026
Could maintainers clarify the supported remediation path for verified cyber users when this product-level warning fires under Daybreak—e.g., diagnostics bundle, appeal/feedback channel, account entitlement refresh, or false-positive report metadata? System/model instruction changes do not appear relevant when no assistant output item is produced.