Codex Security Review: OpenAI's AI Vulnerability CLI

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Codex Security is OpenAI's open-source CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in a codebase. It shipped with no blog post and no tweet — someone found the npm publish, put it on Hacker News, and it hit 598 points before OpenAI acknowledged it existed. The company's eventual post on X opened with: "We quietly released the open-source Codex Security CLI, but Hacker News found it before we had a chance to share it here."

Key facts:

• Repo: openai/codex-security — Apache-2.0, TypeScript, ~10,065 stars and 718 forks as of August 22, 2026. Created July 13, 2026; first npm publish July 28.
• Package: @openai/codex-security, currently v0.1.16 — 17 releases in under four weeks.
• Requirements: Node.js 22.13+ (22.x line), 24.x, or 26.x, plus Python 3.10+ for scans, exports, and saved findings.
• Not a linter. It's an agent harness: it reasons about code in context, validates its own findings, and can write and verify the patch.
• Not offline. Your source code goes to a hosted model. There is no local-inference path that OpenAI officially supports (yet).
• The catch: a single scan on a small repo drained half of one user's weekly ChatGPT Pro allowance, then crashed.

The scanner is genuinely interesting. But as one commenter put it, the scanner isn't the product — the harness around it is.

What Codex Security actually is

Most static analysis works on pattern matching. Semgrep, CodeQL, and the SAST layer inside Snyk all encode "this shape of code is dangerous" as rules, then match those rules against an AST. That approach is fast, deterministic, and reproducible, which is exactly why it drowns teams in false positives: a rule can see that user input reaches a SQL string, but it can't see that three frames up the call stack a middleware already validated and escaped it.

Codex Security runs a model over your repository instead. It reads code the way a human security reviewer would — following data flow across files, reasoning about what the application is for, and asking whether a given path is actually reachable by an attacker. When it produces a finding, it has already tried to talk itself out of it.

The workflow has four stages that map onto four CLI verbs:

1. scan — discovery. The model explores the repository, optionally delegating to parallel workers.
2. Validation — the harness re-checks each candidate finding, with an optional custom validation step you control.
3. patch — the fix. It writes the change, verifies it, and can open a draft GitHub PR.
4. scans compare — regression tracking. It matches findings between two scans by root cause, not by line number, and classifies each as new, persisting, reopened, resolved, or unknown.

That fourth stage is what legacy tools handle badly, and what determines whether a security tool survives contact with a real team.

Why it's trending now

Three things converged.

First, the release mechanics were bizarre in a way developers love. An Apache-2.0 repo from OpenAI appearing with no marketing is catnip for Hacker News.

Second, the person who eventually showed up has credibility. Michael D'Angelo — co-founder of Promptfoo, the LLM eval framework — posted as dangelosaurus: "Michael here, co-founder of Promptfoo and one of the people working on the Codex Security CLI at OpenAI." Promptfoo was acquired, and its team's DNA is visible in the release: the repo ships the actual TypeScript skill definitions that tell the model how to hunt for vulnerabilities, and D'Angelo described spending "billions of tokens" of evals tuning those prompts.

Third, AI-written code created the demand. Teams are merging far more code than they can review. A scanner that reasons instead of pattern-matching is the obvious response — which is also why the most-upvoted cynical comment in the thread landed: "security tools from AI companies feel like fire departments run by arsonists. useful, sure, but you can't help noticing who benefits from all the fires."

Getting started

Install and run:

npm install @openai/codex-security
npx @openai/codex-security login
npx @openai/codex-security scan .

The login step uses your ChatGPT account. On a headless box, use device auth:

npx @openai/codex-security login --device-auth

For CI, set OPENAI_API_KEY or CODEX_API_KEY instead of signing in. Note the precedence rule that bit early users: an environment API key overrides a stored ChatGPT sign-in by default. Interactive scans now ask which credential to use, but non-interactive runs still silently prefer the API key. Force it explicitly:

npx @openai/codex-security scan . --auth chatgpt
npx @openai/codex-security scan . --auth api-key

Environment keys are passed straight to the running scan and never written to the credential store or system keyring.

The flags that matter

# Fix high and critical findings, then open a draft PR
npx @openai/codex-security scan . --patch --patch-severity high --create-pr

# Only scan what changed — the CI-friendly mode
npx @openai/codex-security scan . --diff origin/main --json

# Narrow the blast radius
npx @openai/codex-security scan . --path src --path tests

# Feed it your threat model and architecture docs
npx @openai/codex-security scan . --knowledge-base ./docs/threat-models --knowledge-base ./docs/architecture.pdf

