# RunVSAgent puts VS Code coding agents inside JetBrains IDEs

> RunVSAgent is a JetBrains plugin that runs VS Code style coding agents such as Roo Code, Cline and Kilo Code inside IntelliJ, WebStorm and PyCharm. It works by pairing a Kotlin plugin with a Node.js extension host over RPC, and its weakest point is that the bridge has to emulate the VS Code API.

**wecode-ai/RunVSAgent** — Run VSCode-based coding agents and extensions seamlessly within other IDE platforms - bridging the gap between VSCode ecosystem and other development environment.

- Repository: https://github.com/wecode-ai/RunVSAgent
- Stars: 713 · Forks: 104
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wecode-ai-runvsagent

## Why a JetBrains user needs a bridge at all

RunVSAgent is a JetBrains plugin that runs VS Code style coding agents inside IntelliJ IDEA, WebStorm, PyCharm and the rest of the JetBrains family. The problem it addresses is narrow and real. Roo Code, Cline and Kilo Code are built against the VS Code extension API, so a JetBrains user who has settled on one of them has no supported way to run it in the editor they actually use. Rather than porting each agent, the project wraps a Node.js extension host next to the IDE and speaks to it over RPC.

The audience is therefore JetBrains users who standardised on a VS Code agent for daily work, and the three agents the project names as supported are Roo Code, Cline and Kilo Code. The listed IDE coverage is wide: IntelliJ IDEA in both Ultimate and Community editions, WebStorm, PyCharm Professional and Community, PhpStorm, RubyMine, CLion, GoLand, DataGrip, Rider and Android Studio. The stated compatibility floor is JetBrains IDE 2023.1 or later, which is worth checking against older installations in a team environment before anyone rolls it out.

## A Kotlin plugin, a Node host and a socket between them

The architecture diagram in the project documentation is worth reading, because the split explains both what works and what does not. The JetBrains side is a Kotlin plugin that contains a UI integration piece and an editor bridge. The other side is an extension host running on a Node.js runtime, which provides the VS Code API layer and an agent manager. A coding agent talks to that API layer, and the plugin talks to the host over RPC.

Transport is RPC over Unix Domain Sockets or Named Pipes, so the two halves are separate processes on the same machine rather than two libraries in one process. The Node.js side is TypeScript, and the project layout puts its main entry point, an extension manager, an RPC manager and a WebView manager under extension_host/src. The Kotlin side mirrors that separation with core, actions, editor and webview packages under jetbrains_plugin/src/main/kotlin.

One detail in the directory tree is worth noticing: the plugin's Kotlin package path is com.sina.weibo.agent. Whatever the history behind that namespace, it tells you the plugin ships under a vendor style package name rather than a neutral one, and it is the kind of detail that can collide with another plugin in the same IDE. The project also keeps a deps/ directory and a .gitmodules file, so parts of the build depend on vendored or submodule content.

## Installing from the Marketplace, and what to look for after the restart

The project describes two installation paths, and the recommended one is the JetBrains Marketplace. The steps are the familiar JetBrains ones: open the IDE, go to Settings/Preferences and then Plugins, search for RunVSAgent in the Marketplace tab, press Install, and restart when prompted. After the restart, the plugin should appear in the IDE plugin list.

The alternative path is a prebuilt zip from the GitHub releases page. The flow is the same up to the last two steps: open Settings/Preferences and Plugins, click the gear icon, choose Install Plugin from Disk, select the downloaded .zip file, and restart the IDE. The Marketplace route is recommended in the documentation because it is described as the more convenient and secure option, and on a managed workstation that is usually also the only route your administrators will allow, since a disk install bypasses their plugin catalogue.

There is no command line installer and no homebrew style package in the documentation, so the first real check after installation is whether the Node.js extension host actually starts on your machine. Node.js 18 or newer is listed as a prerequisite, and the plugin cannot run a VS Code agent without it, which makes this the most likely first failure for a JavaScript or Python developer who has never installed Node locally.

## Building the two halves from source

For anyone who wants to modify the plugin rather than install it, the documentation lists prerequisites of Node.js 18.0 or newer, a JetBrains IDE 2023.1 or newer, Git and JDK 17 or newer, and it describes the build in a short script sequence. The setup step prepares the development environment:

```bash
./scripts/setup.sh
```

and the build step produces the plugin:

```bash
./scripts/build.sh
```

The plugin file lands in the distributions directory of the JetBrains plugin module, and the documentation says to install it through Settings, Plugins, Install Plugin from Disk. Two separate build entry points exist, one per half, which matters when you are iterating. The extension host starts on its own:

```bash
cd extension_host
npm install
npm run dev
```

and the Kotlin plugin launches a sandbox IDE separately:

```bash
cd jetbrains_plugin
./gradlew runIde
```

Running the two development commands in separate terminals is the intended workflow, since the plugin and the host communicate over a socket. The version numbers in the stack are explicit: TypeScript 5.0 or newer on the host side, Kotlin 1.8 or newer against IntelliJ Platform 2023.1 or newer on the plugin side, with npm or pnpm, Gradle and shell scripts as the build tools.

## Where the emulation of the VS Code API is likely to bite

The honest limitation here is structural. A VS Code agent is written against an API that RunVSAgent has to reproduce, and the host layer is described as a VS Code API compatibility layer rather than the real thing. Every API surface an agent touches is a place where behaviour can differ from the genuine article, and the project itself keeps a Known Issues page for the list of common problems. The documentation does not enumerate those issues in the README, so the file to read is docs/KNOWN_ISSUES.md before you commit a team to it.

