Codex Security CLI Goes Open Source, but the Scanner Stays Closed

OpenAI has published the command-line interface and software development kit for Codex Security, its AI-driven vulnerability scanner, under the Apache 2.0 license 12. The release lets developers wire AI security review directly into commits and CI pipelines. The actual analysis, however, still runs on OpenAI's hosted models. That split between open client and closed engine shapes how teams should evaluate the tool.

What OpenAI Released

The CLI can scan whole repositories, review staged and unstaged changes before a commit, compare findings across scans, and export results to other code-scanning tools 1. The Decoder adds that it can verify fixes and run bulk scans across multiple repositories 2. In CI, teams can set a severity threshold so that a completed scan fails the check when it finds an issue at or above that level. OpenAI recommends starting in advisory mode before letting findings block merges 1.

The tool is in beta, installs via npm, and requires both Node.js 22 and Python 3.10 or later 2. A more detailed breakdown lists support for Node.js 22.13.0+ within the 22.x line, or 24.x and 26.x. It also notes that Python 3.10 needs the tomli package for TOML parsing 4. One writer guesses that the dual runtime exists because the discovery layer leans on Python-based security tools, possibly Semgrep or Bandit. That is an inference, not something OpenAI has confirmed 4.

Codex Security grew out of an internal project called "Aardvark." According to OpenAI, it has already helped fix more than 3,000 critical security flaws 2. The repository drew attention quickly, with write-ups citing roughly 10,000 to 11,000 GitHub stars 34.

How It Differs From Traditional Scanners

The pitch is that Codex Security reasons about code rather than matching patterns. One reviewer says it follows data flow across files, considers what an application is meant to do, and asks whether a vulnerable path is actually reachable by an attacker. It also tries to argue itself out of a finding before reporting it 3.

A dev.to analysis describes the architecture as a multi-stage agent pipeline [4]:

• Parallel discovery workers spread across code paths.
• Validation agents filter out false positives.
• Patch agents generate fixes.
• Verification agents confirm those fixes work.

If that design holds up in practice, it targets the main complaint about conventional static analysis: noisy alerts that developers learn to ignore.

The timing makes sense. AI coding assistants have sharply increased how much code teams merge, often beyond what humans can carefully review 3. The release also comes amid open competition with Anthropic's Claude Security, as AI vendors try to pair automated defense with increasingly automated attacks 2.

The Open-Source Asterisk

The sources agree on the facts but frame them differently. The Decoder and the dev.to piece present the release mainly as an open-source developer tool 24. DevOps.com and the andrew.ooo review focus on where the openness ends.

Public client code means teams can inspect the CLI and SDK and adapt them to their own tooling. The service that performs the analysis remains under OpenAI's control 1. Mitch Ashley, quoted by DevOps.com, put it bluntly: OpenAI "open-sourced the client and kept the scanner," which he called distribution rather than openness 1.

This has practical consequences. Source code is sent to a hosted model, and OpenAI does not officially support any local-inference option at present 3. Organizations with strict data-residency or IP rules will need to decide whether shipping proprietary code to an outside service is acceptable. Being able to audit the CLI does not settle that question.

Cost Is the Other Catch

Cost may be the more immediate problem. The andrew.ooo review reports that one user's scan of a small repository used up half of their weekly ChatGPT Pro allowance and then crashed 3. That is a single anecdote, not a benchmark. Still, it points to a structural issue: agentic pipelines that spawn parallel workers and repeated validation passes use far more tokens than a rules engine running locally.

This cuts against the CI use case OpenAI is promoting. A scanner that runs on every pull request has to be predictable in both speed and price. OpenAI's advice to start with advisory results 1 is sensible, and it also gives teams a low-risk period to measure real consumption before making scans mandatory.

The Takeaway

In our reading, this release is mainly a distribution play. OpenAI has made it easier to put its hosted security model into everyday developer workflows, which matters as AI-generated code outpaces human review. The reasoning-based approach and the reported track record of fixes are real advantages over pattern-matching tools.

Teams should not treat the Apache 2.0 license as a sign of independence, though. Before adopting the tool in CI, they should answer three questions:

• Can our code legally and contractually leave our environment?
• What does a realistic scan cadence cost?
• How stable is the beta under load?

The open client makes integration easy. Whether the closed engine underneath is affordable and compliant is a separate decision.