In IntelliJ IDEA 2025.1, WSL projects indexed faster than native Windows projects - a sign that JetBrains' internal agent-backed filesystem channel was already delivering. Now that channel has a public name: EelApi.
EelApi stands for "execution environment API." It is the IntelliJ Platform's answer to a question that got harder every year: "Where does this operation actually run?" For plugin authors who have been duct-taping together WSL-aware ProcessBuilder calls and hoping paths resolve, this is the first first-class API that forces you to be explicit about the environment.
The Shape of the Problem
The old IDE model was simple because there was only one machine. A Path was a file the IDE could read. SystemInfo described the host OS. ProcessBuilder started a process in the only possible place. Then WSL2 arrived with Linux filesystems on the same host, followed by Dev Containers with their own filesystems, environment variables, and network namespaces. JetBrains' first response was not a public API but an agent - a small IntelliJ Platform process called ijent that runs inside the target environment and provides a controlled channel for filesystem, process, port, and platform operations.
That agent is the backbone of WSL support since IntelliJ IDEA 2024.3 (Hyper-V sockets, symlinks) and native Dev Container support since IntelliJ IDEA 2025.3 (with 2026.1 making it the default workflow). EelApi is the Kotlin-first API surface that wraps that channel for plugin authors.
What EelApi Actually Does
Through a single EelApi instance, you get: NIO Path operations routed to the target environment, process execution with EelExec, TCP tunnels via EelTunnelsApi, and platform detection via eel.platform. The key insight is that most plugin code should start from a Project - the platform already knows whether that project lives locally, in WSL, or inside a container.
val descriptor = project.getEelDescriptor()
val eel = descriptor.toEelApi()
From there, copying a binary into the environment uses standard Files.copy but the Path is environment-aware thanks to a custom filesystem provider. Running that binary uses eel.exec.spawnProcess instead of ProcessBuilder. Detecting the target OS uses eel.platform instead of SystemInfo. Connecting to a localhost service inside the environment requires explicit tunneling - because localhost inside a container is not the same as localhost on the host.
Path handling is the part easiest to get wrong. java.nio.file.Path is always the IDE/JVM-side path. For WSL that's \\wsl.localhost\Ubuntu\home\user\project. For Dev Containers it's a synthetic routing path like //devcontainer.ij/devcontainer-abc@.../workspaces/app. The target-side path - what Linux tools inside the container expect - is /home/user/project or /workspaces/app. Use path.asEelPath().toString() when passing paths to processes in the environment.
Where This Leaves Plugin Authors
Most of EelApi is currently marked @ApiStatus.Experimental. That does not mean ignore it. This API already backs production features in two major areas: WSL projects in 2024.3 and native Dev Containers in 2025.3+. The remaining changes during stabilization are expected to be limited because the model has been exercised at scale.
If your plugin downloads a CLI tool, starts a process, reads environment variables, or opens TCP connections, and you have been silently hoping users won't open the project in WSL or a Dev Container - that hope expires. EelApi gives you an honest, explicit path to handle those environments without split-mode gymnastics. The API is still experimental, but given it already backs production features, plugin authors should start targeting it now - before environment-awareness becomes the default expectation.
Source: The Dev Containers Story: Introducing EelApi for Plugin Authors
Domain: blog.jetbrains.com
Comments load interactively on the live page.