> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Track resolved findings in pull requests

> How Qodo detects that a finding was fixed, and how to show resolved findings in place, in a separate section, or not at all.

As you push commits to a Pull Request (PR), Qodo checks which findings you have addressed and marks them resolved in the review comment. By default, resolved findings stay visible and struck through, which lets you see your progress toward a clean PR. You choose where they appear: in place within their group, in a separate section after the open findings, or not at all.

## How Qodo detects a resolved finding

Each time Qodo reviews a new commit, it re-evaluates every finding that's still open against the changes made since the finding was raised.

* Qodo looks at the full set of changes in the PR, not only the code the finding pointed to. A fix counts even when it lands somewhere else, for example in a new file or in a helper the finding did not mention.
* A finding is marked resolved when the changes address the issue it describes. Findings that the changes do not address stay open.
* When the full set of changes is not available, for example for a very large change set, Qodo checks the code the finding pointed to.

All three statuses count as resolved findings. Each resolved finding carries one status:

| Status | Description |
| - | - |
| ✓ Resolved | A later commit fixed the issue. |
| ✗ Dismissed | The finding was dismissed without a fix and no longer needs action. |
| ⊖ Outdated | The code the finding referred to was removed or rewritten. The finding no longer applies. |

## How resolved findings appear

A resolved finding keeps its title, struck through, followed by its status. It drops the other labels a finding usually carries, such as finding type, category, severity, or the ⭐ New mark. This keeps resolved findings in the background and makes the open, actionable findings stand out, which helps you focus on resolving them.

Where the finding also has an inline comment, Qodo marks that comment as resolved, if your Git provider supports it.

## Placement

| Placement | What you see |
| - | - |
| Resolve in place (default) | Resolved findings stay in their original group, struck through, in one running count with the open findings. |
| Move to resolved section | Resolved findings move to a Resolved findings section after the open findings. The open findings count from 1, and the resolved section counts from 1 again. The numbers in your groups reflect only the findings that still need action. |

## Resolved findings overflow

With resolved findings in their own section, the overflow setting controls how much of the section is shown.

| Setting | GitHub, GitLab, and Azure DevOps | Bitbucket and Gerrit |
| - | - | - |
| None (default) | The section is collapsed behind its title. Expand it to see every resolved finding. | Shows only the count, such as 2 of 9 resolved. |
| 1, 3, or 5 | Shows that many resolved findings, with the rest behind **View resolved (N)**. | Shows that many resolved findings, followed by a count such as 7 of 15 resolved (3 displayed). |
| All | Shows every resolved finding, with no collapse. | Shows every resolved finding. |

Bitbucket and Gerrit do not support collapsible sections. As a result, resolved findings beyond the overflow breakpoint are not displayed. You can view them in the Qodo portal instead.

## Hide resolved findings

Turn off Show resolved findings to leave resolved findings out of the review comment entirely, regardless of placement. Open findings count from 1.

## Configure resolved findings

### Set using the Qodo portal (Recommended)

<Steps>
  <Step>
    Log in to the Qodo portal.
  </Step>

  <Step>
    Navigate to **Configurations** > **Display** > **Resolved findings**.
  </Step>

  <Step>
    Choose the options:

    * **Show resolved findings**: Whether resolved findings appear in the review comment.
    * **Placement**: Resolve in place, or Move to resolved section.
    * **Resolved findings overflow**: How much of the resolved section is shown. Applies only when Placement is set to Move to resolved section.
  </Step>

  <Step>
    Click **Save**.
  </Step>
</Steps>

The **Live preview** shows the result for the Git provider you select. See [Display tab](/configuration/display#resolved-findings).

### Set using .pr\_agent.toml

```toml theme={null}
[review_agent_ux]
show_resolved_findings = true
resolved_findings_placement = "resolved_section"
resolved_overflow_count = 0
```

| Key | Value | Behavior |
| - | - | - |
| `show_resolved_findings` | `true` (default) | Shows resolved findings in the review comment |
| | `false` | Leaves resolved findings out of the review comment |
| `resolved_findings_placement` | `"in_place"` (default) | Keeps resolved findings struck through in their original group |
| | `"resolved_section"` | Moves resolved findings to a separate section after the open findings |
| `resolved_overflow_count` | `0` (default) | None. The resolved section is collapsed behind its title |
| | `1`, `3`, `5` | Number of resolved findings shown before the rest are hidden |
| | `-1` | All. Every resolved finding is shown |

`resolved_overflow_count` applies only when `resolved_findings_placement` is `"resolved_section"`. See [Configure Qodo using the .pr\_agent.toml file](/configuration/configuration-file).

## Related resources

* [Comment anatomy](/code-review/comment-anatomy): The parts of the review comment and how to read them.
* [Control findings visibility](/code-review/findings-visibility): How many open findings are shown before the rest collapse.
* [Persistent review comments](/code-review/persistent-review-comments): How Qodo updates one review comment across commits.