Understand Codex Security—and distinguish it from the Codex sandbox

Codex Security is an application security agent that helps security and engineering teams find, confirm, and fix vulnerabilities. It examines repository code in its security context. It is not a runtime boundary for controlling which files, networks, or machine resources an agent can access while running commands. In short, Codex Security supports repository-focused AppSec review; runtime controls support safe agent execution.

What Codex Security is—and what it is responsible for

OpenAI makes Codex Security available in Codex, from a terminal, through the TypeScript SDK, and with connected GitHub repositories. The cloud product scans connected GitHub repositories for likely security issues. When the documentation was checked on August 24, 2026, OpenAI described it as a research preview.

The product focuses on application security analysis. It uses repository-specific context to identify likely vulnerabilities, tries to validate them, and helps turn findings into fixes that reviewers can inspect. The cloud workflow requires a repository that is connected to GitHub and visible in the Codex cloud workspace. That is a prerequisite for the documented cloud product, not a plugin installation or authentication guide.

The object under examination defines the boundary: Codex Security reasons about a repository and possible vulnerabilities in its code. This function does not determine which resources an agent command may access at runtime.

What Codex Security takes in and what it produces

Codex Security builds a threat model from the repository. It combines a project overview with details about the attack surface, including entry points, trust boundaries, authentication assumptions, and risky components. The system uses this context throughout the scan instead of treating every codebase as interchangeable.

Its documented workflow covers three broad functions: identification, attempted validation, and remediation. First, the system analyzes the repository and explores plausible attack paths. It then tries to reproduce a suspected issue in an isolated environment. For remediation, it can generate a concrete patch for reviewers to inspect before it becomes a pull request.

Findings are ranked and include criticality and validation status. A finding may also contain a proposed patch, reproduction evidence, crash output, call-path context, or related annotations. The exact supporting material depends on what is available. These outputs aid review; they do not make every detected possibility a confirmed vulnerability or every proposed change an approved fix.

Where its claims end

A threat model is editable scan context, not an infallible description of the project. Codex Security creates an initial version from the code, and OpenAI recommends editing it when findings feel misaligned. The quality of that context affects prioritization and review.

Validation tries to reproduce a suspected issue; it does not guarantee that every finding will be confirmed or rejected. If reproduction fails, the finding remains unvalidated. Logs and reports preserve evidence of the attempt so engineers can investigate, retry, or adjust the reproduction approach.

Codex Security is not a replacement for the rest of an AppSec program. OpenAI describes it as complementary to static application security testing, while SAST continues to provide broad, deterministic coverage. It also does not replace manual review, code-level validation, exploitability checks, or human threat assessment. A ranked finding therefore means “review this evidence and status,” not “the system has proved the complete security state of this repository.”

Why Codex Security is not the Codex sandbox

Codex Security scans connected GitHub repositories for possible vulnerabilities. The Codex sandbox has a different job: it constrains commands run by an agent so they do not receive unrestricted access to files, the network, or the machine by default. Approval policies separately determine when an agent must stop and ask before acting.

The outputs reveal which control is involved. Repository findings, validation statuses, reproduction evidence, and patch proposals come from Codex Security. Restrictions on file, network, and machine access for executed commands come from the Codex sandbox and its surrounding runtime controls. For more on that boundary, see the Codex sandbox and local runtime permissions.

Use each term for the security question it answers. When the question is “What vulnerabilities might this repository contain, and what evidence or patch can reviewers inspect?”, Codex Security is the relevant AppSec product. When the question is “What may this agent command access or do while it runs?”, sandboxing and approvals are the relevant controls.