Security review for pull requests written by Codex

What Codex work becomes

Codex writes the change in the terminal, in a cloud task, or as a patch on a branch. GitHub stores a pull request. The security review, if you want one that is not the same agent that wrote the patch, has to be aimed at that pull request.

Business logic is where agent-written pull requests go quiet. The task said to add the export, the invite, or the plan change. The rule that used to decide who may do that lives in a helper the task did not name. The diff can be tidy and still move the rule.

What Codex Security's docs say

Quoted from OpenAI's Codex Security docs, retrieved 2026-10-03: Codex Security is an application security agent that helps security and engineering teams find, confirm, and fix vulnerabilities. The same page includes: before you merge a pull request or branch.

The even comparison, table against table, stays on the Codex Security compare page. This page does not score the two. The difference you can check without a benchmark is already in the sentences above. Aevral's finding is a lead with evidence. The fix is a prompt. A person applies it, or does not.

What to look for on a Codex pull request

Start with the business rule, not the feature. Who is allowed to take this action, which field decides it, and did the new code call that field or a copy of it. A plan name compared as a string, a role checked by label, an entitlement read from the request body: those are the business-logic shapes. The guide on business-logic access control walks one of each.

Then the ordinary authorization shapes. A lookup keyed by an id the caller chose. A route that forgot the tenant. Those are the same questions as on any other pull request. Codex did not invent them. It arrives with more of them, because it arrives with more pull requests.

Your options, in order of reach

Codex Security, as OpenAI documents it. The page includes: before you merge a pull request or branch. Use it if that is the workflow you want from the lab's agent. Installing it is their console, not this one.

Your own checklist on the business rule, using the business-logic guide, before you read the rest of the diff.

A second reviewer on the repository. The Aevral GitHub App reads the next pull request on the repositories you choose, including the ones Codex opens. At most five findings, advisory, with a fix prompt you can paste back into Codex. Nothing is applied for you.

From install to the first comment

One: install the Aevral GitHub App on the repositories you choose; a GitHub owner or admin approves the install. PR review is live on install: installing the App starts reviews on the next pull request, even before anyone signs in, and the owner can turn them off in Setup.

Two: sign in to the console with GitHub. That connects the install and starts a 14-day trial for private repositories: private reviews are free up to 500, and the trial ends at 14 days or 500 reviews, whichever comes first.

Three: open a pull request, or let your coding agent open one. Aevral reads the diff of the changed files, and the most security-relevant in full.

Four: read the result on the pull request. An advisory Check sits on the head commit, and when there is a grounded finding, inline comments sit on the added lines, at most five findings per review. Each finding carries the evidence, a suggested fix, and a Fix with your agent prompt a human can paste into Claude Code, Cursor, or Codex. Aevral never pushes, applies, or merges anything, and it never blocks a merge. You decide what ships.

What it looks for, and the published record

Aevral's PR review looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks, live on install. The whole-repo scan reads authorization, IDOR, and business-logic access control across the default branch.

The published record: on the Aevral receipts page, the PR review runs of 25 September 2026 read "10 of 12" (Run 1) and "11 of 12" (Run 2) on the frozen authorization slice of planted pull requests. In the page's own words: "Each recall number is the result of that named run on that corpus. It is not a product accuracy rate, and results on your code depend on your code."

Limits worth knowing: GitHub only (not GitLab, Bitbucket, or Azure DevOps). The review reads the diff of the changed files and the most security-relevant files in full; on a large pull request the most security-relevant files are reviewed first, and the review says which files it covered. It is not secret scanning, not dependency scanning, and not a general SAST.