Codex Security is not one interface with four interchangeable entry points.
OpenAI documents a Desktop plugin and Security workbench, a command-line interface, a TypeScript SDK, and a separate Codex Security Cloud plugin. Each surface can participate in application-security work, but each places initiation, execution, evidence, operating state, and review in a different part of the system.[1][2]
That makes surface selection an architectural decision.
The right question is not simply which interface a team prefers. The right question is which operating model the work requires.
One Security Discipline Does Not Mean One Product Surface
The four surfaces share a broad security discipline: find potential vulnerabilities, investigate and confirm them, prepare remediation, preserve evidence, and keep review consequential.
They should not be presented as one deployment model or as a promise of feature parity.
Capabilities documented for one surface do not automatically belong to another. Bulk scanning, CI behavior, SARIF, saved workbench history, embedded lifecycle callbacks, and continuous connected-repository monitoring are surface-specific capabilities.[1][2][3][4][5]
The architecture should therefore begin with operating needs rather than a feature checklist.
Desktop for Interactive Investigation
The Security workbench brings scans, findings, and repositories together in the Codex desktop app. OpenAI documents starting scans, following progress, returning to saved scans, reviewing findings and evidence, and inspecting repository scan history.[2]
Select Desktop when a person is actively investigating and retained review context matters.
This surface fits work where an investigator wants to see the target, revision, progress, findings, coverage, and artifacts together—and return to that state later. The dominant architectural property is interactive visibility.
The workbench does not eliminate normal review controls. It gives the reviewer a durable place to examine the work before deciding what happens next.
CLI for Repeatable Engineering Workflows
The CLI runs Codex Security from a terminal. OpenAI documents local scans, saved scan history, change checks, bulk repository campaigns, CI workflows, portable artifacts, SARIF, cost limits, and false-positive feedback.[1][3][6]
Select the CLI when repeatability, automation, or engineering-workflow integration dominates.
That can include local execution, scripted checks, repository campaigns, pre-merge review, CI, or artifacts that another workflow must preserve. The CLI is the natural choice when the command, inputs, outputs, and exit behavior need to participate in a repeatable operating process.
The tradeoff is ownership. The surrounding engineering system must decide how credentials are provided, how outputs are protected, what constitutes a passing result, and who reviews the evidence.
TypeScript SDK for Embedded Orchestration
The TypeScript SDK allows an application or developer tool to initiate scans and manage the lifecycle in code. OpenAI documents typed findings, coverage details, artifact paths, preflight checks, progress callbacks, cost controls, and cancellation.[1][4][6]
Select the SDK when another system must own orchestration.
The consuming application can decide when a scan starts, how progress is presented, where results are stored, and how cancellation or cost boundaries are handled. This is different from merely invoking a terminal command: the scan lifecycle becomes part of another product or internal platform.
That flexibility also creates responsibility. The integrating system must preserve result integrity, protect credentials and event data, communicate incomplete coverage, and keep human review visible rather than hiding the scan behind a single pass-or-fail signal.
Cloud for Connected Repository Monitoring
Codex Security Cloud is a separate research-preview plugin for connected GitHub repositories in Codex cloud. OpenAI documents one-time scans, continuous scanning of new commits, findings review, threat-model refinement, and proposed patches that remain subject to review.[1][5]
Select Cloud when centralized connected-repository scanning or monitoring dominates.
This surface fits teams that want repository connections, scan state, findings, and commit monitoring associated with the Cloud workflow rather than constructing a local orchestration layer.
Cloud has its own prerequisites. Workspace access, GitHub connectivity, repository permissions, and a compatible Codex cloud environment affect whether the workflow can run.[5]
Five Questions for Surface Selection
The selection decision can be made with five questions.
- Who initiates the work? An investigator, developer, delivery pipeline, application, or repository owner?
- Where must it run? An interactive Codex task, terminal or CI environment, embedded application, or Codex cloud?
- How should it repeat? Ad hoc, scripted, event-driven, campaign-based, or continuously?
- Which system owns the evidence and operating state? The workbench, exported artifacts, a consuming application, or the connected-repository workflow?
- Where does accountable human review occur? Who evaluates the evidence and authorizes what happens next?
This is a selection lens, not a scorecard.
Desktop is not inherently more mature than CLI. Cloud is not inherently more governed than an embedded SDK. Automation is not automatically more scalable if ownership, evidence handling, and review are unclear.
The best surface is the one that fits the operating model while preserving the required evidence and decision boundaries.
Human Review Remains a Shared Boundary
The surfaces differ in who initiates the work and which system retains progress and results. They do not remove the need for accountable review.
A finding is not automatically a production incident. Validation is not universal proof. A proposed fix is not an approved merge. A draft pull request is not deployment authority.
Each implementation should make the review point explicit:
- Desktop should preserve the reviewer’s ability to inspect findings, evidence, coverage, and patches.
- CLI workflows should preserve artifacts and expose incomplete coverage or scan errors rather than reducing everything to a misleading success state.
- SDK integrations should present lifecycle state and results clearly enough for another person or system to review them responsibly.
- Cloud workflows should preserve patch and pull-request review rather than treating repository connectivity as change authority.
The interface changes. Accountability does not disappear.
Limits and Failure Boundaries
Codex Security Cloud is currently a research preview. Its availability, interfaces, prerequisites, and operating behavior can change.[1]
The public @openai/codex-security package is still pre-1.0, and OpenAI notes that minor releases may change its public API.[6] CLI and SDK implementation details should therefore be treated as current evidence, not permanent enterprise contracts.
Product access, workspace permissions, repository connectivity, compatible environments, credentials, and cost controls remain surface-specific dependencies. Saved logs, events, and artifacts can contain source code or credentials and require appropriate handling.[2][3][4][6]
The five-question selection lens and each “select when” rationale are Luminity architectural interpretations. OpenAI documents the surfaces and their current capabilities; it does not prescribe this enterprise selection framework.
Surface selection should follow the operating model: where work begins, how it repeats, which system owns progress and evidence, and where human approval occurs.
Choose Desktop for interactive investigation, CLI for repeatable engineering workflows, the TypeScript SDK for embedded orchestration, and Cloud for connected-repository scanning and monitoring—without treating those surfaces as interchangeable.
