Codex Security: Pricing, Setup, Local vs Cloud, and Reading Scan Results

Codex Security is a security agent that finds potential vulnerabilities in code, checks the evidence, and helps you work toward fixes. The first distinction to make is between the plugin you use in your local Codex environment and Codex Security Cloud , which connects to GitHub. Despite the similar names, their setup, execution environment, and billing information differ.

This article covers choosing an option, pricing and free allowances, your first scan, the overhead of deeper scans, interpreting results, and checking fixes. The explanation is based on OpenAI documentation reviewed on October 7, 2026. We have not run a product scan, so we do not report measured detection accuracy, scan duration, or actual usage.

Sources: OpenAI, Codex Security overview and getting started with the local plugin.

Choosing local scans, Cloud, or ordinary reviews

For a small change, you can also give your usual Codex chat a diff and your review criteria. That does not mean it automatically produces a dedicated scanner's artifacts or coverage records. Asking for a code review and running a Codex Security scan are distinct actions. For choosing between coding tools more generally, see our Claude Code and Codex comparison.

Cloud is a research preview and requires access for the relevant workspace. For the standalone CLI, too, a publicly available package does not necessarily mean your account has permission to scan. Depending on the account and repository, a full codebase scan may also require additional “Trusted Access for Cyber” access. A subscription name such as Pro does not establish access to every option. If an option does not appear, check whether the plugin is enabled, your access permissions, and your organization's administrative settings.

Sources: OpenAI, overview and access requirements and security reviews of code changes.

Pricing and free allowances: check even with Pro

Cloud scans are outside your ordinary plan allowance

OpenAI's Cloud FAQ explains that repository scans and continuous scans configured on or after October 1, 2026, at 12:53 p.m. Pacific Time are billed in credits or US dollars at your plan's token rates . They are not included in the ordinary plan allowance. Eligible accounts' free scanning credits are applied before paid usage.

The US$500 is neither a cash payment nor a guaranteed benefit for every user. After the free balance is exhausted, the account's or workspace's billing rules apply. Before starting, check your eligibility, remaining free balance, and paid usage conditions in the interface.

The displayed “cost” is not necessarily your bill

In Cloud, open the relevant scan from “Scans” to see its token count and cost. Hover over the token count for the input, cached input, and output breakdown. The displayed cost is calculated before free credits or billing exemptions, so read the free-credit deduction separately from the actual charge. Scans marked “Exempt from billing. No charges apply.” are not charged.

Source for billing, free allowances, and displayed costs: OpenAI, Codex Security Cloud FAQ: Billing. The cutoff uses Pacific Time, as stated in the documentation.

Do not apply Cloud's free allowance to the local plugin

The local plugin runs as a Codex task. Under Codex's general usage rules, consumption depends on the subscription, model, workload, and authentication method; additional local work authenticated with an API key is subject to API billing. However, the local setup guide, Standard and Deep scan documentation, and CLI FAQ we reviewed provide neither a fixed price per scan nor a separate pricing table covering every plugin use case. We cannot describe local scans as consuming nothing or claim they use Cloud's US$500 allowance.

Check your remaining Codex allowance in the usage interface, or with /status inside Codex CLI. Cloud scan costs also need to be checked on the Cloud side. For subscription comparisons, see our Pro pricing and usage allowance guide.

Sources: OpenAI, Codex and Work pricing and usage and CLI authentication selection.

Your first scan: steps and a sample request

The following describes the official setup instructions. Scan only code you own or have permission to inspect. For a first scan, check the target branch, revision, output location, and authentication method. Starting with Standard makes the process easier to follow.

The local plugin in the desktop app

1. Find “Codex Security” in the plugin list, then install and enable it. The Cloud version is a separate plugin.
2. Open “Security” → “Scans” → “+ Scan” in the sidebar.
3. Select a repository and choose “Codebase” for a codebase scan. Leave “Deep scan” off for your first scan.
4. Check the folders to inspect, the current branch and revision, and the model and reasoning effort.
5. If needed, add public entry points, authorization rules, and important operations to “Additional context”.
6. Choose “Start scan” and follow the progress through each stage. On completion, read the coverage and evidence.

Inside Codex CLI, install it through /plugins, then use /new to create a new chat for the target repository. Explicitly naming the dedicated scan and its target provides a clearer record of your request than simply asking to “check security”.

Run a Standard scan with Codex Security, focusing on services/billing.
Prioritize user input, ownership checks for billing information, and administrative operations.
For this task, inspect and report only. Do not modify source code, commit, push, deploy, or change billing settings.
Report the target revision, inspected scope, excluded or unfinished areas, and reproduction evidence.
If a settings change is needed, explain the proposed change and reason, then stop.

This is a sample request, not a sandbox configuration that enforces permissions. Scans may require output artifacts and validation work. Do not assume that written restrictions alone protect the entire computer; also check execution permissions.

The Cloud version connected to GitHub

1. Install “Codex Security Cloud” and check its GitHub connection to the target repository.
2. Under “Scan”, select the repository and environment. “Auto” creates an environment at startup; use “Customize” to check an existing prepared environment.
3. Choose “One-Time Scan” for a single inspection or “Continuous Scanning” to monitor future commits.
4. Check pricing, the free balance, and the target before choosing “Create” to start.

