Fix and verify security findings

Use Codex Security to turn an accepted security finding into a focused, verified patch. You can work in the Security workbench or run the remediation workflow from a prompt, the command line, or CI/CD. Codex validates the issue and, when testing is safe and practical, adds a focused regression test that fails before the fix and passes after it. It also checks that legitimate behavior still works. If a regression test is unsafe or infeasible, Codex records the proof gap and provides the strongest repeatable validation artifact instead.

Start by fixing one accepted finding so you can evaluate the patch and verification quality. Once the workflow meets your standards, scale it across more accepted findings by processing each finding in a separate task or CI/CD job. Keeping each fix scoped makes the code changes and evidence easier to review.

Fix a finding in the UI

Open an accepted finding from Findings or a completed scan in Scans. Review its evidence, then use Patch to generate, review, apply, and verify one focused fix.

1. Generate a focused patch

   Open the finding, select the Patch tab, and select Generate patch. Codex validates or reproduces the issue when feasible and writes a patch artifact without modifying the selected checkout.

2. Review the proposed diff

   Read every changed source, regression test, and validation artifact. Reject broad refactors, unrelated cleanup, or changes that weaken another security control.

3. Apply the patch locally

   Select Apply patch only after the diff is acceptable. Codex applies the exact generated patch to the working tree and records that state. Review the working-tree diff before continuing.

4. Verify the fix

   Select Verify fix. Codex reruns the original reproducer or the strongest available exploit check. If a regression test is safe and practical, Codex checks that it fails before the fix and passes after it. If the test is unsafe or infeasible, Codex records the proof gap and provides the strongest repeatable validation artifact instead. It also checks legitimate behavior, nearby bypasses, and relevant repository tests.

5. Close the finding deliberately

   Verification doesn't automatically close a finding. Review the commands, results, and remaining proof gap, then close the finding with an accurate reason or keep it open for more work.

Fix a finding from the CLI

Use the Codex CLI when you already have a finding from a scan, ticket, advisory, disclosure, security assessment, or internal review:

The commands below assume Codex Security is already installed in the CODEX_HOME used by codex exec. A fresh CI runner doesn't have marketplace plugins installed by default.

Use $codex-security:fix-finding to fix finding <finding-id> from <report-path>. Validate the issue, make the smallest safe change, and add a focused regression test that fails before the fix and passes after it. If that test is unsafe or infeasible, record the proof gap and provide the strongest repeatable validation artifact instead. Verify that the issue no longer reproduces.

Include the known source, sink, attacker input, impact, expected invariant, reproducer, affected files, and validation command. Codex can inspect the repository for missing technical details, but it should ask before guessing a product policy or intended security invariant.

For an automated run, pass the prompt to codex exec after checking out the code, making the finding report available, and provisioning the plugin in that CODEX_HOME:

codex exec --sandbox workspace-write 'Use $codex-security:fix-finding to fix finding <finding-id> from <report-path>. Validate the issue, make the smallest safe change, and add a focused regression test that fails before the fix and passes after it. If that test is unsafe or infeasible, record the proof gap and provide the strongest repeatable validation artifact instead. Verify that the issue no longer reproduces.'

Scan and fix findings in CI/CD

Provision Codex Security in the runner's CODEX_HOME before invoking these skills. The command below uses the installed plugin; it doesn't install the plugin itself.

In CI/CD, separate the change scan from remediation and require the scan to leave the checkout unchanged. Preserve the completed scan directory as a job artifact, review the findings, and start a separate Codex task or job for each finding accepted for remediation.

Run both the change scan and remediation with --sandbox workspace-write. The scan needs that permission to save temporary artifacts, but its prompt must still require Do not modify the checkout. Remediation needs the same permission to write the focused patch and verification evidence.

1. Resolve the base and head revisions for the change.
2. Run $codex-security:security-diff-scan against that diff without modifying the checkout.
3. Preserve the complete scan directory and select the findings to fix.
4. Invoke $codex-security:fix-finding once for each accepted finding.
5. Generate one focused patch and a regression test that fails before the fix and passes after it, or record why that test is unsafe or infeasible.
6. Verify the original issue and legitimate behavior independently.

First, scan the change without modifying the checkout:

codex exec --sandbox workspace-write 'Use $codex-security:security-diff-scan to review changes from <base-revision> to <head-revision> for security regressions. Do not modify the checkout.'

Then fix one accepted finding from the completed scan:

codex exec --sandbox workspace-write 'Use $codex-security:fix-finding to fix finding <finding-id> from <completed-scan-directory>. Validate the finding, generate one minimal patch, and add a focused regression test that fails before the fix and passes after it. If that test is unsafe or infeasible, record the proof gap and provide the strongest repeatable validation artifact instead. Verify that the issue no longer reproduces.'

Repeat the second command in an independent task or job for each remaining accepted finding. After verification, merge each patch through your normal code-review and release process.