# Deep mode: multi-worker, long-horizon discovery
npx @openai/codex-security scan . --mode deep --workers 2 --subagents 0 \
  --stop-after-no-new 3 --max-discovery-runs 10 --max-time-hours 1.5

--knowledge-base is underrated: handing over your threat model is the highest-leverage way to cut irrelevant findings, because it tells the scanner where your real trust boundaries are.

Ordinary scans never modify repository files. Only --patch writes, and --create-pr commits to a branch and opens a draft PR. If publication fails, the CLI prints a patch --resume-pr BRANCH command so you can retry without paying for the model run again.

Deep mode and the 96-hour ceiling

Deep-scan discovery runs until it stops finding new things, or until it hits a wall-clock limit that defaults to 96 hours. Not a typo. --max-time-hours accepts any positive value up to 96, including fractions, and completed findings are preserved when the limit trips. Set it.

The TypeScript SDK

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();

try {
  const result = await security.run("/path/to/repository", {
    outputDir: "/path/outside/repository/results",
    maxCostUsd: 5,
    mode: "standard",
  });

  console.log(result.reportPath);
  console.log(result.findings.findings.length);
} finally {
  await security.close();
}

maxCostUsd is the flag every reader of this post should care about — it stops the scan once estimated model cost passes a threshold. The SDK also exposes preflight() to validate inputs without starting the runtime, an AbortSignal for cancellation, and lifecycle callbacks (onCost, onWorkerStatus, onScanStarted, onSessionEvent) so you can build a real progress UI — which you will want, for reasons below.

Model portability: the pleasant surprise

For a tool from OpenAI, the provider story is unusually open. The CLI supports third-party inference:

export OPENROUTER_API_KEY="<key>"
npx @openai/codex-security scan . --provider openrouter --model anthropic/claude-sonnet-4.5

export FIREWORKS_API_KEY="<key>"
npx @openai/codex-security scan . --provider fireworks --model accounts/fireworks/models/qwen3-235b-a22b

export AWS_BEARER_TOKEN_BEDROCK="<key>"
export AWS_REGION="us-east-2"
npx @openai/codex-security scan . --provider amazon-bedrock --model openai.gpt-5.6-luna

You can run OpenAI's security harness against Claude. That matters for the data-residency objection: as one HN commenter noted, the Bedrock path keeps analysis inside your AWS account rather than sending it to OpenAI.

Workflow integration

publish scan pushes every finding from a completed scan into Linear as issues containing the scan ID, affected locations, source snippets, and remediation guidance:

npx @openai/codex-security publish scan /path/to/scan \
  --to linear --linear-team TEAM_ID --linear-project PROJECT_ID

It works in reverse too — patch --linear-issue SEC-123 imports an existing Linear issue and fixes it, and --linear-project "Security backlog" with a filter chews through a backlog.

There's also a containerized bulk-scan path — official image plus Docker Compose config — for non-interactive, resumable scans of repositories pinned to immutable Git revisions. That's the fleet-scanning story for platform security teams.

What the community actually said

The HN thread was skeptical in a productive way.

On launch quality, the top comment was just "Just getting auth issues so far..." — a real bug, fixed in v0.1.1 the same day via PR #22. A separate commenter turned that into a broader point: "this right here is why I don't believe any marketing around 'great amazing models that one-shot everything and programmers are no longer needed.'"

On guardrails, the most substantive complaint. One user: "I seem to have gotten a bunch of 'you are trying to stuff we don't allow' errors." D'Angelo's answer was candid — the CLI performs no repository-ownership check, public projects are supported, and reviewing your own kernel patches "is the kind of defensive work we want to support." The refusals come from model guardrails "which can be overly cautious." The escape hatch is Trusted Access for Cyber (internally TAC1/Daybreak) at chatgpt.com/cyber, with a separate conditional-access form for open-source maintainers.

On cost, this is the review-defining anecdote. User gregwebs:

Just ran it on a small repo. It ran for almost an hour and then got interrupted. It drained half my weekly usage on a Pro plan.

The run died at the 52-minute mark with Repository HEAD changed while the scan was running. Start a new scan. Another user hit account rate limits, watched the retry logic give up after about a minute, and reported the failed run cost roughly $13. Both got a "partial output was kept at…" message with no obvious way to resume.

On observability, iancarroll: "the CLI output is not particularly interesting while the scan is running. I wish it could show token usage, some kind of progress." D'Angelo: "Agreed! This is near the top of our priority list."

The sharpest architectural take came from knighthacker:

The scanner is the least interesting part of this. The harness around it is the product: dedup across runs, false-positive tracking, budget controls, CI gating. That is the layer where we'll see most interesting innovations.

