Codex Security Cloud setup: connect GitHub and run a first scan

By Rogier Muller09.29.26
Codex Security Cloud setup: connect GitHub and run a first scan

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

Codex Security Cloud is a ChatGPT plugin that scans connected GitHub repositories in Codex cloud, validates likely vulnerabilities, and watches new commits. Setup is five steps: install the plugin, connect GitHub, pick a Cloud environment, start a Repository scan, then turn on commit monitoring. The Codex Security Cloud setup guide is the primary source for everything below.

OpenAI announced the cloud version at DevDay on 29 September 2026. This walkthrough covers a first scan on one repository and what to check before Codex opens a pull request for you. Our earlier piece, codex-security tests the repo boundary, covered the open-source CLI. This is the hosted counterpart: no local state directory, no CI job, and the scan keeps running with your laptop closed.

Who can use Codex Security Cloud today?

The DevDay recap lists Codex Security Cloud for all Pro, Business, Enterprise and Edu users on desktop and web. The Codex Security overview page still labels the cloud offering a research preview. Plan for changes in the UI and in what a finding contains.

You need three things before the first scan: a workspace with Codex Security Cloud access, a connected GitHub repository, and a compatible Codex cloud environment. If the plugin is missing from your marketplace, the docs send you to your workspace administrator.

There are now three Codex Security surfaces, and they are easy to mix up:

Surface Where it runs Use it for
Codex Security Cloud plugin Codex cloud, opened from ChatGPT web or desktop Scanning connected GitHub repositories and monitoring commits
Codex Security plugin A local Codex task in the desktop app Scanning a local checkout
@openai/codex-security CLI and SDK Your machine or CI Scripted and pipeline scans

The recap also says Codex Security Cloud includes access to models offered through Daybreak Blue, without a separate Daybreak application. OpenAI's models page describes Daybreak Blue as an alias for flagship general-purpose models with safeguards for defensive cybersecurity work. The setup docs do not say which model a given scan uses.

Codex Security setup in five steps

This is the documented procedure, in order.

  1. Open Plugins in ChatGPT on the web or desktop app. Search the marketplace for Codex Security Cloud, install and enable it, then open Security Cloud from your installed plugins or the sidebar.
  2. Confirm Codex cloud is set up for your workspace. In the plugin, select New scan. If prompted, select Connect GitHub and grant access only to the repositories you want scanned.
  3. In New scan, choose the repository and a compatible Cloud environment, or select Create environment if none exists. Leave What to scan on Repository, the default, and select Start scan.
  4. Follow progress under Scans. When the scan finishes, open Findings and select an issue to see the affected code, validation evidence and remediation guidance.
  5. For ongoing checks, select New scan again, pick the same repository and environment, set What to scan to Commit changes, and select Create.

A repository missing from step 3 usually means the GitHub connection or its permissions do not include it. Fix that grant for the one repository. Do not widen access to the whole organization to make the list look complete.

Pick the Cloud environment before you scan

The environment decides what the scan and its validation jobs can run. Per the Cloud FAQ, each analysis and validation job runs in an ephemeral Codex container with session-scoped tools, and the container is torn down after the job. Auto-validation tries to reproduce a suspected issue in a clean container. It records logs, commands and artifacts as evidence.

The FAQ says the project does not need to compile for Codex Security to produce findings. Validation can only reproduce what the environment can run, though. If a code path needs a specific runtime or service to execute, reuse the Codex cloud environment your team already runs Codex tasks in. The reproduction then runs against a setup you already trust.

A finding that fails validation stays unvalidated. The logs still capture what was attempted, so an engineer can retry or adjust the reproduction steps.

Review the first finding before Fix with Codex

Findings arrive ranked, with criticality, validation evidence, remediation guidance and a proposed patch when one is available. The recap adds that Codex removes duplicate findings. Codex Security does not auto-apply patches. When a finding offers Fix with Codex, the plugin generates a proposed patch, and you review it before selecting Create draft pull request.

Use this review order on your first scan:

  • Read the validation evidence first. Validated means Codex reproduced the issue in a container. Unvalidated is a lead to investigate.
  • Trace the affected code path yourself. Check that user-controlled input actually reaches it.
  • Read the proposed diff as security-sensitive code. The FAQ describes it as a minimal diff with file and line context.
  • Check whether a test proves the fix. If the patch has none, add one to the draft pull request before review.
  • Open a draft pull request only for findings you would defend in a code review.

The FAQ is direct that Codex Security complements SAST and does not replace manual security review. Keep your existing scanners running while you learn how the two sets of findings overlap.

Monitoring new commits and the threat model

Commit monitoring is set per repository. Open Repositories, select the repository, and open Monitoring settings. You can change the Cloud environment, choose how many days of history to review, and pause or enable monitoring. Select Save to apply.

The recap mentions scans on demand or on a schedule. The setup page documents one-off Repository scans and Commit changes monitoring, and it does not show a separate schedule control yet. Check the plugin in your own workspace before you promise anyone a weekly full scan.

Under Project context you will find the generated threat model. OpenAI's threat model guidance calls it a short security summary of how your repository works. Codex Security uses it to guide future commit scans and prioritize findings. Edit it on day one and add:

  • entry points and untrusted inputs
  • trust boundaries and auth assumptions
  • sensitive data paths or privileged actions
  • the areas your team wants reviewed first

Changes apply to future scans. If the repository already has a SECURITY.md or an AGENTS.md with security rules, copy those facts in rather than rewriting them from memory. OpenAI's Daybreak material names SECURITY.md as shared system context for security work.

A first week with Codex Security Cloud

Our methodology treats every accepted finding like any other delegated Codex task: a clear scope, evidence attached, and a named person who owns the merge. A calm first week looks like this.

  • Day one: run a Repository scan on a service you know well, then edit its threat model.
  • Day two: triage the findings with the service owner and separate validated from unvalidated.
  • Day three: use Fix with Codex on one validated finding, open the draft pull request, and let your normal CI run.
  • Day four: turn on Commit changes monitoring with a short history window.
  • Day five: compare what monitoring flagged with what your existing scanners flagged on the same commits.

Install the plugin today, run one Repository scan on a repository you own, and edit its threat model before the first commit scan runs.

Further reading