Bazel for CLion: the IntelliJ plugin that JetBrains took over

A Bazel plugin that Google handed to JetBrains

This repository holds a CLion plugin for Bazel projects, and the first line of the README is the fact that reframes everything else: as of July 1, 2025, the Bazel for IntelliJ and Bazel for CLion plugins are maintained by JetBrains. These plugins are not offered by nor affiliated with Google, and the Bazel trademark and logo are the property of Google LLC.

That handover explains the shape of the repository, and the documentation is unusually explicit about it. The plugin you install from the JetBrains Marketplace is uploaded regularly from the state of this repository, so the code here is the code that runs in your IDE.

The responsibility split is worth stating plainly. Google contributed the original work and the Bazel for Android Studio plugin is a Google product, built from AOSP. JetBrains took over the CLion and IntelliJ editions. The README says the project uses binary bundles licensed under the JetBrains User Agreement, which is a specific and unusual licensing arrangement for an open source plugin, and it is one that matters if you redistribute a build of the plugin yourself.

The audience is developers whose C and C++ projects are built with Bazel and who want their IDE to understand that. The topic list on the repository is exactly that scope: bazel, build-tool, clion, cpp and ide.

For context on how active this is, the release list shows a plugin release dated 2026-10-14, an EAP release the same day, and a stable release dated 2026-09-21. The repository is not archived and the last push was on 2026-10-19.

Four branches, three plugins, one upstream source of truth

The branch structure is the most confusing part of this project and the README handles it better than most projects do.

The Bazel for CLion plugin is built and released from the master branch of this repository. The Bazel for IntelliJ plugin is built and released from the ijw b branch, and the README adds the caveat that maintenance for the IntelliJ plugin is limited to ensuring compatibility with new versions of JetBrains IDEs, with no new features or bug fixes.

The Bazel for Android Studio plugin is built and released from AOSP, and the README is emphatic that this is the only location with up-to-date sources. The google branch is deprecated, and the aswb branch holds only an outdated snapshot from when the plugin was last hosted in this repository, with the instruction not to use it as a reference for current Android Studio plugin code.

So the repository is one of three plugin editions, and the other two are somewhere else entirely. The README also notes that the code in this repository and in AOSP share the same structure and core components but have diverged from each other.

The merge direction is described in detail. Changes for the CLion plugin are only merged into the master branch, and users can request that certain fixes also needed by the Android Studio plugin be merged into the AOSP project, which will require the internal teams' approval. Changes made by the internal Google teams are automatically exported to AOSP, and these commits were regularly cherry-picked to the master branch. The Android Studio plugin was removed from the master branch and is now only available in the AOSP.

In practice, if you are a CLion user you are in the right place. If you are an Android Studio user, this repository will mislead you unless you read the README closely.

The AOSP cherry-pick pipeline and why it stopped

The AOSP relationship has a specific process, and the README documents its current state with a candour that is worth reading.

After the migration of the Android Studio plugin to AOSP, this process was interrupted for approximately five months. In November 2024, many changes from AOSP were cherry-picked in pull request 6965, and from that point the project has been making a best effort to apply AOSP changes to the master branch.

The tooling is named. The project uses a Python tool, LeFrosch/intellij-aosp-merge, which is capable of adjusting paths from AOSP to the project's layout and allows the revisions in AOSP and in this repository to be compared. The status of picked and skipped commits is tracked in a linked document.

Then the important line: due to multiple regressions caused by picks from the AOSP, cherry-picks have been halted for the time being.

That is a significant operational fact, and it explains a structural property of the codebase. The master branch and AOSP share structure and core components but have diverged, and they will keep diverging while the merge is stopped. A fix that lands in AOSP today will not appear in the CLion plugin for an unknown period, and the manual merge tool exists precisely because this cross tree translation is done by hand.

For a CLion user, the practical effect is that you should not assume a bug fixed in the Android Studio plugin has reached your IDE. The compatibility documentation and the issue tracker are where you confirm that, and the README points to the plugin support documentation entry for exactly that question.

Building the plugin with an ij_product target

The build system for the plugin is Bazel itself, which is a nice symmetry and also the reason contributing needs the toolchain installed first.

Install Bazel, then build the target from the project root:

bazel build //clwb:clwb_bazel_zip --define=ij_product=clion-oss-latest-stable

The result is a plugin zip at bazel-bin/clwb/clwb_bazel.zip, which can be installed directly from the IDE.

The ij_product define is the interesting part, because a single source tree has to build against several IDE versions. The alias forms are clion-oss-<VERSION> with <VERSION> being one of oldest-stable, latest-stable or under-dev, and you can also set ij_product to a direct CLion version such as clion-2026.1.

The semantics of the aliases are given explicitly. The oldest-stable and latest-stable aliases are for the two IDE versions that the plugin is officially compatible with at a given time, where latest-stable usually maps to the last released IDE version and oldest-stable to the one right before that, for example oldest-stable=2022.1 and latest-stable=2022.2. The under-dev alias represents the upcoming version of the IDE that the project is working towards supporting. A complete mapping of all currently defined versions is in intellij_platform_sdk/build_defs.bzl.

If the IDE refuses to load the plugin because of a version issue, the fix is to specify the correct ij_product, which is the symptom described in the documentation.

