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.
• Each Fix Review uses 25 standard credits, the same cost as a PR Review.
• 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 the finding's GitHub, GitLab, or company-enabled Forgejo provider 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.

Fix Review cannot verify a patch unless Apex can fetch the affected repository, branch, and pull request. Reconnect the workspace when preflight reports a GitHub access problem.

1. 1
   Open workspace settings

   Use the link in the blocked scan notice, then open the GitHub repositories section.
2. 2
   Select the owning organization

   Use Connect when no active installation exists. Otherwise use Change account or Manage on GitHub.
3. 3
   Update repository access

   Include the affected repository and approve Contents: Read. PR-targeted Fix Review also needs Pull requests: Read.
4. 4
   Save and retry

   Return to Apex, confirm the repository is selected, save the workspace, and rerun 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: follow the GitHub reconnect checklist for repository access, Contents: Read, Pull requests: Read, and organization IP allowlist blockers. Refresh the GitLab connection for GitLab targets.
• 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.

Forgejo support is available when an administrator enables Forgejo in the company’s Beta settings. Connect a reachable HTTPS instance using a dedicated bot and repository-scoped tokens. The read token needs repository read access; an optional write token enables PR statuses, comments and webhook installation. A repository administrator can install the webhook manually if the bot cannot manage hooks.

$ apex connect forgejo --company acme
$ apex scan https://git.example.com/team/service
$ apex scan --mode pr --pr https://git.example.com/team/service/pulls/42
$ apex findings fix-review ACME-25 --fix-pr-url https://git.example.com/team/service/pulls/42

For an existing Apex workspace, bind its name or prefix with apex workspace use ACME --company acme before running apex doctor --json. In plannedSources, the repository should use provider: forgejo and materializationAuth: connection. Custom HTTPS hostnames resolve through the company’s saved connections.

• When creating a workspace, select Forgejo alongside GitHub and GitLab. Reuse a connection you own (administrators can reuse any company connection), or connect an instance in the dialog, select repositories and branches, PRs or commits, then continue to context and Standard or Audit scan setup.
• The Forgejo repositories and scans page connects selected repositories to a workspace and starts repository or PR scans. CLI and MCP use the same company connection.
• Enable automatic PR scans when connecting, or comment /apex scan as a repository collaborator with write access. Signed fix handoff markers attribute a PR to its original finding and start Fix Review.
• PR and Fix Review results publish against the reviewed head commit. Draft and fork PRs are excluded. A push refreshes a linked Fix Review; merged and closed PRs update the finding review state.
• Forgejo uses Standard, Audit, PR and Fix Review scans. Lite, guest and demo flows retain their existing providers. Tokens stay on the server and are not returned to CLI or MCP.
• The hosted integration requires an internet-reachable HTTPS endpoint. Private-only instances require an additional connector before enabling this integration. Every repository is checked against its saved instance and repository ID.