Claude Code for JetBrains: The Plugin and Its MCP Server

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.

Two pieces, and the order they go in

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.

What the integration actually adds

Four things, and the fourth is more limited than people assume:

• Diffs open in the IDE's native diff viewer instead of the terminal, controlled by a setting that only appears once you are connected.
• Your current selection or tab is shared with Claude Code automatically, so you can ask about this function without pasting it.
• A shortcut inserts a file reference with a line range, which is the fastest way to point Claude at a specific region.
• Claude can read the IDE's inspection diagnostics — but only by explicitly calling for them. Claude Code does not request diagnostics from the plugin on its own after an edit, so if you want the IDE's opinion on a change, ask for it.

The local MCP server, and what it exposes

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.

Selection context leaves on every prompt

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.

The security note that is specific to IDEs

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 failures worth recognising

Four problems account for most of what goes wrong, and each has a specific cause rather than a general one.

Symptom to cause:

The networking setting to leave alone

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.