Skip to main content
Large pull requests can generate many findings, which can clutter the review and make it harder to focus on what matters. Qodo addresses this by showing only a subset by default, the rest collapse behind View all and stay one click away, nothing is discarded. You can also control how each finding’s individual components (for example, description or code) are shown or expanded, separately for the summary comment and for inline comments. This page describes how to control what’s shown within a finding, not where it’s published. For choosing whether findings appear inline, in the summary comment, both, or not at all by severity, see Control review verbosity.
  1. Log in to the Qodo portal.
  2. Navigate to Configurations > Display.
  3. Configure the following settings:
  • Finding overflow: How many findings are shown before the rest collapse behind “View all.” Set under Overflow > Findings visible per group.
  • Per-finding verbosity: Whether each part of a finding is hidden, collapsed, or expanded in the summary comment. Set under Findings > Finding content sections.
  • Show content section titles: Shows a label above each finding part in the summary comment. Set under Findings > Show content section titles.
  • Inline comment sections: Whether each part of a finding is shown in the inline comment. Set under Findings > Inline findings.
  • Link finding summary to inline findings: Links a summary finding’s title to its inline comment. Set under Comment routing > Link finding summary to inline findings. Currently supported on Bitbucket and Gerrit only.
  • Resolved findings: Whether resolved findings are shown, where they appear, and how much of the resolved section is shown. Set under Resolved findings.

​
Configure findings visibility in .pr_agent.toml

​
Finding overflow

GitHubGitLabAzure DevOps
Control how many findings are shown before the rest collapse behind “View all”.

​
Resolved findings

Control whether resolved findings are shown, whether they stay in place or move to a separate section, and how much of that section is shown.
resolved_overflow_count applies only when resolved_findings_placement is "resolved_section". For more information about each value and how it renders by Git provider, see Track resolved findings.

​
Per-finding verbosity

GitHubGitLabAzure DevOps
For each part of a finding, control whether it’s hidden, shown collapsed, or shown expanded in the summary comment. Each part is controlled by two keys: render_* sets whether the part is shown at all, expand_* sets whether it’s expanded or collapsed when shown.
To hide a part entirely, set its render_* key to false. Agent prompt doesn’t set render_prompt by default. Unset, it falls back to the legacy show_prompt key (true), which combined with expand_prompt = false gives it a default of Collapsed, not Hidden. Setting render_prompt explicitly overrides show_prompt.

​
Show content section titles

BitbucketGerrit
Shows the section titles (Description, Code, Agent Prompt) above each finding part in the summary comment. Currently supported on Bitbucket and Gerrit only.
Default: false.

​
Inline comment sections

For each part of a finding, control whether it’s shown in the inline comment attached to the code line, separately from the summary comment. Each part is either shown or hidden.
Unset, inline_render_description and inline_render_prompt follow the summary comment’s render_description and render_prompt. inline_render_code, inline_render_evidence, and inline_render_recommendation stay hidden regardless of the summary comment’s settings.
BitbucketGerrit
When a finding is published as both a summary and an inline comment, link the summary finding’s title to its inline comment.
Default: true. Currently supported on Bitbucket and Gerrit only. On GitHub, GitLab, and Azure DevOps, the summary comment is published before the inline comments exist, so there’s no URL yet to link to, and the setting has no effect.