Skip to main content
Fixing a finding is only half the loop — someone still has to confirm the fix actually worked. Automatic retests close that loop for you: link the pull request that fixes a finding, and when it merges, Odin reviews the merged code change and decides whether the finding is resolved. There’s no separate retest to request by hand, and the Odin MCP does not trigger a manual or paid retest. This sits at the end of the finding lifecycle, between Mitigating and Fixed & Retested. See Finding status for the full lifecycle.
Automatic verification reviews the merged code change. A finding with no linked pull request can’t be retested automatically — the merged diff is what the retest reads.

​
Prerequisites

Three things need to be in place for a retest to fire automatically:
1

Connect GitHub

Install the Borg GitHub App so Odin can read your repositories and receive pull request events. See the GitHub integration.
2

Turn on Automatic retests

On the GitHub card in Management > Integrations, enable Automatic retests. It’s off by default, and when off, merging a fix updates the linked PR’s state but doesn’t trigger a retest. The toggle only appears once retests are available to your organisation — if you can’t see it on the GitHub card, ask your Borg contact to enable them.
3

Link the pull request that fixes the finding

The fix has to be connected to the finding. Odin can do this for you, or you can do it by hand — the options are covered next.

​
Linking a pull request to a finding

Every finding has a unique, human-readable identifier made from your organisation’s finding prefix and a sequence number — for example BORG-12. It’s shown in the finding header and on every list row, and it’s how Odin connects a finding to your engineering work. When the GitHub integration is connected, Odin watches incoming pull requests for a {PREFIX}-{N} identifier in three places, in priority order:
  1. The branch name (highest priority)
  2. The pull request title
  3. The pull request body
If a token matches a finding in your organisation, that PR is linked automatically. Odin re-scans when the pull request is opened, edited, reopened or closed — pushing new commits on its own doesn’t re-scan, because the branch, title and body haven’t changed. The source it matched on is recorded against the link, and you can see it in the Link a pull request dialog. Odin also keeps a Linked Findings comment on the pull request itself, listing each linked finding with its severity, status, discovery date and a link back into Odin. It edits that one comment in place rather than posting a new one on every event. There are three practical ways to make a link happen.

​
1. Copy the generated branch name (fastest)

The finding detail header has a Copy branch name action. It gives you a ready-to-use git branch name that combines the identifier and a slugified title:
Paste it into git checkout -b, push your fix, and open the PR — because the identifier is in the branch name (the highest-priority source), the PR links automatically the moment it’s opened. This is the recommended path: nothing to remember, nothing to type.

​
2. Reference the identifier in the PR title or body

If you branched some other way, just mention the identifier when you open the pull request. Any of these link the PR automatically:
  • A title like BORG-12: fix SQL injection in login form
  • A body that mentions the finding, such as Fixes BORG-12
The same detection runs each time the PR is opened or edited, so adding the identifier to an existing PR links it too. Sometimes a PR fixes a finding without mentioning it anywhere Odin looks. Choose Link a pull request from the finding’s action menu to connect it by hand (needs the GitHub integration and permission to update the finding). The dialog lists recent pull requests, scoped to the finding’s repository when Odin knows it, searchable by number, title, author, or branch. Pick one to link it, or paste a GitHub PR URL if it isn’t in the list.
Only manually linked pull requests can be removed. Unlink one from the dialog if you picked the wrong PR — auto-linked PRs are managed by Odin and would be re-created on the next PR event.
If your repository also runs Mjolnir PR reviews, a completed review can link a pull request to a finding even when nothing in the branch, title or body mentions the identifier. The review reads the diff against findings Odin already knows about and records one of two relationships:
  • Fixes — the change addresses the finding. Odin links the PR and, if the finding is Reported or Acknowledged, moves it to Mitigating. The finding header shows an Auto-linked by PR review chip linking back to the review.
  • Worsens — the change makes the finding more exploitable. Odin links the PR, records a regression in the activity feed, and shows a Regression risk chip. If the finding had already reached Fixed & Retested, it’s reopened as Needs Revision.
Only the latest review counts. A redelivered or superseded review can’t flip a relationship backwards or reopen a finding a newer review has since resolved.

​
Linking through the Odin MCP

