CodeChecker: static analysis as a database, not a command

An infrastructure layer, not a fifth static analyzer

CodeChecker describes itself as analyzer tooling, a defect database and a viewer extension for static and dynamic analyzer tools, and the README frames it as static analysis infrastructure built on the LLVM/Clang Static Analyzer toolchain, replacing scan-build in a Linux or macOS development environment.

That framing is the thing to hold onto, because it determines what the project is not. It is not a checker. It does not find bugs by itself. It runs five other tools and then does something none of them do well: it stores the results, remembers what was already fixed, suppresses findings you have judged to be false, and shows you the difference between two runs.

The five analysers the README names are Clang-Tidy, Clang Static Analyzer with Cross-Translation Unit analysis and with Statistical Analysis where checkers are available, Cppcheck, GCC Static Analyzer and the Facebook Infer Analyzer. That last one is the signal about scope. Infer is a C, C++ and Java analyser, and its inclusion alongside four C and C++ tools suggests the storage layer was designed to be analyser-agnostic.

The storage layer really is analyser-agnostic. The README lists stored report types including Clang Static Analyzer, Clang Tidy, Facebook Infer, Clang Sanitizers, SpotBugs for Java, Pylint for Python and Eslint for Javascript, with a pointer to a supported-analyzers document for the complete list. A defect database that accepts ESLint output and Clang output through the same schema is what lets one web UI serve a polyglot organisation.

The project is Apache-2.0 licensed, has roughly 2,600 stars and 480 forks, its homepage is codechecker.readthedocs.io, and its topics span the languages it can store results for: c, cpp, objective-c, clang, clang-tidy, llvm, python and javascript, alongside analysis and static-analysis terms and a vue topic reflecting the web frontend.

The wiretap step is the part everything depends on

Static analysis needs to know how your project was actually compiled: every include path, every define, every flag. Guessing is how tools produce thousands of bogus findings. CodeChecker's answer is to sit beside your build and record what the build really did.

The README describes creating the JSON compilation database by wiretapping any build process, and gives the command form directly: CodeChecker log -b "make". The build command is quoted, so this works with make, ninja, a shell script or anything else that shells out to the compiler. The log subcommand, in the README's own subcommand table, runs a build command, collects the executed compilation commands and stores them in a JSON file.

Once that database exists, the analyze subcommand runs the analysers over the files it records, and the check subcommand is the shortcut that performs analysis on a project and prints results to standard output. That last one is the honest starting point: a single command that tells you what the tool finds on your code today, with no server and no database to configure.

Two features around that core are what make incremental use practical. The README lists incremental analysis, where only changed files and their dependencies need reanalysing, and automatic analysis of GCC cross-compiled projects, which works by detecting the GCC or Clang compiler configuration and forming the corresponding clang analyser invocations. The second is the one that trips people up on embedded toolchains, and the fact that it is a listed feature rather than an accident of design says the project has seen that problem.

A defect database, with reviews attached to the findings

The web-based report storage section is where CodeChecker stops looking like a wrapper and starts looking like a system.

It stores and visualises thousands of analysis reports across many analysers, and it is a web application for viewing discovered code defects, backed by either PostgreSQL or SQLite. That database backend choice is worth noting: SQLite means a single engineer can get a local server running in a few minutes, and PostgreSQL is what a team or a CI cluster would use.

Around that store sit the features that address the reason static analysis usually dies. False positive suppression with a possibility to add review comments means a finding is not just an assertion but an object you can annotate. Results are filterable by checker name, severity and source paths, and comparable, meaning the tool calculates the difference between two analyses of the project and shows which bugs were fixed and which are newly introduced. Diff mode is the narrower version of that: the list of bugs introduced since your last analyser execution.

The last feature in that list is the one that decides whether a team actually keeps the tool. Review comments on findings mean a developer can argue about a defect in the same place they argue about code, rather than in a separate spreadsheet.

The transport underneath is described as easily implementable Thrift-based server-client communication used for storing and querying discovered defects, and the README mentions multiple visualisation frontends: the web application, a command-line tool and an Eclipse plugin. The `CodeChecker cmd` subcommand is the command-line path into a running server, with its own subcommands for runs, history and results. So the same stored defect can be read three ways, which matters when the person triaging a build failure is on a terminal and the person planning a sprint is in a browser.

Review integration is the difference between a report and a gate

Two integrations in the README deserve separate attention, because they change who has to care about static analysis.

The first is Gerrit and GitLab integration, which shows analysis results as GitLab or Gerrit reviews. A defect then arrives attached to a line of code, at the point where someone is already reviewing a change. That is a categorically different experience from opening a web UI and reading a list of four hundred findings. The repository also ships a Gerrit-specific skipfile helper, visible in the Makefile as a packaging step that copies a script called gerrit_changed_files_to_skipfile.py into the binary directory, which implies the intended workflow is to restrict analysis to changed files when integrating with Gerrit.

