IntelliJ 2026.2: open-source LSP client, modular Java plugin, Copilot in the agent picker

IntelliJ IDEA 2026.2 went GA on July 16, and the rollout across the rest of the family is still running this week. Most of the release is the usual mix of day-one language support (Java 27 and Kotlin 2.4 both land on day one) and UI polish. Three items are not usual, and if you maintain a plugin they decide whether your next build compiles: the LSP client API is now open source, the Java plugin has been split into modules with their own classloaders, and the AI chat gets an agent picker with GitHub Copilot in it out of the box.

What shipped

The LSP client API is open-sourced and available across JetBrains IDEs, Android Studio and any product built on the open-source platform. Write a language integration once, speak LSP, target the whole ecosystem. The catch is that the API moved while it was being opened: as of July 20, LspServerManager is renamed LspClientManager, and the service is registered only under the new interface. Any getInstance call against the old name fails at runtime on 2026.2.

The Java plugin is now modular, with each module loading in its own classloader. This is the breaking change most people hit first. Anything that depended on the Java plugin as one monolith needs the IntelliJ Platform Gradle Plugin 2.x and an explicit dependency on the modules it actually uses. If your build still runs on the 1.x Gradle plugin, 2026.2 is the release that forces the migration.

On the AI side, GitHub Copilot ships out of the box and shows up in the agent picker inside AI chat, next to JetBrains' own agents. The Machine Learning Code Completion plugin is deprecated and no longer bundled. Read together: completion is moving into the agent and next-edit layer, and several agents now sit behind one picker. Kotlin Notebook is sunset from 2026.2 as well.

Why it matters if you ship plugins

The open LSP client is the part I like: a language service written against LSP is portable across editors, and JetBrains just removed the reason to write a proprietary IntelliJ integration for it.

The modularisation is the part that costs you a weekend. Classloader isolation means a class you used to reach through the Java plugin may now live in a module you never declared. It compiles against the old SDK, then throws at runtime in 2026.2.

Every platform release is a compatibility exam you did not schedule, and 2026.2 is a harder one than most.

There is a second, quieter deadline in the same window. The Q2 2026 Busy Plugin Developers newsletter on July 21 announced that the Marketplace now automatically flags plugins that use internal APIs, as part of the ongoing IntelliJ Platform API stabilisation. The notification is a warning, not a grace period: anything on an internal API can become incompatible in any 2026.x build. The same newsletter shipped Plugin Verifier 1.409, Gradle Plugin 2.18.1 and Plugin Template 2.6.0 (on IntelliJ Platform Gradle Plugin 2.16.0, IDEA 2025.2.6.2, Gradle 9.5.0), and made the Exceptions tab default for all authors.

Compatibility checklist

• Bump the build target to 2026.2 and run Plugin Verifier 1.409 against it before anything else.
• Migrate to IntelliJ Platform Gradle Plugin 2.x if you have not; the modular Java plugin requires it. Declare the Java modules you depend on explicitly.
• Rename LspServerManager to LspClientManager everywhere, including getInstance calls and any reflection.
• Check the Marketplace author dashboard for internal API flags, and grep your code for anything marked internal or unstable.
• Ship in lockstep: version bump, change notes in plugin.xml, README and Marketplace listing in one release, not a hotfix chain.

If you build on the ACP side, the picker change is the same story from the other direction; I covered how JetBrains' own agents fit together in AIR vs Junie.

The honest gap

Everything above is from JetBrains' own release notes, incompatible-changes list and newsletter. I have not yet run a full plugin suite against a 2026.2 build with the modular Java plugin, so I cannot tell you how many transitive classloader failures a typical mid-size plugin hits. The rename and the Gradle 2.x requirement are certain; the size of the cleanup behind them is a per-plugin question, and mine starts this week.