OpenAI Codex Security CLI: Open Source Scanner, Limits, and What Coding Teams Should Know

OpenAI quietly open-sourced the Codex Security CLI on GitHub, and Hacker News found it first. The openai/codex-security repository publishes the same @openai/codex-security package that powers terminal scans, a TypeScript SDK, and a sample GitHub Action workflow. If you run Codex, Claude Code, Cursor, or CI bots against proprietary repos, this changes what you can bolt onto pull requests—and what code and metadata leave the machine for model inference. Early adopters on Hacker News thread 49089755 report auth friction, subscription usage burn, and Trusted Access for Cyber gates that halt scans mid-run.

TL;DR

What shipped in the public repository

OpenAI’s README describes Codex Security as tooling to find, investigate, and fix vulnerabilities through three surfaces:

1. Codex Security plugin inside Codex desktop or CLI sessions (interactive workbench).
2. cs / codex-security CLI for repeatable terminal and CI scans.
3. TypeScript SDK (import { CodexSecurity } from "@openai/codex-security") for embedding scans in internal tools.

Documented capabilities include:

• Scoped scans of paths, full repositories, or git diff ranges (cs scan . --diff origin/main).
• Deep mode that repeats standard scans and deduplicates findings.
• Patch propose and verify flows after a finding is saved.
• SECURITY.md policy drafting with artifacts saved outside the repo until you copy reviewed files in.
• Third-party scanner import, SARIF/JSON/CSV export, and ticketing hooks.

Runtime requirements are explicit: Node.js 22.13.0+ on the 22 line, or 24.x / 26.x, plus Python 3.10+ (with tomli on 3.10). That matches modern agent tooling stacks but excludes older LTS images still common in legacy CI.

Authentication paths include cs login for interactive use and OPENAI_API_KEY or CODEX_API_KEY in CI, per the README. Amazon Bedrock is listed as a provider that uses AWS credentials instead of OpenAI login.

OpenAI’s documentation hub positions the CLI beside Codex Security Cloud (GitHub-connected, workspace-gated preview) and the desktop Security workbench—three entry points, one package on npm.

How a local scan runs (step by step)

From the README quick start and CLI help references:

1. Install globally: npm install --global @openai/codex-security.
2. Authenticate: cs login (or device/SSH login for headless hosts, documented in the security guides).
3. Preflight from the repository root: the CLI records HEAD, checks worker delegation (HN users saw “up to 8 worker slots”), and loads existing SECURITY.md guidance if present.
4. Investigate selected paths or the whole tree; standard mode respects a 15-minute advisory allowance when you pass --max-time 15, with separate semantics for deep scans.
5. Save a Markdown report at the path printed when the scan completes; cs scans show retrieves the latest completed run for that repo.

If HEAD moves during a long scan, the CLI aborts with an error several HN commenters quoted: repository HEAD changed while the scan was running—start a new scan. That matters for active agent branches where bots commit frequently.

Trusted Access for Cyber and usage limits

The README states plainly that some cybersecurity requests and protected findings require Trusted Access for Cyber, with a Daybreak opt-in path for eligible accounts.

HN reproducibility matched the docs:

• User andreagrandi reported a scan stopped with “This content was flagged for possible cybersecurity risk” and a link to chatgpt.com/cyber.
• gregwebs said a scan ran nearly an hour, then failed after consuming roughly half a weekly Pro allotment.
• ryanto hit the same cybersecurity flag on a small OSS library.

For security teams, that is a policy gate, not a bug: OpenAI is separating everyday coding from offensive-security-shaped prompts and repositories. Corporate adopters should decide before CI integration whether their account tier and cyber enrollment cover the repos agents touch.

What developers are saying

Hacker News commentary clustered around a few practical themes:

• Harness vs model. knighthacker argued deduplication, false-positive tracking, budget controls, and CI gating are the durable value—not the naked model call.
• Open source timing. bakigul noted the capability existed as a Codex plugin; the news is public source and rapid iteration. punnerud linked OpenAI’s post admitting HN found the release first.
• Insider context. Promptfoo co-founder dangelosaurus introduced himself as working on the CLI, asked for feedback, and pointed to CLI security docs.
• Skepticism. petesergeant called it partly a CI wrapper around existing models while crediting richer SDK typing; halfax and vinhnx warned about cloud exfiltration of source and token burn.
• Maintainer load. gyre007 predicted noise from low-quality LLM-generated security reports against OSS repos—a process problem teams should plan for.

