Codex Security plugin: cybersecurity filter blocks output *after* the full run, consuming quota with no result
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.715.31925 (released Jul 17, 2026)
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
I ran the Codex Security plugin against my own repository to find security-related bugs. The task ran to completion and consumed roughly half a week's worth of Pro usage. At the end, instead of the review results, I got:
This content can't be shown We take extra caution with cybersecurity requests.
The run was allowed to start, allowed to consume a large amount of quota, and then the entire deliverable was withheld at output time.
Feedback ID: 019f7d5b-9886-7023-a4ae-0db91410f22e
Why I'm filing this separately from the existing false-positive reports.
The classifier false-positive is already well documented — #32597, #32468, #34151, #33810, #32448, #33305, and others. I'm not re-reporting that. I'm reporting the part none of those cover: the block lands after the usage is spent, and the usage still counts against the plan.
#32597 is the closest match (also the Codex Security plugin, also a defensive review of a repo the reporter owns), but it stops at "the review was blocked." The additional failure here is economic:
- The filter fires at the wrong point in the lifecycle. If cybersecurity content is going to be gated, that decision should happen before the run starts — not after an expensive long-running agentic review has completed and been billed. As it stands, the plugin is billable but not reliably usable.
- The cost is non-trivial and unpredictable. A full security review is expensive by design. Losing half a weekly Pro quota to a run whose output is discarded is a materially different problem from a chat turn getting blocked, and it makes the plugin hard to use with any confidence — there's no way to know in advance whether you'll be permitted to see what you paid for.
- The plugin's own successful output is what trips the filter. This is a first-party security plugin, run by the repository owner, on their own codebase, for defensive purposes. Its normal output is inherently full of vulnerability language — i.e. exactly what the classifier is trained to block. That makes this a near-guaranteed failure mode for the feature rather than an edge case.
This is the documented, intended use case of the feature.
Per the official docs at https://learn.chatgpt.com/docs/security/plugin, the Codex Security plugin is built to "scan your code for vulnerabilities, validate plausible findings, and present evidence and remediation guidance in a reviewable workspace," and the documentation instructs:
Use it to find security issues in code you own or have authorization to assess before they reach production.
That is precisely and exactly what I did — read-only scan, local repo opened in Codex, code I own, pre-production. I followed the quickstart as written. There is no interpretation of my usage under which I was doing something the product didn't tell me to do.
So the position the product currently takes is: ship a security scanner, document the supported workflow, let the user run that documented workflow to completion, bill them a substantial share of their weekly quota for it — and then refuse to show the output on the grounds that it's a cybersecurity request. It is a cybersecurity request. That's the feature. If the intended use case is not permitted to return its results, the feature should not be shipped in its current form, and it certainly should not be charging for runs it won't deliver.
What steps can reproduce the bug?
- Open a repository in the Codex App (Version 26.715.31925).
- Run the Codex Security plugin over the repo, asking it to find security-related bugs.
- Let the task run to completion. In my case this consumed roughly half of a weekly Pro quota.
- Observe that the final response is replaced with the "This content can't be shown / We take extra caution with cybersecurity requests" message rather than the review findings — and that the consumed usage is not returned.
Feedback ID for the affected run: 019f7d5b-9886-7023-a4ae-0db91410f22e
What is the expected behavior?
In priority order:
- The Codex Security plugin's output should not be blocked when it is executing its own documented workflow — a read-only scan of a repo the user owns and has open, which is verbatim what https://learn.chatgpt.com/docs/security/plugin instructs users to do. Whatever allowance the plugin needs so its own results clear the filter, it should have. (This is the ask shared with #32597 / #32468.)
- If a request is going to be refused on cybersecurity grounds, refuse it before execution, not after. A pre-flight decision costs the user nothing; a post-hoc one costs them the entire run.
- Usage spent on a run whose output is withheld should not count against the plan quota. If the product decides after the fact that it won't show me the result, I shouldn't be paying for it.
- Surface why the content was blocked, and whether partial results can be retrieved. Discarding the whole run with no detail leaves nothing actionable — not even enough to know which part of the review triggered it.
Additional information
Related open issues on the underlying classifier false-positive (this issue is about the lifecycle/billing consequence, not a duplicate of these):
- #32597 — Codex Security plugin blocked during defensive review of a personal repo (closest match)
- #32468 — false-positive guard repeatedly hiding authorized defensive local-repo work
- #34151 — content blocked by the same message
- #32448 — defensive security remediation triggered cybersecurity restriction
- #33810, #33305, #33766, #33302 — further false positives across unrelated legitimate use cases
The volume of these suggests the classifier threshold is a known problem. My point is narrower and, I think, independently fixable: whatever the classifier does, it shouldn't be possible to spend half a week's quota on a result the product then refuses to hand over.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