Fix Review workflow

Fix Review is a verification workflow for known findings. It does not ask Apex to hunt for every new issue in the repository. It asks a narrower question: does this proposed target close the original finding?

• The finding should be valid, still relevant, and specific enough for Apex to compare the proposed fix against the original issue.
• The repository connection must still give Apex access to the repository and branch or pull request that contains the fix.
• The fix should be pushed before review starts. Draft work can use the agent handoff flow, but the review starts after Apex can see the branch, PR, or MR.
• One PR scan credit is required. PR Scan and Fix Review use the same PR scan credit pool.
• For linked PR or MR review, keep the change focused on the finding. Unrelated refactors make the result harder to trust.

The target determines the code Apex reviews. Pick the narrowest target that contains the fix and enough surrounding context to evaluate it.

1. 1
   Open the finding

   Start from the finding detail view or a row in the workspace findings browser.
2. 2
   Mark the fix target

   Attach one or more Fix PR or MR URLs when the fix is in review, or leave the selector empty to review the repository's current branch.
3. 3
   Confirm and start Fix Review

   Confirm the exact PR or current-branch target and the one-credit charge. Apex then queues a fix_review scan with the original finding, evidence, fix instructions, and selected code target.
4. 4
   Watch the finding card

   The finding shows queued or running state while Apex reviews the target and publishes the terminal result.
5. 5
   Act on the verdict

   A verified result closes the loop. Issues found, fix not made, failed, or cancelled results should be handled before the finding is treated as resolved.

Agent handoff is the path for teams using Codex, Claude Code, or another coding agent to prepare the fix before Apex verifies it.

1. 1
   Copy the agent fix prompt

   Use the Apex fix instructions when a coding agent is preparing the patch. The prompt includes the security closure criteria, constraints, and validation requirements.
2. 2
   Prove the regression first

   Before editing production code, the agent adds or identifies a focused regression test, runs it against the vulnerable baseline, and confirms that it fails for the expected security reason.
3. 3
   Fix, rerun, and document

   The agent applies the smallest root-cause fix, reruns the regression and adjacent checks, and records the exact before-and-after evidence and validation commands in the PR or MR description.
4. 4
   Create a focused PR or MR

   The agent keeps the change focused, adds "Fix prepared with Cantina Apex." to the description, and does not claim Apex verification before Fix Review completes.
5. 5
   Add the hidden marker

   When Apex provides a handoff marker, keep it in the PR body exactly as generated so the webhook can match the review request to the finding.
6. 6
   Post the start comment

   Post the generated Apex fix review command once on the PR or MR after the marker is present and the branch is ready for review.
7. 7
   Let Apex publish back

   Apex links the review to the finding, runs the scan, and publishes provider comments or checks when that integration is available.

Bulk Fix Review starts many targeted verification runs from one action. Use it after triage, when a set of known Todo findings has fixes ready on visible branches or provider review objects.

• Use filters first. The bulk action follows the current visible Todo finding set or the explicitly selected rows.
• Run preflight before starting. Apex checks eligibility, existing active reviews, already verified findings, repository access, and branch targets.
• Review branch selectors for each repository. Override the default branch when fixes live on a release or integration branch.
• Reconnect GitHub or GitLab when preflight reports missing access. Apex cannot verify code it cannot fetch.
• Expect some findings to be skipped. Skips are reported for already verified findings, active reviews, invalid findings, missing repository context, or unavailable connections.

• Turn on Auto-trigger fix review from the workspace schedule dialog when eligible Todo findings should be rechecked automatically.
• Scheduled Fix Review can run with or without recurring full scans. Use both toggles when you want broad coverage plus fix verification.
• Choose the branch Apex should inspect for scheduled rechecks. Use Workspace branch when fixes land on the workspace refs, or set a dedicated branch when fixes collect elsewhere.
• Scheduled runs use the same capacity, eligibility, access checks, and result model as manual Fix Review.

• No eligible findings: confirm the findings are Todo, valid, not already verified, and not already under active Fix Review.
• Wrong code target: update the Fix PR or MR URL, clear it to review the current repository branch, or override the bulk branch selector.
• Reconnect required: refresh the GitHub App installation or GitLab connection for the affected repositories.
• Provider result missing: read the Apex finding result first. Provider comments and checks are side effects and can lag behind the Apex result.
• Large unrelated diff: run a PR scan or a full Standard/Audit scan for new security questions outside the original finding.