Run CodeCheck automatically in the background

Background checking runs your selected checks whenever the project is analyzed and shows results inline next to your code.

Turn it on

1. Checks → Select Checks to open the Manage Configurations window.
2. Pick an existing configuration, or click New to create one and choose the checks you want.
3. Enable Run in Background and Save.

That's it — from then on CodeCheck runs automatically after each analysis.

When it runs, and over what

Two things kick off a background run:

• Saving the configuration with Run in Background enabled starts one immediately, over every file in the project — so expect one full-project pass the first time you turn it on. The Violation Browser opens itself the very first time a project runs background checks, so you can see what appeared.
• Finishing an analysis starts one over just the files that were analyzed. So after Analyze Changed Files, only the changed files are rechecked — their previous violations are replaced and the rest of the project's results stand. An analysis you abort doesn't trigger a run.

Runs appear as a Background Analysis task in the task list. Toggling Run in Background on while one is already going cancels it and starts fresh.

Run in Background is per configuration, and they stack

It's a flag on each configuration, not a single global setting — every configuration that has it enabled runs on every trigger. Turning it on for a broad standard and a focused custom configuration means both run each time, so keep an eye on how many you've enabled. The list is saved with the project's settings, so it's shared with anyone who opens the project.

Reading the results in the editor

• A spinning icon (top-right of the editor) shows a background check is running.
• A warning icon next to it shows the number of violations in the current file; click it to jump to the Violation Browser.
• The up/down arrows step to the previous/next issue in the file.

See View & triage violations for the browser.

Suppressions behave differently than a full run

Background runs honor only the suppressions that live in your source — UndCC_ suppression comments and annotations. They deliberately skip the project-side ignore data: marked false positives and baselines are not applied.

That's usually what you want while editing — you see what the checks actually found in the code in front of you — but it means the background count for a file can be higher than the count from a full run of the same configuration. Gate CI on an explicit run (und codecheck), not on the background numbers. See Suppress a violation for which suppression method lands where.

Cost

Background checks re-run on every analysis, so their cost is paid repeatedly rather than once. Configurations built from a large published standard — or ones including Bug Hunter, whose interprocedural checks are the most expensive Understand ships — are better run on demand or in CI than in the background. A focused configuration of the rules you actually act on while editing is the one worth leaving on. If analysis starts feeling slow, see performance on a large codebase.

If you edit in VS Code, the Understand extension surfaces CodeCheck violations there too (see use an external editor).