JetBrains routes WSL projects through an in-WSL agent starting with 2026.2

JetBrains names the original defect precisely: the entry point you used decided which architecture ran underneath, and therefore what the experience was ^[1]. Native mode is the fourth architecture in that lineage ^[6].

Under the oldest path, project file I/O went over the 9P filesystem protocol so Windows-side processes could reach files inside the Linux VM, covering scanning, indexing and archive access ^[7]. Command execution was handled separately, by an internal GeneralCommandLine class that normalised Linux paths, working directories, executables, environment variables and arguments for tools invoked inside WSL ^[8]. Both halves cost something. Indexing is the worst shape for 9P because it issues many small separate requests, each one crossing the Windows/WSL VM boundary ^[13]. On the execution side the cost was internal: every code path that shelled out had to carry WSL-specific semantics ^[9]. Spreading that across a codebase is the kind of tax that never shows up in a release note. JetBrains describes the combination as increasingly difficult to scale and maintain, with symlink and performance problems that persisted ^[14].

An agent inside WSL changes where the work happens. For Native mode to clear the 9P failures, the agent has to do the directory walking, the stat calls and the reads inside the Linux VM, so symbolic links resolve with Linux semantics and per-file requests never leave the guest. The post describes the agent's job in those terms, with the IDE remaining a Windows application while the agent handles files and processes on its behalf ^[4], and calls it the currently preferred mode ^[20]. It publishes no latency or indexing figures for it ^[19]. That makes the adoption test local rather than comparative. Time a full index of your own repository under the new entry point, on the layout you actually have, because a figure measured on a sample project only transfers if its file count and symlink depth match yours.

The two discarded approaches are documented unevenly. WSLg gets an explicit recommendation against it, on the product argument that an IDE displayed on Windows should behave as a Windows application rather than as a Linux GUI projected into the Windows desktop, which also avoids depending on an additional GUI remoting layer ^[15][16]. Remote Development appears in the list of earlier attempts ^[5], but the reasoning for stepping away from it is not in the published text at hand ^[18].

Publishing three abandoned designs with the mechanism of each failure is better engineering writing than most default changes get ^[5][14]. For a Windows team, the 2026.2 work that follows is narrow: establish which entry point your terminals and run configurations come through today, then re-time indexing once the in-WSL agent is doing the reads.