Codex Security CLI Brings Agentic Discovery and Patching to CI

Agentic security scanning moves into the terminal

OpenAI's Codex Security CLI started as a hosted security agent. The open-source package now lets developers run it locally, script it, and use it as a gate in continuous-integration pipelines. In late July 2026, OpenAI published @openai/codex-security on npm under the Apache 2.0 licence as both a command-line tool and a TypeScript SDK. Hacker News found the repository before the company had announced it.37 Several outlets put the release on 29 July. RuntimeWire dated it to 28 July and attributed it to Codex lead Thibault Sottiaux, who announced it on X.210 OpenAI's developer forum called it an early release and said the CLI and SDK are in beta and require access.1

The main point of the release is less that an AI can find bugs and more that the whole loop now runs from a command line. Discovery, validation, patching and policy enforcement each work as separate commands that other tools can call.

From Aardvark to an npm package

The CLI has a longer history than its version number suggests. OpenAI introduced Aardvark in October 2025 as a private-beta "agentic security researcher." It used a four-stage pipeline: it built a threat model of the repository, scanned commits against that model, tried to trigger suspected bugs in a sandbox, and attached a patch written with Codex for human review.11 OpenAI said Aardvark avoided traditional techniques such as fuzzing and software composition analysis. Instead it relied on model reasoning and tool use: reading code, writing and running tests, and working through a codebase the way a human researcher would.11 In benchmark tests on seeded "golden" repositories, OpenAI reported that Aardvark found 92% of known and synthetic vulnerabilities, and ten of its open-source discoveries received CVE identifiers.1113

On 6 March 2026, Aardvark was renamed Codex Security and released as a research preview through Codex web.1120 A plugin followed, adding scanning skills inside Codex, including the Codex CLI.824 The new package takes the same scanner out of those surfaces so it can run in terminals and on CI runners.310

How agentic discovery works from the command line

What separates this tool from a conventional static analyser is how it decides where to look and when to stop. In a standard run, npx @openai/codex-security scan . produces a report covering findings, severity, evidence, affected locations, coverage and remediation guidance.6 Scans can cover a whole repository, selected high-risk paths, a Git diff such as origin/main to HEAD, or the working tree before a commit.36

Deep mode is where the agent design shows. A team can assign several workers and subagents and tell the scanner to keep running discovery passes until a set number of passes turn up nothing new, with an overall cap on the number of runs.5 Discovery here is a search with a budget and a stopping rule, not a single fixed pass. The cost controls support that reading: a --max-cost flag caps spending, although requests already in flight can push the final bill slightly over the limit.6

Teams can also shape what the agent looks for. The CLI accepts architecture documents and threat models as a knowledge base, plus custom scan prompts. Practitioner guidance recommends short, factual notes on where untrusted input enters the system and which actions need authorization.610 Threat models are saved with each scan and can be exported separately.23 Daniel Vaughan's hands-on review called this threat-modelling ability "genuinely impressive."3

The tool's relationship with other AI agents is more restricted. It can register itself as an MCP server and sync its skills to agents. However, the reference documentation says MCP exposes only the read-only info command. Scans, exports, authentication, validation and patching stay CLI-only.25 OpenAI appears to want other agents to know the scanner exists without letting them trigger scans or write patches through a protocol bridge. That is a defensible choice for a tool that sends source code to remote models and can change files.

Validation: what has to be proven

Every source agrees that validation is the feature that matters. The dreaming.press analysis argued that confirming a finding before reporting it is what keeps an AI scanner usable in CI, where a flood of false positives quickly gets a check switched off.5 The sources differ on what validation actually involves.

OpenAI's cloud FAQ describes an execution-based process: the system tries to reproduce each likely issue in a clean container and marks the ones that reproduce as validated.29 In the CLI, a validate command asks the agent to test a specific candidate finding against current code.1025 A widely shared DEV Community breakdown describes something different, with validation agents applying a severity rubric through language-model reasoning, and suggests the underlying model is "likely GPT-4 or o1."4 That model guess conflicts with Vaughan's report that the scanner defaults to gpt-5.6-sol with extra-high reasoning effort.3 The DEV piece also refers to SDK functions and a star count that no other coverage confirms.47 It reads as an informed architectural sketch rather than documentation.

The most practical advice comes from the hands-on guides. Flavio Copes warns that results can vary between runs, so a finding that disappears does not prove the bug was fixed. He recommends re-validating important findings directly against the code.6 Omid Saffari makes a similar point about the cloud product: a failed validation attempt is unresolved evidence, not a cleared vulnerability.26 Validation reduces noise, but a pass or fail from a model is not proof.

Patching stays behind human review

The patching side is more conservative than the word "autonomous" suggests. The patch command uses a bundled remediation skill to generate a fix for a named finding. Since version 0.1.15, scan --patch can fix findings above a chosen severity after a full scan.25 OpenAI's documentation says patches still need human review.10 The cloud FAQ adds that the tool does not modify a PR branch directly. It produces a diff or suggested change for maintainers to inspect.29

One detail links patching to CI gating: findings that are verified as fixed or already fixed do not trigger --fail-on-severity.25 A team could therefore move from a blocking state to a passing one using the scanner's own verification. That is convenient, but it also means the gate depends on the same non-deterministic system that flagged the problem.

CI integration and the cost of trust

The CI integration itself is familiar. Scans report without blocking by default. Adding --fail-on-severity returns a non-zero exit code when a finding meets the threshold. Results export as JSON, CSV or SARIF, so they appear in code-scanning dashboards such as GitHub's.1025 The guides disagree on how hard to enforce this at first. Vaughan's example workflow blocks on high-severity findings from the start.3 Copes and Saffari both advise running in advisory mode first and only choosing a blocking threshold after triaging an initial baseline.626 Dreaming.press suggests failing a build only when a pull request introduces new findings, using scans compare against a baseline, so that existing issues in the repository do not block every change.5 Given the non-determinism reported in every hands-on account, the cautious approach looks like the right default.

Saffari's hardened GitHub Actions template shows what careful deployment involves. It pins the package version, installs the CLI outside the checkout with install scripts disabled, does not persist credentials, and skips pull requests from forks and Dependabot.26 Those steps treat the scanner as a privileged component of the supply chain, which is a sensible stance.

Open interface, closed engine

The sources agree on the central limitation: the code is open, but the analysis is not. The scanning engine runs on OpenAI's proprietary models and requires approved access, so the project is open source at the interface layer only.25 Code is processed on OpenAI's servers, and there is no offline or air-gapped mode.3 Vaughan also reports uneven language coverage.3

The success figures are inconsistent. TechPillow says the closed beta found and helped fix more than 3,000 critical vulnerabilities.2 Axios and RuntimeWire, citing OpenAI's March figures, report about 800 critical and more than 10,500 high-severity findings across external repositories, and RuntimeWire notes that these numbers come from OpenAI itself.1020 Readers should treat all of these as vendor claims.

The verdict

Codex Security's CLI is OpenAI's clearest bet that security review can become another programmable Codex task, running where coding agents already work.10 The design choices make sense: bounded discovery, explicit validation, patches that wait for review, and a deliberately limited MCP surface. Vaughan's assessment of version 0.1.1 still holds as a fair summary. The threat modelling is strong, and finding detection has not yet caught up.3 For now, the tool works best as a strong second opinion alongside deterministic SAST and human review, not as a replacement for either. Axios reports that many security leaders already expect enterprises to keep using a mix of vendors.20