You can also change the product from the command line or by editing the .bazelproject file, under build_flags, and the project can be imported into IntelliJ with the Bazel plugin via the ijw b/ijwb.bazelproject file.

Two known issues that will cost you an afternoon

The known issues section is short, and both entries are about setup rather than about code.

The first is Python debugging, and the documentation simply links a specific comment on issue 4745 rather than summarising the problem. That is unusual, and it tells you the details do not fit in a paragraph. The pattern is familiar from the plugin's topic tags, which include python and cpp, since the plugin supports Python and C++ targets and debugging is where a build tool integration meets the debugger.

The second is Remote Development, and this one does have steps. To set it up properly:

1. Create an empty project on the remote machine, which can be just an empty directory. 2. Import the project using Remote Development. 3. Install the Bazel Plugin on the host machine. 4. Close the project. 5. Open the initially intended project.

The order is the point. The plugin has to be installed on the host rather than the remote machine, and the empty project is a placeholder that makes the import work. Any of these steps done in the wrong order produces a confusing state, which is why the documentation enumerates them rather than describing the goal.

A second limitation worth naming is about the IntelliJ edition rather than CLion. The README is explicit that maintenance for the IntelliJ plugin is limited to ensuring compatibility with new versions of JetBrains IDEs, and that no new features or bug fixes will be provided. If you are on IntelliJ IDEA rather than CLion, you are on a maintenance branch of a product that JetBrains is maintaining for compatibility only.

The repository is the build system, not just the plugin

The top level entries show that this is a much larger thing than a plugin project, and understanding the layout explains why the ij_product mechanism exists at all.

There is a clwb directory, which is the CLion plugin itself and the source of the clwb_bazel_zip target. There is a intellij_platform_sdk directory with the build_defs.bzl file that holds the IDE version mapping, so the platform SDK is built inside this repository rather than consumed as a binary. There is a base directory, and a shared directory, and language specific directories for cpp, python, javascript and dart, plus codeinsight for the IDE side of the analysis and skylark for Starlark support. There is a terminal directory, a proto directory, an aspect directory, a vcs directory and a third_party directory.

The build files are Bazel throughout. There is a BUILD file at the root, a MODULE.bazel and a MODULE.bazel.lock for the module system, a .bazelrc, a .bazelversion file pinning the Bazel version, a maven_install.json for Java dependencies, and a .managed.bazelproject, which is the checked-in project configuration. There is a .bazelci directory for continuous integration configuration.

The reason for building the IntelliJ platform SDK from source rather than downloading it is compatibility, and it is the same reason the plugin has a per IDE version build. JetBrains platform artifacts are versioned against specific IDE releases, so a plugin that wants to support several IDE versions needs to compile against several platform versions, and the aliases in build_defs.bzl are what make that manageable.

The supporting files are conventional for a Google maintained project: CODEOWNERS, CONTRIBUTORS, AUTHORS, a CODE_OF_CONDUCT file, a .licenserc.yaml for license header checking, a renovate.json for dependency updates, an ARCHITECTURE.md, a CLAUDE.md, a DEV_IDE_SETUP.md, a CHANGELOG, and an examples directory with cpp and python samples.

Licence, support and what to check before you install

Two licence layers sit on top of each other, and only the first is the usual one.

The repository itself is Apache-2.0, with a LICENSE.txt at the root. That covers the source you read, and it is the licence the JetBrains User Agreement for the binary bundles is separate from. The README states plainly that this project uses binary bundles licensed under the JetBrains User Agreement, which means the platform binaries that get bundled into a built plugin are not Apache-2.0. If you are building the plugin yourself and distributing the result, that is the clause to read, and it is the reason a self built plugin zip is not simply the repository.

The trademark position is separate again. The Bazel trademark and logo are the property of Google LLC, and the plugins are not offered by nor affiliated with Google.

Support is documented rather than handled ad hoc. The README points to the documentation entry for plugin support across JetBrains products, languages and operating systems, and recommends a video to familiarize yourself with the plugin's features. There is a Special Interest Group for the Bazel IntelliJ IDE plugin, hosted by the Bazel project, with a SIG charter describing how to join the discussion. That is a better channel for design questions than the issue tracker, and the SIG still exists even though the plugin is now JetBrains maintained, which tells you the community side has not been dropped.

Installation for an end user is a Marketplace click. The plugin is in the JetBrains Marketplace, and the README also describes going to Settings, then Plugins, then Marketplace inside the IDE and searching for Bazel. Importing an existing project is done with the Import Bazel Project action, which opens a project import wizard.

So the checks before you rely on this are short. Confirm which branch corresponds to the plugin you actually installed, since the Marketplace artifact comes from master while the IntelliJ and Android Studio editions do not. Confirm the ij_product alias your build uses matches your IDE version, or the IDE will refuse to load the plugin. And if you hit the Python debugging issue, read the linked comment before filing anything new, because the diagnosis is already written down.

Editorial conclusion

Adopt the Bazel for CLion plugin if your C or C++ work happens in CLion and you want Bazel targets, indexing and run configurations rather than a generated build system. Do not rely on this repository for the IntelliJ or Android Studio editions, since the IntelliJ one is maintenance only and the Android Studio one lives in AOSP. Verify first which branch matches the plugin you install, that the ij_product alias in your build matches your IDE version, and that the plugin you get from the JetBrains Marketplace is the one you are reading about here.

Frequently asked questions

Official sources

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