Other constraints are visible in the configuration. The agents supported are listed as Roo Code, Cline and Kilo Code, which is a small set rather than a general mechanism, so a different VS Code agent is not guaranteed to run. The description speaks of other IDE platforms in general terms, but the installation instructions, the supported IDE list and the plugin packaging are all JetBrains specific, and no instructions exist for Visual Studio, Neovim or an editor built on Eclipse. The contribution workflow is also light on testing guidance: the steps ask you to add tests and to run ./scripts/test.sh, but there is no coverage report, no compatibility matrix, and no statement about which IDE versions are verified against which agent versions.

## Staying in VS Code is the comparison that matters

The alternative for a JetBrains user is not another plugin. It is to keep the agent where it was built and use the editor it was built for. A VS Code agent running in VS Code talks to the real extension API, so there is no compatibility layer, no RPC hop and no second runtime to start, and every feature the agent ships is available without an emulation layer deciding otherwise.

What the bridge buys you is the opposite. A JetBrains user who has standardised on IntelliJ or WebStorm, who has project specific key bindings and a working debugger setup, and who wants Cline or Roo Code rather than the tool that comes with the IDE, gets to keep the environment and change the agent. That is a real saving for people who cannot or will move editors.

The trade-off is explicit: convenience in the editor against fidelity in the agent, plus an operational cost that the VS Code route does not have. RunVSAgent adds a Node.js 18 runtime, an RPC channel over a socket, a WebView layer for the agent interface and a plugin whose own package namespace is unusual. For a single developer trying an agent, that cost is small. For a team standardising on an agent across hundreds of workstations, it becomes a distribution problem, because a crash in the extension host now takes agent access down with it and the fix lives in a plugin, not in the IDE you already manage.

## Apache 2.0 licensing and a lumpy release history

The project is licensed under Apache License 2.0, with a LICENSE file at the root and a NOTICE file beside it, plus a Chinese translation of the README alongside the English one. Apache 2.0 is permissive, and its patent grant and modification clauses make it a comfortable choice for an internal tool that a company may want to fork and extend, subject to keeping the license and notice files in place.

The activity record is uneven. The repository is not archived and the last push was on 2026-05-12, so code is still moving. The tagged releases tell a different rhythm: 0.2.3 on 2025-09-03, 0.2.4 on 2025-10-21 and 0.2.5 on 2025-10-30, with no tag after that even though pushes continued. In practice the Marketplace build is the version most users will get, and the gap between a tagged release and the current main branch means the two can differ.

That gap is the thing to plan for. There is no changelog policy in the documentation and no documented upgrade path between plugin versions, so upgrading a managed installation is a matter of testing a new Marketplace build against your agent of choice and your IDE version, then rolling it out on your own schedule. There is also no stated support policy, which for a plugin that depends on both a JetBrains platform and a Node.js runtime is where the operational risk sits.

## Conclusion

RunVSAgent suits JetBrains users who want one specific VS Code agent, Cline or Roo Code, without leaving IntelliJ or WebStorm, and who can accept a plugin that depends on a separately running extension host. It does not suit teams that need many agents at once, that need non JetBrains editors, or that require a documented stable API between the two halves. Before committing, install the plugin from the JetBrains Marketplace, check the known issues page, and confirm that your IDE version is 2023.1 or later and that the Node.js 18 runtime starts cleanly on your machine. The last push was on 2026-05-12 and the most recent tagged release, 0.2.5, dates from 2025-10-30, so treat the current state as a project that still moves but does not tag often.

## FAQ

### What is RunVSAgent and which IDEs does it support?

RunVSAgent is a JetBrains plugin that lets VS Code based coding agents run inside JetBrains IDEs. The supported list includes IntelliJ IDEA, WebStorm, PyCharm, PhpStorm, RubyMine, CLion, GoLand, DataGrip, Rider and Android Studio, with JetBrains IDE 2023.1 or later required.

### How do I install RunVSAgent in IntelliJ IDEA?

Open Settings/Preferences, go to Plugins, search for RunVSAgent in the Marketplace tab, click Install and restart the IDE. You can also download a .zip from the GitHub releases page and use Install Plugin from Disk from the gear icon on the Plugins settings page.

### Which coding agents does RunVSAgent support?

The project names three: Roo Code, Cline and Kilo Code. Cline is described as an autonomous agent that can create and edit files, run commands and use a browser, with permission given at each step.

### What do I need to build RunVSAgent from source?

Node.js 18.0 or newer, a JetBrains IDE 2023.1 or newer, Git and JDK 17 or newer. The build runs ./scripts/setup.sh and then ./scripts/build.sh, and the plugin file is produced in the JetBrains plugin module's build distributions directory.

## Sources

- [Issues](https://github.com/wecode-ai/RunVSAgent/issues)
- [License: Apache-2.0](https://github.com/wecode-ai/RunVSAgent/blob/main/LICENSE)
- [README](https://github.com/wecode-ai/RunVSAgent/blob/main/README.md)
- [Releases](https://github.com/wecode-ai/RunVSAgent/releases)
- [wecode-ai/RunVSAgent on GitHub](https://github.com/wecode-ai/RunVSAgent)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wecode-ai-runvsagent