Short answers to what readers ask most about this topic.
The plugin runs a local MCP server, shares your editor selection on every prompt, and carries one security consideration that is specific to running inside an IDE.
Matthews Wong
Software Engineer
Key Takeaway
The Claude Code JetBrains plugin does not bundle the CLI — it runs the claude command in the IDE's integrated terminal and connects to it. While connected it runs a local MCP server named ide, which opens diffs in the native viewer and reads your selection, and exposes exactly one tool to the model: a read-only diagnostics reader.
I assumed the plugin was Claude Code, in the way a VS Code extension usually is. It is not: it is a bridge. It launches the CLI you already have in the IDE's terminal, then talks to it over a local socket — which is why the first thing it tells you when the CLI is missing is that it cannot launch Claude Code, and why installing the plugin alone gets you nowhere.
Understanding that architecture explains most of the plugin's behaviour, including the parts a security review will ask about. This post covers connecting from inside and outside the IDE, what the integration actually gives you, the local MCP server and exactly what it exposes to the model, the selection context that leaves on every prompt, and the one security note that applies to JetBrains specifically and not to a terminal session.
Install the CLI first and the plugin second, because the plugin runs the command rather than shipping it. If the command is somewhere your IDE cannot find, the plugin has a setting for the full path, and that same setting is how WSL users point it at their distribution.
# The plugin does NOT bundle the CLI. It runs the claude
# command in the IDE's integrated terminal and connects to it,
# so both pieces have to be installed.
# From the IDE's own terminal — all features active:
claude
# From an external terminal:
/ide
# -> "Connected to IntelliJ IDEA."
# If it finds a running IDE without the plugin, /ide installs
# the plugin and asks you to restart.
# Cmd+Esc / Ctrl+Esc open Claude Code from the editor
# Cmd+Option+K
# Alt+Ctrl+K insert a file reference such as
# @src/auth.ts#L1-99
# Settings -> Tools -> Claude Code [Beta]
# Claude command e.g. /usr/local/bin/claude, or for WSL:
# wsl -d Ubuntu -- bash -lic "claude"There are two ways to be connected. Running the CLI from the IDE's own integrated terminal activates everything automatically. From an external terminal, one command connects to a running IDE, and if it finds one without the plugin it offers to install the plugin for you. Either way, start from the project root if you want Claude to see the same files the IDE does.
Four things, and the fourth is more limited than people assume:
This is the part worth knowing precisely, because it is a local network service running on your machine and a reviewer will eventually ask what it is. It is deliberately hidden from the MCP list since there is nothing to configure, which means the people most likely to need to know about it are the ones least likely to stumble across it.
# The plugin runs a local MCP server the CLI connects to. It is
# named "ide" and hidden from /mcp because there is nothing to
# configure — but if your organisation allowlists MCP tools in
# a PreToolUse hook, you need to know it exists.
# Transport and auth:
# ephemeral OS-assigned port, not configurable
# unencrypted ws:// — on loopback, anything that could
# capture the traffic can also read the token, so TLS
# would add nothing against a local attacker
# a fresh random token per IDE start, written to
# ~/.claude/ide/<port>.lock
# the CLI presents it as
# X-Claude-Code-Ide-Authorization
# Tools the MODEL can see: exactly one.
mcp__ide__getDiagnostics read-only; the IDE's inspection
errors and warnings
# The rest are internal RPC the CLI uses for its own UI —
# opening diffs, reading selections — and are filtered out
# before the tool list reaches Claude. The JetBrains plugin
# exposes NO code-execution tool to the model.The design decision worth appreciating is the tool filter. The server hosts several tools, but only the read-only diagnostics reader is visible to the model — the rest are internal calls the CLI uses to drive its own interface, filtered out before the tool list ever reaches Claude. The JetBrains plugin exposes no code-execution tool to the model at all, which is a meaningfully smaller surface than the integration's capabilities might suggest.
While connected, the CLI attaches your current editor selection and the active file's path to every prompt you send, and the transcript shows a line saying so. That is the feature working as designed, and it is also a data-flow you should be deliberate about — the file you happen to have open when you ask an unrelated question goes along with it.
# While connected, the CLI includes your current editor
# selection and the active file's path as context on EVERY
# prompt you send. The transcript shows:
#
# ⧉ Selected 12 lines from src/auth.ts
#
# To stop a sensitive file reaching Claude this way, add a Read
# deny rule for its path. A matching rule blocks BOTH the
# selected text and the open-file notice.
{
"permissions": {
"deny": ["Read(./.env)", "Read(./config/secrets.yml)"]
}
}
# The same deny rules also stop the plugin sharing those files
# through the selection-context channel, which is the part
# people forget when they audit what leaves the machine.This one does not apply to a plain terminal session and is easy to miss. When Claude Code runs inside a JetBrains IDE in accept-edits mode, it may be able to modify IDE configuration files that the IDE itself executes automatically. That is a route to running code without going through the permission prompt for shell execution, because the execution is the IDE's, not Claude's.
The practical consequence is that accept-edits and auto mode are a bigger grant inside an IDE than outside one. Both approve edits within your working directory without asking, apart from protected paths, and inside a JetBrains project that directory contains files with execution semantics. Manual mode for edits is the conservative choice here, and it is a defensible one rather than paranoia.
Four problems account for most of what goes wrong, and each has a specific cause rather than a general one.
Symptom to cause:
| Symptom | Usual cause |
|---|---|
| Escape does not interrupt Claude Code | The IDE terminal binds Escape to move focus to the editor — unbind it in terminal settings |
| No available IDEs detected under WSL2 | WSL2 NAT networking or Windows Firewall blocking the connection to the IDE on the host |
| Features missing in Remote Development | The plugin was installed on the local client rather than the remote host |
| Command not found when clicking the icon | The CLI is not on the IDE's path — set the full path in plugin settings |
For the WSL2 case, prefer switching to mirrored networking over opening a firewall rule where you can. Mirrored networking shares the Windows loopback interface with the Linux VM, which lets the socket stay on loopback — and that keeps you away from the plugin's option to accept connections from all network interfaces, which is the setting you genuinely want to avoid.
The plugin can bind its MCP server to all network interfaces rather than loopback only, and the option exists for real cases where the CLI cannot reach the IDE over loopback. It is still the setting to think hardest about before enabling, because of what the transport is.
Connections require the auth token from the lock file either way. But the transport is unencrypted, so with the setting on, both the session traffic and that token cross your local network in cleartext. On loopback that is a non-issue — anything that could capture the traffic could read the lock file anyway — and on a shared network it is a different proposition entirely.
The plugin is a bridge rather than an application, and almost every question about it resolves once you hold that shape in mind: the CLI does the work, the plugin lends it the IDE's diff viewer, selection and diagnostics, and a small local socket joins them. The two things worth deciding deliberately are which permission mode you run in, because an IDE directory contains files that execute themselves, and whether that socket ever needs to leave loopback. The answer to the second is almost always no.
Sources & further reading