Native Mode for WSL is now the recommended approach — what does it mean for plugin developers?

Announcements
, ,
1

With 2026.2, Native Mode is now the recommended way to open WSL projects in IntelliJ IDEA, WebStorm, and PhpStorm.

For plugin developers, the interesting part is what’s underneath: IJent and EelApi.

EelApi provides an environment-aware abstraction for working with files and processes, so plugins don’t need to handle local, WSL, Docker, or Dev Container environments separately.

Native Mode also brings proper Linux filesystem semantics to WSL projects, including symlink handling — something particularly relevant for tools and plugins interacting with project files.

:backhand_index_pointing_right: What this means for plugin developers and how to work with EelApi:

:backhand_index_pointing_right: The story behind Native Mode and our WSL architecture:
https://blog.jetbrains.com/platform/2026/09/the-evolution-of-wsl-support-in-jetbrains-ides

If your plugin interacts with files, launches external processes, or makes assumptions about where a project lives, give it a try with a WSL project in 2026.2.

Let us know if you run into anything that doesn’t behave as expected. Thanks!

2

What is the recommendation for plugins already supporting run targets (wsl, ssh, …)?

Is an there an Eel replacement for SSH run targets?

Will run targets be dropped from the API in the near future?

Does Eel have API for path mapping, e.g. Windows ← → WSL path mapping?

In general, how can plugins using EEL be tested properly?

If I understand correctly, Eel is taking over use-cases were previously split-mode was used (DevContainers?).
Is split mode going to stay or will everything move towards Eel?

3

Sounds to me like EEL routes the execution of system-bound operations either locally or to a remote target via the ijent platform agent running on the target system so you don’t need split mode just to be able to e.g., open a project or execute a run config in your DevContainer. Split mode still serves the true remote development scenario where you have a thin client and a provisioned backend with more resources to be able to handle heavier workloads and larger projects inside the IDE process itself.

Snooping around in the codebase and YouTrack, it seems opening “true” remote projects over SSH via EEL/ijent exists. Given, it’s not mentioned in the post, I’m guessing it’s not publicly available yet.

4

Joachim, thanks, these are good questions. The concepts can look close from the outside, especially for WSL and containers, but they solve different problems.

EelApi gives IDE code operational access to the environment where the opened project lives. For WSL Native Mode, that environment is the WSL distribution. For Dev Containers, it is the running container. Code can work with files, run processes, inspect the platform, convert paths, and create tunnels in that environment.

The Targets API is still the right layer for explicit run and deployment flows, including SSH run targets, remote SDK setup, and UI where the user chooses where to run something. A common setup is that the project is local, while the run target is elsewhere. The flow is usually: describe the target, prepare it, transfer the needed files, run a command, and collect results.

EelApi can cover some use cases that previously used run targets when the “target” is actually the opened project environment. WSL project tooling is the clearest example. Dev Containers are another one.

In some Docker interpreter cases, users can now choose a Dev Container project instead. This is not a direct replacement for Docker interpreters. It is an alternative workflow where the container is the project environment, and EelApi gives the IDE deeper integration through IJent.

For path mapping, could you share why the plugin needs the mapping? If you pass a project path to a process in WSL or a Dev Container, Path / EelPath conversion is probably the right direction. If you map paths for deployment to a run target, the Targets API mapping may still be the right abstraction.

For testing, the easiest approach we have found is to open a project in a Docker container and run the plugin scenario there. It is also useful to verify the same scenario in WSL to catch environment-specific issues.

We have internal test infrastructure that lets us write a test once and run it in different environments. However, that area is changing actively, so it is too early to publish it as guidance. We plan to provide better public testing guidance later.

Could you also share the larger use case your plugin supports with the Targets API today? In particular: where is the project, where does the code run, and what does the user expect to happen? That would help us say whether this remains a Targets API case, becomes an EelApi case, or needs both.

5

David, that is a good summary.

Split Mode still serves the true remote development scenario: the user works through a thin frontend, while the IDE backend runs close to the project and has the resources needed for indexing, analysis, and other heavy IDE work.

Your guess about SSH over EelApi / IJent is also fair. We are experimenting with this direction. For arbitrary SSH machines, we cannot assume that the network path has enough latency and throughput for indexing and heavy file operations if the IDE backend stays on the local machine. We are trying different hybrid approaches here.

So for plugin authors today, opening WSL projects and working with Dev Containers are the main public EelApi scenarios. Run Targets and Split Mode remain separate supported models.