Continuous scanning targets the repository's default branch. A longer historical commit lookback makes the initial inspection take longer. To stop monitoring, open “Repositories” → the target repository → “Monitoring settings”, pause it, and save. Closing the window does not stop monitoring.

Sources: OpenAI, plugin setup and Cloud setup and monitoring.

Standard and Deep: adjusting scope and overhead

The official Deep settings default to 4 concurrent workers, 3 subagents per worker, and a maximum runtime of 96 hours. The 96 hours is a configured limit, not a typical scan duration. Configuring the time limit requires plugin version 0.1.19 or later. When the limit is reached, unfinished workers stop and completed results are consolidated. Any uninspected areas remain uninspected.

First narrow the target to a meaningful service and read the Standard results before deciding whether Deep is necessary. You can also focus deeper inspection on important areas such as payments or authentication. Reducing worker counts or runtime can reduce overhead, but may also leave more problems undiscovered. Record the scope covered by the scan you made cheaper or faster.

Use “Changes” to inspect a diff. You can select uncommitted changes, a single commit, or base and target revisions, but Deep is unavailable for Changes scans. These inspect the diff and directly related code; they do not automatically expand into a full codebase audit.

Sources: OpenAI, Standard, Deep, and default settings, Changes scan coverage, and estimated cost limits.

Read coverage and evidence, not just finding counts

The number of findings alone cannot establish scan quality. A scan with the wrong target, one that stopped midway, or one missing authorization rules can return zero findings without making the code safe. The official Standard scan workflow also recommends first reading the revision, inspected areas, deferred areas, and individual evidence.

1. Is the target correct? Check the repository, revision, and scope. Do not use results for old code as assurance about the current version.
2. What was not inspected? Check excluded, deferred, and interrupted areas. A completion indicator does not mean the entire codebase was covered.
3. Does the evidence hold up? Examine the path from input to dangerous behavior, existing defenses, and the reproduction method and results.
4. Does it need a fix? Assess realistic reachability and impact, then fix accepted findings one at a time.

report.md is the readable entry point. The structured coverage.json records inspected and deferred areas, while findings.json describes finding locations, severity, evidence, and remediation guidance. findings/ may contain detailed reports and reproduction files. Keep related files with the report when sharing or archiving results.

The standalone CLI records coverage as complete, partial, or unknown. Coverage marked partial or unknown produces exit code 2. Even if a finding disappears in a later scan, you cannot call it fixed if the original path was not inspected. Cloud's automatic validation likewise attempts reproduction. An unvalidated result does not mean the code has been proven safe.

Sources: OpenAI, evaluating Standard scans, CLI coverage and comparisons, and Cloud automatic validation.

Fixes, verification, and confidential information

Explain authorization rules to make findings easier to evaluate

Include who should be allowed to perform which operations in the scan context. For example: “Only the owner and administrators can access billing information” or “Only a file's owner can publish it.” In the local plugin, SECURITY.md can hold lasting security policy, while AGENTS.md can hold build and validation instructions. In Cloud, review the generated threat model and fill gaps in public entry points, important operations, and trust boundaries.

A threat model is a short description of the application's structure and the conditions it must protect. Cloud edits apply to future scans. Changing the assumptions does not retroactively change what an earlier report inspected.

Fix one finding at a time and check both reproduction and normal behavior

1. Accept a finding: Review the evidence and real-world impact, then choose one finding to address.
2. Generate a small patch: In the local interface, choose “Patch” → “Generate patch”. Generating a proposal is separate from applying it to the target checkout.
3. Read the diff: Check for unrelated cleanup or changes that weaken other defenses before choosing “Apply patch”.
4. Verify it: Use “Verify fix” to check the original reproduction and normal behavior. Where possible, retain a regression test that fails before the fix and passes afterward.
5. Close the finding: Verification does not automatically close it. Review remaining evidence gaps and either close it with a reason or continue investigating.

When Cloud provides a patch, the workflow also involves reviewing it before creating a draft PR. Record the proposal, application, verification, and production deployment as separate steps. Use our pre-launch checks for AI-built apps too, rather than relying on a single scanner to make every decision.

“Local” does not mean nothing leaves your computer

Even for local execution, separately check how model inference requests and validation information are handled. The standalone CLI's official instructions warn that scans use local OS permissions, do not stop for approval of each operation, and may inherit environment variables. Do not assume they have the same permissions as an ordinary Codex chat. Prepare a scan environment without unnecessary credentials.

Saved logs are not necessarily redacted automatically and may contain source code or credentials. Artifacts can also include reproduction steps and vulnerability details. Check both their contents and sharing scope before making a public link or sharing them with a third party. Model-training settings are covered separately in our ChatGPT and Codex training-data and privacy guide.

Sources: OpenAI, SECURITY.md and AGENTS.md, Cloud threat models, fixes and verification, and standalone CLI permissions, artifacts, and logs.

Checklist before you start

For a first scan, start with Standard on the scope you need and establish whether you can evaluate its results yourself. Consider Cloud for continuous monitoring or the standalone CLI for integrating scans into automated workflows. Use it as a tool that supports discovery and validation, rather than proof of safety that replaces existing static analysis (SAST) or human review .

Frequently asked questions