Whether Codex Security is worth adopting hinges entirely on whether you agree with that — and the evidence (root-cause finding matching, scan comparison, cost limits, resumable PR publication) says the OpenAI team agrees.

Honest limitations

1. Your code leaves your network. D'Angelo was direct: "this isn't an offline scanner. The CLI runs locally but the code and context needed for analysis are sent to the hosted model." If your policy forbids that, the Bedrock provider is the only realistic path.
2. Cost is unpredictable and can be brutal. Always pass maxCostUsd or --max-cost-usd on the first run against an unfamiliar repo. Treat the defaults as hostile.
3. Long scans are fragile. A commit landing mid-scan can invalidate an hour of work, and resume ergonomics for partial output are poor today.
4. Guardrail refusals are arbitrary. You may be blocked from analyzing code you wrote and own, with no clear appeal beyond an access application.
5. Version 0.1.16 means what it says. Semantic versioning applies, but the public API may change between minor versions before 1.0.0. Pin your version in CI.
6. No offline/self-hosted mode is officially supported. Third-party endpoints work; nobody promises they'll keep working.

How it compares

The Strix comparison came up on HN directly, and the answer there was right: "They are entirely different products." Strix is dynamic — it attacks a running application and proves exploitability with a working PoC. Codex Security is static — it reads source and reasons about it. Complementary, not competitive. The same thread surfaced Alibaba's open-code-review CLI, released the same day, which is a general code-review tool rather than a security scanner.

The real competitive question is Snyk. One commenter asked whether tools like this put it out of business; the best reply was "I like to think it just upped the bar, but good durable expertise will need to rise with it." Codex Security has no per-seat license — you pay for tokens — a genuinely different cost curve from enterprise AppSec pricing.

Who should use this

Good fit: teams shipping AI-generated code faster than they can review it; open-source maintainers who can get conditional access; anyone already paying for Codex who wants --diff origin/main gating on pull requests; security teams wanting a second opinion alongside deterministic SAST.

Bad fit: organizations whose source can't leave the network (unless Bedrock satisfies compliance); teams needing deterministic, reproducible output for audit; anyone without a hard budget ceiling; projects on Node.js older than 22.13.

The pragmatic starting configuration is diff-only scanning in CI with an explicit cost limit:

npx @openai/codex-security scan . --diff origin/main --json --output-dir /tmp/scan-results

That bounds cost, bounds runtime, and puts findings where a human reviews them — instead of turning a 96-hour deep scan loose on your monorepo and discovering the bill on Monday.

FAQ

Is Codex Security free?
The CLI and SDK are free and Apache-2.0 licensed. Running scans is not free — you consume ChatGPT plan usage or pay per token via an API key. HN users reported a single small-repo scan consuming half a weekly Pro allowance, and one failed run costing about $13. Use maxCostUsd from the first run.

Can I run Codex Security offline or with a local LLM?
Not officially. OpenAI confirmed local and third-party endpoints "aren't officially supported yet," though the CLI does accept OpenRouter, Fireworks, and Amazon Bedrock providers, and the Apache-2.0 license lets you point it anywhere. Bedrock is the closest thing to a data-residency-friendly option.

Does it modify my code?
Not by default. Ordinary scans are read-only. --patch writes fixes, and --create-pr commits verified files to a branch and opens a draft pull request — never a direct push to your default branch.

Why does it refuse to scan some repositories?
Model guardrails, not ownership checks. There is no repository-ownership verification; public repos and your own patches to projects like the Linux kernel are explicitly supported use cases. Overly cautious refusals are a known issue, and Trusted Access for Cyber is the approved path to reduce them.

How is this different from the Codex security plugin?
Codex Security started life as a plugin inside Codex. The news is that OpenAI open-sourced it as a standalone CLI and SDK with a scriptable interface, CI integration, scan history, cross-run finding comparison, and Linear publishing — the harness features a plugin invocation can't offer.

Is it production-ready?
At v0.1.16, a month after release, with 181 open issues and a maintainer saying "expect the product to evolve quickly" — no. Run it in CI on diffs with a cost cap, review every finding by hand, and don't retire your existing SAST yet.

Sources

• openai/codex-security on GitHub — repository, README, and TypeScript SDK docs (Apache-2.0)
• Hacker News discussion #49089755 — 598 points, including maintainer replies from Michael D'Angelo
• @openai/codex-security on npm — version history (v0.1.16, first published July 28, 2026)
• Official Codex Security CLI documentation

Facts verified August 22, 2026. Star counts and version numbers move fast on a repo this young — check the source links for current values.