Codex Security Cloud: What It Scans and What It Won't

Codex Security Cloud is a new OpenAI tool that scans GitHub repositories for security holes, investigates what it finds, and prepares fixes in the cloud. OpenAI announced it at DevDay on 29 September. The Decoder reports that it scans entire repositories on demand or on a schedule, keeps checking new commits as they arrive, and is available on Pro, Business, Enterprise and Edu plans on desktop and web.

What Codex Security Cloud does

The OpenAI developer community thread on DevDay lists four jobs: vulnerability scanning, investigation of what turns up, deduplication of repeated findings, and fix preparation. The Runtime Wire keynote roundup says GitHub support is generally available.

It sits alongside the other Codex changes from the same keynote, including persistent cloud environments. Those are covered in our report on OpenAI Codex cloud.

Why this matters if an agent writes your code

When a coding agent produces a feature in an hour, the bottleneck moves to review. Nobody reads every line, and the lines nobody reads are where security bugs live. A scheduled scan that also watches new commits is aimed at exactly that gap. Our list of signs your AI coding agent is about to introduce a security bug describes what those bugs tend to look like.

What an automated scan leaves to you

The next section is my own judgment about scanners in general, not a claim about how Codex Security Cloud performs. Nothing I read this run described its detection coverage or false-positive rate.

A repository scan can only see the repository. Several of the most damaging mistakes in AI-built apps live elsewhere or depend on meaning that code alone does not show:

• Authorization rules. A scan can spot a missing check that looks like a known pattern. It cannot know that customer A must never see customer B's invoice unless you told it.

• Secrets outside the repo. Keys pasted into a dashboard, a chat, or a hosting setting never appear in the code. Our guide to environment variables and secrets in an AI-built app covers where they should live.

• Database access rules. Whether a table is readable by anyone is a setting in your data platform, not a line in your source.

• The agent's own permissions. What your coding agent is allowed to touch is a separate question from what it wrote.

Treat every prepared fix as a pull request from a stranger and read it before merging, using the routine in how to review AI-generated code before you ship it.

A sensible order of operations

If you do turn a scanner loose on a repository, the order in which you work through the output matters more than the tool.

1. Start with one repository that has real users, not your whole account. The first run will be noisy, and noise is easier to triage in a small codebase.

2. Sort findings by what an attacker would gain, not by the order they appear. Anything touching login, payments or customer data goes first.

3. Reproduce the serious ones yourself before accepting a fix. A finding you cannot explain is a finding you cannot verify.

4. Merge fixes one at a time so a bad patch is easy to revert.

5. Keep the scheduled scan running after the first clean-up, because the value of continuous checking is catching the next regression, not the old backlog.

What the sources leave open

• Pricing or scan quotas. No source I read gave either.

• Whether fixes arrive as pull requests or as patches you apply yourself. The coverage says "prepares fixes" and stops there.

• Support beyond GitHub. Runtime Wire mentions GitLab only for the code review feature, where it is in preview.

• How well it performs. There is no independent evaluation yet, which is normal one day after a launch.