Version 0.2.0 turns model review into durable scan artifacts
Codex Security v0.2.0 can scan a repository, selected paths, a committed diff, or working-tree changes. It records findings, coverage, and a manifest, then exports formats such as SARIF, JSON, and CSV. Deep mode adds parallel discovery workers. The result is more useful than a chat transcript because a team can see which surfaces were reviewed, which work was deferred, and what evidence supports each reported vulnerability.
The tool also validates findings, drafts patches, verifies fixes, creates security-policy drafts, and saves threat models. Existing GitHub code-scanning alerts can enter the same review flow. A TypeScript SDK exposes scans and callbacks for applications, while GitHub Actions, Docker Compose, and bulk CSV campaigns cover automation. The README supports OpenAI, Amazon Bedrock, OpenRouter, and Fireworks credentials, though feature and model availability still depend on the provider and the user's approved access.
Access matters more than the 1-second repository install
Our repository-level install finished in 1 second, added 0 packages, and used 23 MB. That result reflects the sparse root package, not installation of the published @openai/codex-security CLI from npm. A real scan needs Node.js 22.13.0 or later in the 22 line, or Node 24 or 26, plus Python 3.10 or newer. The public package alone does not grant permission to run OpenAI-backed scans.
Interactive users can sign in with ChatGPT, while CI can use an OpenAI or Codex API key. Device authentication covers some headless workspaces. Official OpenAI documentation says some full-repository scans may also require Trusted Access for Cyber. Alternative providers bring their own credentials and model selection. Cost belongs in the operating plan: the CLI reports usage estimates when available, and its maximum-cost setting can be exceeded slightly by requests already in progress.
What happened when we ran it
Our sandbox cloned commit 5ebe48d with 922 files, about 293,526 lines of source, and a 12.8 MB checkout. The repository-level npm install completed in 1 second with 0 packages installed and 23 MB on disk. Our test method used an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. Npm audit found 0 known vulnerabilities in that root install.
The root package defines neither a build script nor a test script, so both steps were skipped. Our scan found 20 CI workflow files, a Dockerfile, and a Compose file, but no conventional tests directory. Those signals show substantial automation elsewhere in the monorepo. They do not replace a runnable root verification target, and we made no paid or credentialed model call to judge finding accuracy, scan duration, token use, or patch quality.
Node 22.13.0 scans inherit local operating-system permissions
The documented minimum is Node 22.13.0 within the 22.x line, and local scans use the account's operating-system permissions without pausing for approval. OpenAI tells users to remove unrelated credentials before scanning. A dry run checks paths and output locations without starting Codex or loading credentials, which should be the first production check. Run the actual job in a disposable worktree or similarly constrained environment when the repository is sensitive.
Output needs equal care. Findings can contain source excerpts and vulnerability details, live dashboard events may expose code or credentials, and saved logs are not redacted. Release v0.2.0 explicitly notes that diagnostic text resembling credentials is no longer masked. Store results outside the checkout, apply a retention policy, and review every report before sharing it in a ticket, pull request, or chat channel.
The v0.2.0 preview findings service has no authentication
The local findings service in v0.2.0 can store scan results, display them in a dashboard, group possible duplicates, and accept published scans. Its API has no built-in authentication. Imports also send complete finding JSON to the configured embeddings endpoint and require an embedding API key. Treat it as a local or tightly protected preview component, not an Internet-facing AppSec portal.
Patches deserve the same restraint. The CLI can generate a change, verify it, and optionally open a pull request, but a model-produced fix is still a proposed diff. The official guidance keeps the final decision with an engineer. Teams should reproduce the bug where safe, inspect the changed trust boundary, require a regression test when feasible, and run their existing review and deployment gates before merging.
Forty-six open issues show young contracts under real use
GitHub search found 46 open issues on October 8, 2026, while the repository API listed 287 combined issues and pull requests. The repository was pushed that same day, two days after v0.2.0 shipped. Current reports include missing delegated-worker dispatch events, inconsistent durable coverage after resolved checkpoints, and equivalent findings receiving different identities between Standard and Deep scans. These are integration and evidence-contract bugs, not cosmetic requests.
Issue 763 asks for a public, versioned corpus that measures whether releases keep finding the same vulnerability classes with comparable evidence. An open October 8 pull request adds an initial synthetic corpus and scorer, so the gap is being worked. Until that lands and accumulates history, evaluate Codex Security on your own known test cases. Its best role today is an evidence-producing investigator beside established scanners, with humans retaining authority over severity, disclosure, and fixes.