CodeCompass is a pluginable code comprehension server with a web front end

The unit of work is the whole project, not the open file

CodeCompass is described in one line as a pluginable code comprehension tool, and the emphasis in the feature list is on scale and navigation rather than on editing.

The features are listed as a user friendly web UI, fast navigation among source code elements, several languages supported, deep parsing for C, C++ and Java with more coming, many diagrams including call path, inheritance, aggregation and CodeBites, and scalability, described as quick response time even for a large 100Mb source code base.

Two of those deserve unpacking. The first is the diagram set. A call path diagram is the answer to a question an editor cannot answer, which is how a value or a failure reaches this function through the whole program. Inheritance and aggregation diagrams do the same job for a class hierarchy. CodeBites appears as a separate screenshot in the readme, alongside an info tree view, which suggests a decomposed view of a larger unit into smaller pieces.

The second is the 100Mb claim. That figure is the project's own, and it describes a single source tree in the tens of megabytes, which is where the architecture starts to pay for itself. Reading one file at a time is what an editor is good at, and the case for a separate comprehension tool appears when the question spans the tree.

The project description names C, C++ and Python as the target languages, with the caveat that deep parsing covers C, C++ and Java and that more is on the way.

The source tree is the architecture

The repository layout for a tool of this size is unusually readable, because the directory names map onto the stages of the pipeline.

parser/ holds the parsing side, model/ the domain model that results from it, service/ the layer that exposes that model, and webserver/ the HTTP front for it. util/ and logger/ are the supporting pieces, lib/ holds shared library code, and scripts/ holds the helper programs. There are two front ends: webgui/ and webgui-new/, the latter with its own development guide, which suggests a rewrite in progress rather than two alternative products.

plugins/ is the directory that explains the word pluginable in the project's own description. Language support lives there, since the readme's screenshots are pulled from paths inside plugins/cpp/webgui/images, including the C++ function call diagram and the detailed class diagram. A new language or a new kind of diagram is therefore a plugin rather than a change to the core.

Two more directories are worth noting for a first look. .devcontainer/ holds a container definition for development, and .gitlab/ holds the configuration for the GitLab pipeline, which the readme badges show is used for tarball packaging.

The AGENTS.md file at the root and the coding conventions document under doc/ are both signs of a project that expects outside contributions, since one is a guide for automated agents working in the repository and the other sets the house style.

CMake find modules name the dependencies the build expects

CodeCompass is a C++ project built with CMake, and the root of the repository shows the shape of that build.

The top level carries CMakeLists.txt alongside a set of supporting files: Config.cmake and Exports.cmake for package configuration, Functions.cmake for shared helper functions, Testing.cmake for the test setup, and three Find modules named FindODB.cmake, FindOpenLdap.cmake and FindThrift.cmake.

Those three find modules are the most informative thing in the listing, because a Find module is how a CMake project says that a dependency is not bundled and has to be located on the system. ODB is an object database generator, OpenLDAP provides the directory and database services, and Thrift is the interface definition format that appears in the project's topics. Together they indicate a server architecture with a database layer and a service layer behind the web interface, which is consistent with the persistence claim in the feature list: a codebase is parsed once into a store, and the queries behind those diagrams run against that store.

The dependencies in practice are documented separately. The development section of the readme points at doc/deps.md for building CodeCompass, which is where a new user should look first, since the find modules tell you what is needed but not how it is expected to be installed.

The other two build-adjacent files, SECURITY.md and LICENSE.txt, sit next to the sources in the same way, so the security contact route and the licence terms are part of the repository rather than hidden on a website.

Three documentation paths: backend, frontend and Docker

The readme keeps its documentation to a short list, and it is organised by who needs the document rather than by feature.

- [Backend user guide](doc/usage.md)
- [Frontend user guide](doc/webgui.md)
- [Docker guide](docker/README.md)

The backend guide covers using the tool, the frontend guide covers the browser interface, and the Docker guide covers deployment. That third entry is the one that matters most for an evaluation, because it is the difference between a research artefact you run on a workstation and a service you put in front of a team.

The development section follows the same split.

- [Building CodeCompass](doc/deps.md)
- [Frontend development guide](webgui-new/README.md)
- [Coding conventions](doc/coding_conventions.md)

Building instructions, a guide for working on the new front end, and the conventions to follow when contributing code.

The Docker guide and the devcontainer directory point in the same direction. Between them they suggest that running the tool does not require a bespoke local install, and that contributors are expected to work inside a container rather than assembling the dependency set by hand on a workstation.

For a first look without any of that, the readme links a live demo running on the LLVM source code. That is the fastest way to see what a comprehension view of a real C++ project actually looks like, and it also tells you what to expect the tool to be good at, since LLVM is a large, modern C++ codebase.

Deep parsing covers C, C++ and Java, and the rest is shallower

The limitation to plan around is in the language support, and the readme is precise about it.

The feature list says several languages are supported, and the project description names C, C++, C# and Python. Deep parsing is listed for C, C++ and Java, with more coming. So the distinction is between a language that is parsed deeply enough to produce trustworthy call path and class hierarchy information, and a language that is handled well enough to navigate but not to reason about.

For a C or C++ codebase, which is the case the tool is aimed at, that distinction is fine. For a project that is mostly C# or Python, it matters a great deal, because the diagrams are the reason to use the tool and a shallow parse produces diagrams of the wrong depth.

The second limitation is about packaging rather than capability. There are no GitHub releases, so there is no binary to download and no version to pin from a release page. The badges at the top of the readme show a build pipeline and a tarball packaging pipeline on GitLab, and the readme points to codecompass.net for the project, so the distribution path is the project's own site and pipeline rather than GitHub releases.

That is a real constraint for evaluation, since you will be building from source to try it, and the dependency set includes a database layer and directory services rather than a self contained binary.

GPL-3.0, no releases, and a push on 2026-10-14

The licence is GPL-3.0, and for a tool that people may want to run as an internal service and possibly extend with in house plugins, that is the first thing to check. It is a copyleft licence, so distribution of a modified version carries obligations, and the difference between running the tool as a service for your own team and shipping it to customers is a question for whoever handles your licence reviews rather than for this article.

The file is LICENSE.txt at the repository root, so the terms are available without leaving the source tree.

On maintenance, the repository is not archived and the last push was on 2026-10-14, which is recent. That tells you the code is being worked on. It does not tell you which plugin is being worked on, and since the language support lives in plugins/, that is the question that matters for an evaluation of a specific codebase.

The safest evaluation path is therefore concrete. Read the plugin list for your language, run the live LLVM demo to see the depth of the diagrams, use the Docker guide to stand an instance up without building the dependency set by hand, and only then decide whether the architecture, a parsed project in a database served over HTTP, is the one you want behind your team's code review process.

Editorial conclusion

CodeCompass fits a team taking on a large legacy C or C++ codebase where reading the code in an editor is not enough and a persistent, queryable model of the project is what people need. It is a poor fit if you need deep semantics for a language outside C, C++ and Java, if your workflow is a single file rather than a whole repository, or if a copyleft licence rules out your distribution model. Check first that the plugins directory covers the languages in your project, that the docker guide fits your deployment, and that the plugin you depend on is maintained in the same repository before you build your process around it.

Frequently asked questions

Official sources

1. Ericsson/CodeCompass on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README