Beam did not run the CLI ourselves in this unattended pass; treat timings and usage figures as commenter-reported, not benchmarks.

What this means if you run AI coding agents

In CI and on laptops agents share

Coding agents already read, edit, and commit the same trees you might scan. Codex Security does not observe those sessions automatically; it is a deliberate second pass. Useful pairings:

• Run cs scan . --diff origin/main on pull requests agents open, with a spend cap (the sample GitHub Action uses an estimated $5 limit and does not fail the job on findings alone).
• Keep SECURITY.md current so scans inherit your reporting and severity rubric—the README says scans consume root and component policy files.
• When agents propose dependency bumps, align with Node.js October 2026 security releases and MCP SDK advisories—the same class of flaws Codex Security already helped credit on Brotli (CVE-2026-111497).

Data handling decisions

If your threat model treats source code as confidential, default OpenAI routing may fail compliance regardless of model quality. The README’s Bedrock path is the documented alternative that keeps inference inside AWS credentials you control—still cloud, but a different contract.

Agents that paste install commands or pull skills from the internet remain out of scope for Codex Security; pair scanner output with InstallFix awareness and skill supply-chain hygiene.

When scans disagree with agent output

HN users noted long runtimes and sparse progress UI. For agent-heavy teams, that latency pushes scans off the critical path unless you budget time or scope paths (--path src). The deep-scan mode is powerful but multiplies model calls—watch the same usage pools your Codex sessions consume.

How Beam handles this

Beam and Codex Security solve different layers of the same workflow.

Codex Security looks backward at static code and saved findings: it proposes vulnerabilities, patches, and policy files, usually with cloud model inference unless you reconfigure providers.

Beam looks forward at what a coding agent is doing on your machine: it records tool calls, heuristically scans skills and MCP server configs (11 patterns plus version-pin checks), redacts known credential shapes before storage, and can deny selected risky actions through Claude Code and Codex PreToolUse hooks when workspace policy is cached locally.

Where Beam fits better:

• You need evidence of what an agent actually ran (shell, file writes, secret exposure) without uploading the whole repo.
• You want local-first observability with no default cloud telemetry from the collector (what stays on-device).

Where Codex Security fits better:

• You need systematic vulnerability review across a large tree, SARIF for auditors, or CI gating on new findings.
• You already enrolled in Trusted Access for Cyber and accept provider-side processing.

Beam does not statically analyze application source for OWASP-style bug classes, and Codex Security does not block a live curl | bash you typed because a fake install page told you to. Using both is reasonable: scanner on the repo, Beam on the agent harness.

For an adjacent commercial control plane story, see Bay’s runtime hook launch and GitGuardian’s survey of agentic pentest frameworks—different products, same question of where you enforce policy.

Checklist before you enable CI scans

1. Confirm account programs: Trusted Access for Cyber, Daybreak, and workspace Codex Security Cloud if you need remote dashboards.
2. Pin dependencies: install @openai/codex-security from npm with a lockfile; review GHSA history on MCP SDKs separately.
3. Scope aggressively: start with --path on services agents edit most, not monorepo roots.
4. Set secrets: CODEX_SECURITY_API_KEY in GitHub Actions only on protected branches; never in agent-readable .env files agents might exfiltrate (token theft patterns).
5. Review Action SHA: the README tells you to replace REPLACE_WITH_REVIEWED_COMMIT in the weekly workflow with a reviewed distribution commit.
6. Plan for noise: triage workflow before you auto-open issues—HN warned about spammy LLM reports.

Frequently asked questions

The FAQ entries in front matter mirror the sections above; see those for quick citations.

Related reading

• Bay AI agent security: runtime hooks and discovery
• PHP2Shell and AI agents: attack speed
• MCP TypeScript SDK: four advisories in 1.32.0
• Node.js October 2026 security release
• Fake Claude Code installers and InstallFix
• WardenStealer and Aoki target agent tokens
• OpenAI fuzzy robustness: automated red teaming against cyber jailbreaks (Nov 12, 2026)
• OpenAI Daybreak Red Team and Defense Factory keynote launch (Nov 12, 2026)
• Primary sources: GitHub repository · Codex Security documentation · @openai/codex-security on npm

Details reflect the public README and documentation as of November 11, 2026. Auth rules, pricing, and cyber enrollment change frequently—verify against OpenAI’s docs before production CI.