The second is the command line fixit feature. The subcommand table describes fixit as applying automatic fixes based on the suggestions of the analysers. Static analysers have suggested mechanical fixes for a long time, and the usual outcome is that nobody applies them. A subcommand that applies them turns a finding into a diff you can review, which is a much cheaper unit of work.

Between the review integrations and fixit, the picture is of a tool designed to sit inside an existing review process rather than to export a report and hope. The docs point separately to a Gerrit integration page and a GitLab integration page, and there is a public demo instance linked from the README showing analysis results from open-source projects, which is the fastest way to see what a populated database looks like before you have one of your own.

Backward incompatible changes ship in the notes, in plain language

The most useful part of the release history is how explicitly the project communicates breaking changes. The v6.29.0 notes, published in September 2026, open with a heading for highlights and then a heading for backward incompatible changes, and list three of them.

The first is a rename: GCC Static Analyzer checkers move from a gcc- prefix to a gcc-analyzer- prefix, so gcc-out-of-bounds becomes gcc-analyzer-out-of-bounds. The second is a removal: the CodeChecker analyze --z3 flag is gone, because the Z3 constraint solver is unsupported by Clang Static Analyzer, though Z3 for refutation can still be used. The third is another removal, this time of the deprecated CodeChecker analyze --tidy-config flag, with the replacement given as CodeChecker analyze --analyzer-option clang-tidy:take-config-from-directory=true.

Two things stand out. Every removal names its replacement, so a migration is a find-and-replace rather than an investigation. And the Z3 removal explains itself with a reason, which tells you the flag was there on someone else's schedule rather than through a considered design choice.

The same release adds a file tree view that shows how reports are distributed within files and directories, aimed at finding hot-spots, being the problematic files with the most reports. You can filter paths with wildcards, sort by severity or review status, and pick paths with checkboxes. The tree opens to the first folder that branches, and both the view mode and the set of open folders are saved in the URL, so a shared link reproduces the same view. That last detail is a small piece of care that says the feature was designed around real sharing conversations.

The version cadence itself is recent and regular: v6.29.1 on 17 September 2026, v6.29.0 on 8 September 2026, and v6.28.3 before that, with the last recorded push to the repository on 23 September 2026.

What the directory layout says about the build

The repository root lists what the project actually is made of, and the directory names are more informative than the marketing.

There is web/, which holds both a server and a client directory, matching the README's claim of a web application with multiple frontends. There is analyzer/, codechecker_common/ and codechecker_api/, the three Python packages that mypy is configured to check, with pyproject.toml listing codechecker_common/, tools/ and analyzer/ as the files to check and excluding tests, setup.py files and build directories.

There is bin/ for the command-line entry point, tools/ for helper scripts such as the memory safety reporter, scripts/ for maintenance scripts, config/ for configuration, tests/ split into unit, functional and libtest directories, and ci/ for pipeline definitions. Two packaging systems sit side by side: a snap/ directory for Snapcraft packaging, and an sdist setup.py that reads requirement files from both analyzer/ and web/ and installs documentation into a share/codechecker data directory.

The Makefile is where the build story becomes concrete. It includes Makefile.local as an optional override, which is the standard Go-adjacent and Python-adjacent convention for local configuration. It defines BUILD_DIR and PYTHON_BIN with overridable defaults, sets the default target to package, and stages a directory structure with mkdir calls for bin, lib/python3 and www. The package target depends on several preparatory steps including a git commit template setup, the Gerrit skipfile script and the memory safety reporter, then recurses with make into codechecker_api, into analyzer for a package_analyzer target, and into web.

The presence of a BUILD_LOGGER_64_BIT_ONLY switch, documented in a comment as building 64-bit-only shared objects and the ldlogger binary, tells you that the wiretapping layer is compiled native code rather than implemented purely in Python. That is consistent with a tool whose whole premise is intercepting a build process without slowing it down unacceptably.

For documentation, mkdocs.yml, readthedocs.yml and a docs/ directory point at the same MkDocs setup that publishes codechecker.readthedocs.io, and there is a mkdocs_build target in the Makefile.

Editorial conclusion

The concrete next step for anyone evaluating CodeChecker is to run CodeChecker log -b "make" against a real project before installing any server: if the wiretap step records a complete compilation database from your build, the rest of the pipeline works, and if it does not, no amount of server configuration will recover the missing compile flags.

Frequently asked questions

Official sources

1. Ericsson/codechecker on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases