Starting with the 2026.2 release, opening a project located inside the Windows Subsystem for Linux, or WSL, from within IntelliJ IDEA, WebStorm, or PhpStorm leads to what JetBrains calls Native mode. In this mode, the IDE remains a Windows application, while a small agent inside WSL performs file and process operations on its behalf. The company says this is currently the recommended entry point, while the Remote Development option remains available on the welcome screen but is no longer the preferred way to open WSL projects.
The issue is not merely a change to a name in the user interface. Supporting a Linux project located inside WSL requires the development environment to access files, run tools using the correct paths, manage environment variables, and run build, debugging, and profiling processes, while keeping latency low enough for the experience to feel natural. JetBrains explains that previous methods used different architectures depending on the entry point, which led to variations in performance and behavior across products and scenarios.
Why is the 9P path no longer enough?
Under the older approach, JetBrains applications on Windows accessed WSL files through the 9P filesystem protocol, while the GeneralCommandLine class handled the normalization of commands running inside the Linux environment. This made it possible to run the IDE against WSL projects, but it moved a large portion of read and indexing operations across the boundary between Windows and the virtual machine hosting WSL.
According to JetBrains, three main problems emerged. First, 9P does not expose Linux symbolic links correctly through the \\wsl$ path, which may prevent the IDE from resolving or indexing some trees. This issue affects environments that use symbolic links, such as pnpm workspaces, Python virtual environments, and path-dependent Composer repositories. Second, Microsoft Defender scanning during access may extend the time required to read WSL files by tens of seconds. Third, the protocol adds noticeable time to operations that handle large numbers of small files, such as indexing.
The command-execution layer also required platform developers to handle WSL-specific semantics in different parts of the codebase. JetBrains believes this made the approach more difficult to scale and maintain, rather than providing a unified foundation for non-local work environments.
What did Remote Development add?
Remote Development addressed the problem from the opposite direction: the complete IDE backend moves into WSL, while a client remains on Windows to display the interface and receive user input. The two sides communicate through the JetBrains RD protocol, which transfers event models and editor and project state in both directions. Heavy operations, such as indexing, analysis, building, debugging, and version-control operations, take place inside WSL close to the files.
This design removed the direct dependency on 9P for file access, but introduced another cost. JetBrains says the backend requires about 2 gigabytes of additional disk space, in addition to the time needed to download and install it inside WSL. Continuous interaction between the client and backend also requires constant transfer of interface state and user input, which may affect responsiveness. Product development itself requires splitting code between the client and server, which can cause delays or freezes in dynamic interfaces if some modules remain unsplit.
How does Native mode work?
The new approach relies on an agent called IJent. The agent performs file and process operations inside the target environment instead of passing them through 9P or general execution layers. JetBrains describes it as a small component written in Rust, reducing the need for additional runtime dependencies such as Java or Kotlin inside WSL or containers.
IJent uses a transport layer based on Stdio, which is portable and does not require opening firewall ports, while Hyper-V sockets in WSL provide a faster path, particularly when transferring large numbers of files. Because filesystem operations are executed inside the Linux environment itself, path and symbolic-link handling more closely follows native Linux semantics. External plugins also benefit when their file operations pass through IJent.
IJent is connected to the EelApi interface, which JetBrains designed to hide the difference between local and remote environments from platform developers and plugin authors. Under this model, the same code can work with a local environment, WSL, Docker, or a Dev Container without adding logic specific to each environment. The company says IJent implements the EelApi interface and provides its actual functionality.
What do the tests say?
JetBrains compared 9P mode with IJent mode in a cold-open test of a spring-framework project containing 23 subprojects and 8,191 source files. The measurements were conducted on Windows 11 with WSL 2, Ubuntu 24.04, and IntelliJ IDEA Ultimate version 263.SNAPSHOT, with the results based on the median of five runs.
- Ready to work: decreased from 18.5 seconds to 11.5 seconds, an improvement of 38%.
- Project tree scan: decreased from 8.1 seconds to 3.7 seconds, 54% less.
- File indexing: decreased from 10.8 seconds to 8.4 seconds, an improvement of 22%.
- Reading file contents: decreased from 12.2 seconds to 5.7 seconds, 53% less.
The company cautions that a small project containing only a few files showed no measurable difference in the same test. Therefore, the greatest practical benefit applies to large projects or workflows that repeatedly access a large number of files.
What does this mean for developers?
The most important change is the unification of the entry point and recommended architecture, not the immediate elimination of all previous options. Users who open a WSL project directly in the supported products receive Native mode, while Remote Development remains useful for those who choose that path or need a separate client-and-backend model. As for running the IDE itself through WSLg, JetBrains says it is technically possible but is not a first-class supported workflow, due to limitations related to graphics, window management, and input, as well as the application's dependence on a Linux display layer inside Windows.
The published results indicate a noticeable improvement in some operations, but the test scope is limited to one project, one environment, and one specific version. The figures therefore do not prove consistent superiority for all projects or plugins. Adoption of the new architecture across more JetBrains products is also still underway, making plugin compatibility and behavior across different environments an aspect worth monitoring.