Coverage Gutters paints lcov results into the editor margin

Two rendering modes and why you may need only one

The extension paints coverage in two places, and the interaction with debugging is the part worth knowing before you install it. The README has a specific tip for this: to use the extension and code debugging breakpoints at the same time, you need to disable the gutter coverage and enable the line coverage, through the coverage-gutters.showGutterCoverage and coverage-gutters.showLineCoverage settings respectively. The reason is that the gutter is where the breakpoint markers live, and the extension's gutter marks collide with them. The design gives you a choice, and the choice is forced on you as soon as you want to step through code in a file that also has coverage data. Line coverage highlights the code itself, which is more legible anyway, at the cost of losing the compact per-line status strip.

Watch, Display and Preview Report

Three commands define how the extension behaves. Watch, activated from the command palette or a shortcut icon on the status bar, lets the extension keep track of coverage changes and update its cache, and it automatically applies coverage to a file if some exists. Display, also from the command palette or a shortcut key, shows coverage for the currently active file only and does not update when the coverage files change. Preview Report, from the command palette, shows an HTML preview of the coverage reports inside the editor. The split between Watch and Display is a real design choice about cache invalidation, and it is the difference between a panel that follows your test runs and one that shows a snapshot of whatever was on disk when you opened the file.

The caching layer is what makes it usable on large files

Two features carry the performance story. The first is a coverage caching layer, described as making for speedy rendering even in large files. The second is multi coverage file support for both xml and lcov, so a project with several coverage outputs can have them all loaded rather than one overwriting the other. There is also relative coverage file resolution for people with complex file paths, which is the kind of detail that determines whether the extension works in a monorepo or a container where the build root and the editor root differ, and a hot swapping feature for custom coverage paths, aimed at remote builds where the coverage file lands somewhere the editor can reach only after the build finishes. The README also mentions extensive logging and insight into operations via the output logs, which is how you would debug a case where the gutters simply do not appear.

Any language, as long as it produces lcov

The headline capability is language independence. The extension supports any language as long as you can generate an lcov style coverage file, which is the point of lcov being a format rather than a tool. On top of that it also reads xml, and the officially supported languages, backed by tests run nightly, are Java, with separate examples for Java with Gradle and for multimodule Java, PHP, Python, Nodejs, Ruby and DotNet, each with a setup example in the example directory. The nightly test job across six toolchains is what separates the supported list from the any-language claim, and it is the part of the project that would quietly rot if nobody ran it. There is also a huge amount of workspace settings to customise the features, and colour compatibility with light and dark themes, with separate default highlight colours for each.

How the highlights are configured

The manifest shows the settings surface concretely, and the defaults reveal the visual design. A light themed highlight for code coverage defaults to rgba(0, 255, 64, 0.2) and a dark themed one to rgba(0, 122, 30, 0.4), so fully covered lines get a green wash whose strength depends on the theme. Partial coverage has its own pair of settings, partialHighlightLight and partialHighlightDark, defaulting to rgba(255, 235, 0, 0.2) and rgba(163, 149, 0, 0.4), so partially covered lines read as yellow. Each setting is scoped to resource, which means it can be overridden per folder in a multi-root workspace rather than only globally, and the pair of light and dark values means a user who dislikes the default green can pick a colour that works with their theme without losing the distinction between full and partial coverage. The contributed configuration block in the manifest looks like this:

        "coverage-gutters.highlightlight": {
          "type": "string",
          "scope": "resource",
          "default": "rgba(0, 255, 64, 0.2)",
          "description": "light themed highlight for code coverage"
        },
        "coverage-gutters.highlightdark": {
          "type": "string",
          "scope": "resource",
          "default": "rgba(0, 122, 30, 0.4)",
          "description": "dark themed highlight for code coverage"
        },

The same pattern repeats for the partial highlight pair, and the settings are documented in the IDE itself rather than only in the manifest.

The packaging, the engine floor and the extension host

The package manifest names the extension vscode-coverage-gutters with the display name Coverage Gutters, published under the ryanluker publisher, version 2.15.0, licensed MIT, and categorised under Testing and Other. The engines block is where the compatibility question sits, requiring VS Code 1.66.0 or newer and Node 24.0.0 or newer, which is a modern floor given that the extension host runtime is what executes the TypeScript. The main entry point is ./dist/extension, and the build is driven by esbuild.js at the repository root, with husky hooks, an .eslintrc.json, an .editorconfig, a .devcontainer directory and a test directory in the tree. The keywords list the extension as multi-root ready, which matches the resource scope on the settings and the relative path resolution.

Where Coverage Gutters is the wrong tool

Three cases. The first is a team whose coverage tooling emits something other than lcov or xml, since the extension takes no other input and there is no adapter layer described, so you would be writing the file yourself. The second is anyone who wants per-test coverage, where a line is either covered or not, because the extension works from a merged report and has no notion of which test produced which line, so a report that distinguishes two tests touching the same line cannot be represented. The third is a project that needs the numbers rather than the picture, since the gutters are a visual aid and the report preview is an HTML view, so extracting a coverage percentage for a dashboard means going back to the report generator. Against a language-native coverage extension, the difference in approach is that this one is format-first rather than language-first, which means the same extension covers a Java service and a Python script in the same workspace, and also means the officially tested list is a list of test fixtures rather than a list of integrations. On maintenance, the README opens with a call for maintainers, asking for help with bugs, new features or performance improvements, while noting the project has a full test suite and code linting, and the release history shows v2.15.0 on 2026-09-24, v2.14.0 on 2025-08-27 and v2.13.0 on 2025-01-26, with the last push on 2026-10-15.

Editorial conclusion

Coverage Gutters is a good fit for a polyglot team that already produces lcov or Cobertura-style xml from its test runs and wants the result visible while editing rather than in a separate report, and it costs nothing but a coverage file on disk. It is a poor fit if your coverage tooling emits a format the extension cannot read, if you want coverage per test rather than per line, and it is a poor fit for a team that needs an actively maintained project, because the README opens with a call for maintainers. Check three things before you install it: that your coverage output is lcov or xml, since that is the only input the extension takes; that you set the two conflicting settings when you also want debugger breakpoints, because the README says you must disable gutter coverage and enable line coverage to use both at once; and that your editor runtime matches, since the package manifest requires VS Code 1.66.0 or newer and Node 24.0.0 or newer, while the requirements section in the README still lists VS Code 1.27.0 and up, so the manifest is the one to trust.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ryanluker/vscode-coverage-gutters on GitHub