The Odin MCP server supports the same GitHub-first flow for coding agents. Ask the agent for ODI-12 to get the remediation, suggested branch, workflow blockers, linked PRs, and latest retest state. Create the branch, commit, push, and open the pull request yourself in Cursor or your normal development environment. Then explicitly ask the agent to use link_finding_pull_request with the existing GitHub URL. The MCP verifies the URL through the organisation’s GitHub App installation and stores the authoritative PR metadata. It does not create, modify, merge, or push the PR. Linking the same PR again is idempotent. A Read-only key can inspect context and read retest history with get_finding_retests, which never starts a retest or spends credits. Linking the PR or changing a finding status requires Read & Write.

​
What linking does to the finding

  • Linked PRs show as chips in the finding header, one per pull request. Each chip shows the PR number and follows its state on GitHub: open, merged, or closed. Hover a chip for the title, repository, author and when it was linked. To see how a PR was linked, open the Link a pull request dialog.
  • A PR linked to a Reported finding auto-transitions it to Mitigating, a clear signal to Borg’s analyst team that work is in progress. A finding already further along keeps its status — except a PR-review fixes link, which also advances an Acknowledged finding.
  • Merging a PR does not, on its own, move the finding to Fixed & Retested. In develop → staging → production workflows, merging to develop doesn’t mean the fix is live. What the merge does trigger is the retest below.

​
What happens when your PR merges

When a pull request linked to a finding merges, and the finding is still retestable (Reported, Acknowledged, Mitigating, Open for Retest, or Needs Revision), Odin queues an automatic retest — provided Automatic retests is on for the GitHub integration, the organisation’s retest automation capability is enabled, and the finding is eligible. A Mjolnir repository configuration is needed for live verification; code-analysis retests can use the merged GitHub diff without one. Odin then:
  1. Checks out your repository at the merge commit
  2. Extracts the code change the PR introduced (the diff between its base and head)
  3. Reviews that change against the original finding — is the root cause actually addressed, is the fix complete, can it be bypassed, and does it introduce any regressions?
The review looks past the symptom to the underlying cause (for example, SQL injection means checking for parameterised queries, not just that one string was escaped), and reads the surrounding files to confirm the fix holds across every code path.
The retest reads a snapshot of your code at the merge commit to run the review, then discards it. It never writes to your repository — no commits, no comments, no pull requests.

​
Retest outcomes

A retest that runs to completion resolves to one of three outcomes:
Fixed & Retested is the one status only Borg can confirm. An inconclusive retest leaves the finding open so you can adjust the fix and merge again, or move it to Open for Retest for Borg’s analyst team to verify by hand.
Two more states mean no verdict was reached. Retest skipped means it never started, for one of the reasons listed below, and Retest didn’t complete means something went wrong part-way. Both leave the finding’s status alone, and both show on the retest detail with the reason. Neither puts a chip on the findings list.

​
Following a retest

You don’t have to watch for the result — it surfaces across the Findings UI as it happens.
  • In the findings list, a chip appears next to the finding’s title: Retesting while the review runs, then Verified or Retest failed once it completes.
  • On the finding detail, a banner reports the same states — a fix being retested, a verified fix, or an incomplete fix that needs revision. On a finding sitting in Open for Retest with no result yet, the banner instead reads Not retested yet and offers a See how link.
  • Click View retest for the full picture:
    • The outcome and the reasoning behind it
    • A How this retest ran timeline — the pull request that triggered it, followed by the code review step and its verdict
    • A Spotted while retesting section listing any related issues Odin noticed while reviewing the change, each with the file, line, and a short description
    Where there’s no result to show yet, that same screen gives you the generated branch name to copy and a button through to opening a pull request on the finding’s repository.
Issues in Spotted while retesting are observations attached to the retest, to give you a heads-up — they aren’t raised as new findings automatically. Flag anything worth tracking to Borg’s analyst team in the finding discussion.

​
When a retest doesn’t run

A retest is skipped, rather than run, when:
  • The finding has no linked pull request — there’s no merged code change to review. Link a PR first.
  • The PR was merged before it was linked — linking a PR that’s already merged doesn’t retest retroactively. Move the finding to Open for Retest yourself when you’re ready for Borg to verify it.
  • Automatic retests is off for the GitHub integration, or the finding is already Fixed & Retested.
  • The finding is not in a retestable status. Resume mitigation or use Open for Retest when the lifecycle requires a different verification path.
  • A retest is already running for that finding. One runs at a time, so a second merge while the first is still in flight doesn’t queue another.
  • Your organisation is out of credits and auto-deposit is off. The retest is skipped and shown as such on the finding; top up or enable auto-deposit under Billing, then merge again or move the finding to Open for Retest.

GitHub integration

Connect GitHub and turn on Automatic retests

Findings

Track findings through the full remediation lifecycle