Repository navigation
Codex Security validation blocked on defensive review of personal repository #32597
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.707.51957
What subscription do you have?
Plus
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
I encountered what appears to be a false-positive cybersecurity block while using the Codex Security plugin on my own personal Python repository.
Prompt "@codex Security] Do a security review of this repo."
The workflow had progressed to the validation stage of a security review when Codex stopped with:
“Goal blocked: This content can’t be shown. We take extra caution with cybersecurity requests.”
This was a defensive review of code I own, not an attempt to exploit an external system.
Feedback ID: 019f53da-dcea-7e60-b758-0e9d2d732e36
Product surface: Codex desktop / Codex Security plugin
Repository type: Personal knowledge-management Python application
This appears related to #32448 and #32468 , which reports the same cybersecurity block. My case differs because it occurred while using the Codex Security plugin during the validation stage of a defensive scan on a repository I own.
What steps can reproduce the bug?
- Open a personal Python repository in the Codex desktop app.
- Run the Codex Security plugin to perform a defensive security review.
- Continue through the workflow to the validation stage.
During validation, the workflow stops with:
Goal blocked and a popup that says "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 repository is a personal knowledge-management application that I own. The block occurred during the plugin-generated validation workflow, not from a manually entered exploit request.
Feedback ID: 019f53da-dcea-7e60-b758-0e9d2d732e36
Session ID: Not available
Token/context usage: Not available
What is the expected behavior?
The Codex Security plugin should complete the defensive validation of findings in a repository owned by the user without triggering a cybersecurity safety block. If a specific validation action cannot be completed, it should identify the blocked action and provide a clear explanation rather than stopping the entire workflow with a generic message.
Additional information
No response
Activity
github-actions commentedon Jul 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Suhaibinator commentedon Jul 20, 2026
Hit this same thing on the Codex App (Version 26.715.31925, Pro) — Codex Security plugin, defensive review of a repo I own, blocked with the same message. Feedback ID
019f7d5b-9886-7023-a4ae-0db91410f22e.One addition to your report that I think is worth tracking separately: in my case the block landed after the review had run to completion, and the run had consumed roughly half a week's worth of Pro quota. The usage was spent and still counted; the output was discarded. So beyond the classifier being wrong, there's a lifecycle problem — the gate is evaluated at output time rather than before execution, which makes an expensive long-running plugin billable but not reliably usable.
Filed that angle as #34257 and referenced this issue there, since your report is the closest match. 👍'd here as well.
ericwooley-ai commentedon Jul 28, 2026
AI: I encountered the same false-positive block during a defensive Codex Security Deep Scan of a user-owned repository.
The requested focus was authentication, payments/management, and admin-only authorization. Codex Security preflight passed, but the repeated-discovery coordinator terminated with: "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."
Environment:
The failure was terminal and non-resumable. It generated no scan-manifest.json, findings.json, coverage.json, or report.md, so the security review could not return even partial results.
Expected behavior: defensive scans should complete without triggering this false positive. If one operation must be blocked, the workflow should isolate that operation, preserve resumable progress, expose a request/feedback ID, and retain already-produced defensive findings instead of terminating the entire scan.
matthewprotti commentedon Jul 29, 2026
Same issue here with the first-party Codex Security plugin performing an authorized, read-only review of a private repository owned by my organization.
Environment: Codex App
26.721.81911, macOS arm64, modelgpt-5.6-sol, Pro account. The workflow completed preflight, threat modelling, and discovery, then marked the entire goal blocked as it entered validation with the same “This content can’t be shown” / Trusted Access message.No external target, live system, production data, real credential, deployment, or repository setting was accessed or changed.
The expected behaviour is to complete the scan, or isolate a specifically unsupported operation without terminating the entire goal.
Feedback ID:
019fab65-8b11-7e71-9f11-bec403e2e37bMcLuck commentedon Jul 31, 2026
Additional reproduction on Codex Desktop 26.727.40816 (build 6067), macOS 26.5.2 arm64, using the Codex Security Deep Scan workflow on an authorized, locally owned aggregate source workspace.
The scan passed the
deep_security_scanpreflight with statusreadyand no unmet, unknown, or warning capabilities. It then ran the plugin-owned discovery phase for roughly 52 minutes before terminating with:The preserved coordinator failure manifest reports:
workflowVersion: deep-scan-mcp/v1schemaVersion: 1status: failedfailure.phase: discoveryfailure.kind: ErrorThe user-supplied context was explicitly defensive and bounded: communication/reporting in PT-BR, scan the complete local aggregate workspace including child repositories, and do not modify source code.
Impact: the classifier discards a long-running defensive discovery run as a terminal logical scan. This version cannot resume the persisted coordinator, so the user loses the completed runtime and must either start over or enroll in Trusted Access. The plugin should recognize its own authorized defensive scan workflow, or at minimum preserve resumable discovery progress when a single worker/output is blocked.
88250 commentedon Sep 4, 2026
I encountered the same false-positive cybersecurity block while asking Codex to perform a defensive analysis of a private security advisory for a repository I maintain. The active GitHub CLI session was authenticated with ADMIN permission for that repository, and no external system was being tested. Feedback was uploaded successfully. Thread ID: 01a06a29-c270-7fe0-a4d3-4443b0645c6c. Please use the uploaded thread for the full private context because the advisory itself is not public.