Codex Security CLI: Open Client, Closed Scanner Under the Hood

What OpenAI actually released

OpenAI has published its Codex Security command-line tool under the permissive Apache 2.0 licence. The tool is an AI-driven vulnerability scanner that runs in developers' terminals and in CI/CD pipelines. One account dates the release to 29 July 2026 and says the package ships on npm as @openai/codex-security 1. DevOps.com notes that the software development kit was opened alongside the CLI 2. The Next Web reports that OpenAI put the code out quietly, before it had formally announced the tool 4.

The project has a short but visible lineage. It began as an internal effort codenamed Aardvark and became a research preview in March 2026. It then ran as an invitation-only beta, during which OpenAI says it helped identify and fix more than 3,000 critical vulnerabilities in customer codebases 13. The tool is still labelled beta. It requires Node.js 22 and Python 3.10 or newer 3. One developer write-up gives a finer version range, citing Node 22.13.0+ within the 22.x line or the 24.x and 26.x releases, plus the tomli package on Python 3.10 5.

What it does in a workflow

The feature list is practical. The CLI can:

• scan whole repositories
• review staged and unstaged changes before a commit
• compare findings across runs
• export results to other code-scanning tools

In CI, teams can set a severity threshold so that a scan fails the check when it finds an issue at or above that level 2. OpenAI advises starting in advisory mode before letting findings block merges 2. The Decoder adds that the tool can verify fixes and run bulk scans across multiple repositories 3.

The dev.to analysis focuses on architecture. It describes Codex Security as an agentic pipeline rather than a conventional rule-based static analysis (SAST) tool 5. In that account, the scan moves through four stages:

1. Parallel discovery workers comb different code paths.
2. Validation agents use LLM reasoning to weed out false positives.
3. Patch agents propose fixes.
4. Verification agents confirm the patches work 5.

The same write-up guesses that the Python dependency exists because the discovery layer relies on established tools such as Semgrep or Bandit. It hedges that claim as "likely," so it should be read as speculation, not confirmed design 5. It also cites more than 11,000 GitHub stars, a figure the other reports do not mention 5.

The asterisk on "open source"

This is where the coverage converges. The client code is public, but the engine that performs the analysis is not. The scanner runs on proprietary OpenAI models and requires approved API access 1. The Next Web puts it bluntly: the part that does the hunting is still locked behind OpenAI's approval 4. DevOps.com draws the same line, saying the openness ends at the integration layer while the analysis service stays under OpenAI's control 2. Analyst Mitch Ashley, quoted there, called the release distribution rather than openness 2.

The Decoder and dev.to pieces lean more heavily on the "open-source tool" framing and say less about the gating 35. That difference matters for readers trying to judge what they are adopting. Developers can read, fork and adapt the CLI and SDK 2. What they cannot do is run the scanner independently, audit the models making security judgements, or avoid a usage-based relationship with OpenAI.

Why OpenAI would structure it this way

The commercial logic is not hard to see. The Next Web notes that the release puts security scanning in front of Codex's roughly five million weekly users. It frames the move as an application-security land grab aimed at Anthropic's Claude Security 4. The Decoder also positions the two as direct competitors in a race to answer increasingly automated attacks with AI-powered defence 3.

In that contest, an open client is a strong distribution tool. A free, inspectable, permissively licensed wrapper lowers friction for security teams wary of black-box tooling, and it invites integration into existing pipelines. Meanwhile, the valuable and billable part stays proprietary. This is a familiar pattern in developer tooling, and it is not inherently deceptive. It is, however, a long way from what "open source" traditionally implies for security software, where independent verification is a large part of the appeal.

The takeaway

Codex Security CLI looks like a capable addition to the merge path. Agentic validation and patching, if they work as described, could cut the alert noise that has long dogged SAST tools. Teams should still evaluate it as what it is: an open-source front end to a closed, access-controlled service.

That has concrete consequences. Your code goes to OpenAI's models. Your results depend on a vendor's approval. Your CI gate is only as available as the API behind it. The licence on the wrapper changes none of that.