Codex Security CLI is here: How to find vulnerabilities and verify that fixes work
OpenAI has released Codex Security CLI, a tool that finds vulnerabilities in code, validates whether the findings are real, and checks whether a fix actually worked. In addition to security scans from the Codex interface, it can scan repositories from a terminal, compare findings across runs, and add security checks to CI/CD.
This article explains how Codex Security CLI differs from a regular code review, how to try it on a local repository, and what to keep in mind when fixing a finding. The information is current as of July 29, 2026.
Here are the announcements behind this article
The release was shared by Tibo from the Codex team and by the official OpenAI account.
- The Codex team introduces the CLI and TypeScript SDK
- OpenAI announces Codex Security CLI
- Codex Security CLI quickstart (OpenAI)
- openai/codex-security on GitHub
Codex Security CLI does more than list vulnerabilities
When people hear “security check,” they often picture a tool that mechanically flags suspicious code. Codex Security reads the repository, checks whether a possible vulnerability is worth reporting, and gathers the evidence and remediation guidance in one workflow.
According to OpenAI’s documentation, scan results can include evidence showing the conditions under which the issue occurs, reproduction steps when available, and a suggested direction for the fix. Instead of simply saying “this line is dangerous,” the result helps you follow how an input travels through the code and why it could be exploited.
After a patch is created, Codex Security can also verify whether the same issue can still be reproduced. In other words, it follows the process of finding a problem, fixing it, and checking the fix.
Basic setup from Codex CLI
The CLI and SDK are in beta and require access. If you have access, follow the installation instructions provided by OpenAI. The CLI requires Node.js 22 or later, while running scans and exporting results requires Python 3.10 or later.
- Choose the repository to scan and a private directory outside the repository for the results
- Run
npx codex-security --versionandnpx codex-security --helpto verify the installation - Sign in with
npx codex-security login(automated CI runs can use an API key) - Run
npx codex-security scan /path/to/repository --output-dir /path/to/results - After it finishes, review
report.mdand the structured result files
Before starting a full scan, you can use --dry-run to check the target and output directory. Results may include source excerpts and detailed vulnerability information, so use a private location outside Git and decide how long the results should be retained.
You can also use the Codex Security plugin from Codex CLI. Open the repository with codex, install Codex Security from /plugins, and start a new chat. Then use a prompt like this:
Run a Codex Security scan on this repository.
For scan quality, the official documentation recommends gpt-5.6-sol with xhigh reasoning. Available models and access requirements vary by account, so check the options shown in your environment.
Read report.md, then judge each finding
The output directory contains report.md, the main human-readable result. It also includes findings.json, which records severity, confidence, locations, evidence, and remediation, and coverage.json, which records reviewed surfaces and deferred work.
Do not decide that a repository is safe based only on the number of findings. Check whether coverage is partial or unknown, and read any deferred areas or open questions. A completed scan does not necessarily mean that every part of the repository was examined at the same depth.
Review the diff before applying a fix, then verify it
When a problem is found, accept findings one at a time and inspect the proposed diff instead of applying everything automatically. Codex Security provides a workflow for verifying whether the vulnerability can still be reproduced after the change.
Verification may rerun the reproducer or add a focused regression test that fails before the fix and passes after it. If a safe test is not possible, the system records why verification could not be completed and what repeatable evidence was used instead. Verification does not automatically close a finding, so a human should review the diff and test results before closing it.
It is safer to separate scanning from remediation. For a scan-only task, explicitly ask Codex not to modify the checkout. Make fixes on a working branch. If you automate remediation from CI, keep each finding as a separate task and merge only after review.
How it differs from regular reviews and Claude Security
A regular Codex code review, such as /review for the current changes, is useful for quickly checking bugs and design concerns in a working diff. Codex Security CLI is designed to inspect a whole repository or selected paths for vulnerabilities while preserving evidence, coverage, and post-fix verification.
Claude Security has a similar goal: finding vulnerabilities, checking the evidence, and helping with remediation. The supported environments, output formats, models, and access requirements are different. If Claude Code is central to your workflow, Claude Security may fit naturally; if you already work through Codex CLI and GitHub, Codex Security CLI may be the more practical choice. If you try both on the same repository, compare duplicate or conflicting findings and make the final decision yourself.
Would it be useful for the AI Jiten production environment?
AI Jiten is built by editing a WordPress theme and custom plugins locally, with changes managed in Git. In this setup, Codex Security CLI is worth trying before a major release or after adding authentication, file operations, or external API calls.
Start with a pre-release branch, run a standard scan, and review report.md together with its coverage. If a problem is found, review the diff on a fix branch and merge only after verification passes. Avoid scanning a production checkout or files containing secrets such as wp-config.php and API keys. When necessary, prepare a working copy with secrets removed.
A full scan is not necessary for every change. Use a repository-wide scan before a release, and use a diff scan such as --diff origin/main --head HEAD or --working-tree --base HEAD for routine changes. The CLI also provides install-hook if you want to add a Git pre-commit check.
“The AI found it” does not mean “the code is safe”
Codex Security CLI is useful, but a scan is not a security guarantee. False positives, missed issues, and unreviewed areas can remain. Be especially careful when a command may perform a risky operation or when enabling access to external networks.
Having AI find a problem and accepting a change made by AI are separate decisions. Confirm that you own the code or have permission to assess it, then review the evidence, diff, tests, and coverage before moving toward a release.
Summary
Codex Security CLI is a security-focused CLI that can look for vulnerabilities, validate the evidence, and track whether an issue is gone after a fix. It is still in beta and requires access, but it could complement regular code review for people who develop with Codex.
A good first step is to try it on a small repository you own, using a separate private output directory. Learning how to read the results will make it easier to move toward CI/CD later without relying only on the number of findings.