OpenAI has published the source for Codex Security’s command-line interface and TypeScript SDK under the Apache 2.0 license, turning what was previously a web- and plugin-led application-security service into a tool developers can inspect, automate, and run against local working trees or CI jobs. The important qualification is that this is an open-source client and workflow layer, not an open release of the Aardvark security model or a free, self-contained vulnerability scanner.
The distinction corrects the broadest reading of reports that OpenAI had “open-sourced Aardvark.” Aardvark was the former name of the security agent OpenAI announced in private beta in October 2025 and relaunched as Codex Security in research preview on March 6, 2026. OpenAI’s new public repository exposes the CLI, SDK, scan orchestration, report handling, CI hooks, and provider integrations; scans still require Codex Security access and generally invoke a hosted model provider.
For Windows developers, this is a meaningful change. The published package documents a native PowerShell workflow using Node.js 22 or later and Python 3.10 or later, with a repository path such as
OpenAI’s March launch positioned Codex Security as an application-security agent that builds a project-specific threat model, hunts for realistic attack paths, attempts to validate findings in an isolated environment, and proposes minimal patches for human review. Axios and TechRadar independently described that earlier research-preview service as an evolution of Aardvark, not as an open-source release.
The newly published
But OpenAI’s own documentation says plainly that the public package requires “access to Codex Security” to run scans. The default documented model is OpenAI’s GPT-5.6 Sol with xhigh reasoning effort. Neither the model weights nor the hosted validation infrastructure have been released under Apache 2.0. Calling the tool “open source” is accurate for its client code; calling its underlying security intelligence open source is not.
That separation has a practical consequence for procurement and reproducibility. An organization can audit how the CLI stores artifacts, handles credentials, invokes a scan, and creates CI results. It cannot independently run the exact default model stack on its own infrastructure, reproduce OpenAI’s hosted behavior indefinitely, or avoid provider access simply by cloning the repository.
That should be treated as a safeguard, not as a missing feature. A model that can infer business logic and write a fix can also make a security finding disappear by breaking a legitimate path, weakening a feature, or changing authorization behavior that was deliberately unusual. OpenAI itself recommends that teams review generated patch pull requests through their normal review process and even suggests running Codex Code Review on remediation produced by Codex Security.
The CLI’s output design exposes another detail that matters in real operations: a clean-looking report is not necessarily a complete review. Each scan saves a coverage record alongside its findings. Coverage can be marked complete, partial, or unknown, and the report records excluded surfaces, deferred work, and open questions. In CI, incomplete coverage and runtime errors use a different failure result from a completed scan that finds high-severity issues, so they are not meant to be mistaken for a passed security policy.
Teams should preserve that distinction when wiring the tool into build gates. A reasonable first deployment is a report-only scan on pull-request diffs, followed by a failed build only for validated high-severity findings after the team has measured noise and runtime. Enabling the provided pre-commit hook immediately is more aggressive: it scans staged and unstaged changes and can block commits on high-severity findings or scan failures.
This means the scanner’s method is becoming more portable than its original Aardvark service. A team can use the open-source scan workflow with a model selected for cost, availability, policy, or performance, rather than accepting OpenAI’s default. The tool also includes a scan-cost limit, enabling a job to stop after estimated inference cost exceeds a chosen dollar threshold.
However, the specific claim that DeepSeek is a supported, cost-effective Codex Security option is not documented by OpenAI’s repository or current CLI documentation. The OpenRouter integration accepts a provider and a supported model identifier, so a DeepSeek model may be usable if OpenRouter makes that model available in a compatible form. That is not the same as OpenAI having validated it for vulnerability discovery, proof-of-concept generation, or patch quality.
The provider choice also changes the data-handling decision. Codex Security’s own documentation warns that scan outputs can include source excerpts, vulnerability details, and reproduction steps, and recommends keeping result directories outside the repository with access limited to authorized reviewers. When inference is directed through OpenRouter or another provider, the analysis request is also being sent through that selected provider’s service rather than solely to OpenAI. Security teams should review the provider’s retention, regional processing, subcontractor, and training-use terms before scanning proprietary code, credentials-adjacent configuration, incident evidence, or regulated data.
Open source has made the local runner more inspectable; it has not erased the need to decide where sensitive application context goes.
The prerequisites remain significant for managed endpoints: Node.js 22 or newer, Python 3.10 or newer, access credentials, and a writeable private directory for scan state and reports. The scanner’s output directory must sit outside the repository and any enclosing Git worktree. This prevents scan artifacts from being accidentally committed, but it leaves IT administrators responsible for ensuring those results directories are encrypted, retained appropriately, excluded from ordinary synchronization if needed, and visible only to the developers and security staff who need them.
OpenAI says environment-provided API keys used in CI are passed directly to the scan and are not stored in the Codex credential home or system keyring. That is useful, but it does not remove conventional secret-management requirements. A CI job needs a restricted service credential, repository access must be scoped narrowly, and exported SARIF or JSON results need the same access controls as source code because they may contain line-level evidence and attack paths.
The release also includes Docker-based bulk scanning and optional Ubuntu AppArmor hardening. That may be attractive for centralized security teams, but Windows shops should not confuse containerization with isolation sufficient for every repository. A scanner that reads source, runs validators, and processes build-oriented files still deserves a dedicated worker, least-privilege credentials, and a controlled network policy.
That does not end the era of unprotected products. It gives teams a more capable and inspectable layer for finding application flaws earlier, especially authorization mistakes, risky data flows, and multi-file defects that simplistic pattern scanning can miss. It cannot see infrastructure drift, misconfigured CDN rules, exposed cloud permissions, production secrets outside the repository, or a DDoS response plan.
The immediate operational move is to treat Codex Security as a new review signal rather than an autonomous security authority: pilot it on a low-risk Windows repository, keep result artifacts private, compare its findings with existing SAST and code review, and require human approval for every patch. The code is now open; the accountability for what gets merged remains with the team that ships it.
For Windows developers, this is a meaningful change. The published package documents a native PowerShell workflow using Node.js 22 or later and Python 3.10 or later, with a repository path such as
C:\code\repository. That is a much more practical route for teams that want security review close to their local Git workflow instead of granting a cloud service standing access to every repository.
The open-source release is a client, not the security engine
OpenAI’s March launch positioned Codex Security as an application-security agent that builds a project-specific threat model, hunts for realistic attack paths, attempts to validate findings in an isolated environment, and proposes minimal patches for human review. Axios and TechRadar independently described that earlier research-preview service as an evolution of Aardvark, not as an open-source release.The newly published
@openai/codex-security package changes the delivery model. Its repository includes the command-line interface, a TypeScript SDK, Docker and Docker Compose materials, report formats, scan history support, and configuration for deep scans. The package can scan an entire repository, selected paths, a committed diff, or the uncommitted working tree. It can also export findings to JSON, CSV, and SARIF, the format that can feed GitHub code-scanning views and other security tooling.But OpenAI’s own documentation says plainly that the public package requires “access to Codex Security” to run scans. The default documented model is OpenAI’s GPT-5.6 Sol with xhigh reasoning effort. Neither the model weights nor the hosted validation infrastructure have been released under Apache 2.0. Calling the tool “open source” is accurate for its client code; calling its underlying security intelligence open source is not.
That separation has a practical consequence for procurement and reproducibility. An organization can audit how the CLI stores artifacts, handles credentials, invokes a scan, and creates CI results. It cannot independently run the exact default model stack on its own infrastructure, reproduce OpenAI’s hosted behavior indefinitely, or avoid provider access simply by cloning the repository.
The workflow is built for code review, not automatic remediation
Codex Security’s strongest design choice is also a constraint: it is report-only by default. It can generate a patch proposal and provide validation evidence, but it does not silently modify source code. OpenAI’s Codex Security help documentation says the proposed patch must be reviewed and may then be turned into a pull request.That should be treated as a safeguard, not as a missing feature. A model that can infer business logic and write a fix can also make a security finding disappear by breaking a legitimate path, weakening a feature, or changing authorization behavior that was deliberately unusual. OpenAI itself recommends that teams review generated patch pull requests through their normal review process and even suggests running Codex Code Review on remediation produced by Codex Security.
The CLI’s output design exposes another detail that matters in real operations: a clean-looking report is not necessarily a complete review. Each scan saves a coverage record alongside its findings. Coverage can be marked complete, partial, or unknown, and the report records excluded surfaces, deferred work, and open questions. In CI, incomplete coverage and runtime errors use a different failure result from a completed scan that finds high-severity issues, so they are not meant to be mistaken for a passed security policy.
Teams should preserve that distinction when wiring the tool into build gates. A reasonable first deployment is a report-only scan on pull-request diffs, followed by a failed build only for validated high-severity findings after the team has measured noise and runtime. Enabling the provided pre-commit hook immediately is more aggressive: it scans staged and unstaged changes and can block commits on high-severity findings or scan failures.
Third-party models widen choice—and the code-sharing boundary
The published SDK confirms a claim in the submitted report that was not available in OpenAI’s March announcement: Codex Security now supports inference through OpenRouter, Fireworks AI, and Amazon Bedrock, in addition to ChatGPT and OpenAI API authentication. The OpenRouter example in OpenAI’s repository uses Anthropic’s Claude Sonnet 4.5; Fireworks is shown with a Qwen model; Bedrock is shown with an OpenAI-hosted model.This means the scanner’s method is becoming more portable than its original Aardvark service. A team can use the open-source scan workflow with a model selected for cost, availability, policy, or performance, rather than accepting OpenAI’s default. The tool also includes a scan-cost limit, enabling a job to stop after estimated inference cost exceeds a chosen dollar threshold.
However, the specific claim that DeepSeek is a supported, cost-effective Codex Security option is not documented by OpenAI’s repository or current CLI documentation. The OpenRouter integration accepts a provider and a supported model identifier, so a DeepSeek model may be usable if OpenRouter makes that model available in a compatible form. That is not the same as OpenAI having validated it for vulnerability discovery, proof-of-concept generation, or patch quality.
The provider choice also changes the data-handling decision. Codex Security’s own documentation warns that scan outputs can include source excerpts, vulnerability details, and reproduction steps, and recommends keeping result directories outside the repository with access limited to authorized reviewers. When inference is directed through OpenRouter or another provider, the analysis request is also being sent through that selected provider’s service rather than solely to OpenAI. Security teams should review the provider’s retention, regional processing, subcontractor, and training-use terms before scanning proprietary code, credentials-adjacent configuration, incident evidence, or regulated data.
Open source has made the local runner more inspectable; it has not erased the need to decide where sensitive application context goes.
Windows support is now explicit, but endpoint hygiene still applies
The npm package lists Windows support, and OpenAI’s TypeScript SDK documentation provides a PowerShell example for setting an API key and scanning a local repository. That is a stronger position than treating Windows as an experimental afterthought behind WSL.The prerequisites remain significant for managed endpoints: Node.js 22 or newer, Python 3.10 or newer, access credentials, and a writeable private directory for scan state and reports. The scanner’s output directory must sit outside the repository and any enclosing Git worktree. This prevents scan artifacts from being accidentally committed, but it leaves IT administrators responsible for ensuring those results directories are encrypted, retained appropriately, excluded from ordinary synchronization if needed, and visible only to the developers and security staff who need them.
OpenAI says environment-provided API keys used in CI are passed directly to the scan and are not stored in the Codex credential home or system keyring. That is useful, but it does not remove conventional secret-management requirements. A CI job needs a restricted service credential, repository access must be scoped narrowly, and exported SARIF or JSON results need the same access controls as source code because they may contain line-level evidence and attack paths.
The release also includes Docker-based bulk scanning and optional Ubuntu AppArmor hardening. That may be attractive for centralized security teams, but Windows shops should not confuse containerization with isolation sufficient for every repository. A scanner that reads source, runs validators, and processes build-oriented files still deserves a dedicated worker, least-privilege credentials, and a controlled network policy.
A security reviewer can now be part of the build, not a separate portal
OpenAI’s March research preview was primarily a service that connected directly to GitHub repositories and worked through Codex web. The public CLI and SDK bring the same broad workflow nearer to where Windows developers and CI systems already operate: in a checked-out repository, on a diff before merge, or in a controlled bulk scan.That does not end the era of unprotected products. It gives teams a more capable and inspectable layer for finding application flaws earlier, especially authorization mistakes, risky data flows, and multi-file defects that simplistic pattern scanning can miss. It cannot see infrastructure drift, misconfigured CDN rules, exposed cloud permissions, production secrets outside the repository, or a DDoS response plan.
The immediate operational move is to treat Codex Security as a new review signal rather than an autonomous security authority: pilot it on a low-risk Windows repository, keep result artifacts private, compare its findings with existing SAST and code review, and require human approval for every patch. The code is now open; the accountability for what gets merged remains with the team that ships it.
References
- Primary source: AIBase
Published: 2026-08-06T03:10:30.453486
Loading…
news.aibase.com - Related coverage: github.com
Loading…
github.com - Related coverage: help.openai.com
Codex Security | OpenAI Help Center
help.openai.com
- Related coverage: openai.com
Loading…
openai.com - Related coverage: github.com
Loading…
github.com - Related coverage: openai.com
Loading…
openai.com - Related coverage: cdn.openai.com
- Related coverage: ipa.go.jp
Loading…
www.ipa.go.jp - Related coverage: lockllm.com
Loading…
www.lockllm.com - Related coverage: unmasked.goodfriends.workers.dev
Loading…
unmasked.goodfriends.workers.dev - Related coverage: codex.danielvaughan.com
Loading…
codex.danielvaughan.com - Related coverage: cdn.openai.com
- Related coverage: codex.danielvaughan.com
Loading…
codex.danielvaughan.com - Related coverage: d17th0s7i8wl11.cloudfront.net
Loading…
d17th0s7i8wl11.cloudfront.net - Related coverage: axios.com
Loading…
www.axios.com - Related coverage: techradar.com
Loading…
www.techradar.com - Related coverage: techradar.com
OpenAI Codex tool with over 29,000 downloads linked to malicious npm supply chain attack stealing authentication tokens | TechRadar
A tool started benign and turned sour after a little whilewww.techradar.com - Related coverage: itpro.com
Big tech is clamping down on open source ‘AI slop’ reports | IT Pro
Firms including Microsoft, OpenAI, and Google have pledged funding to bolster open source security and cut down on AI slop reports.www.itpro.com - Related coverage: itpro.com
Loading…
www.itpro.com - Related coverage: help.openai.com
Loading…
help.openai.com - Related coverage: npmjs.com
Loading…
www.npmjs.com - Related coverage: developers.openai.com
Loading…
developers.openai.com - Related coverage: deepwiki.com
Loading…
deepwiki.com - Related coverage: developers.openai.com
Loading…
developers.openai.com