JetBrains Extension

What it integrates#

The Claude Code JetBrains plugin embeds a Claude Code session inside any IntelliJ Platform IDE — IntelliJ IDEA, PyCharm, WebStorm, GoLand, RubyMine, PhpStorm, Rider, CLion, Android Studio. One plugin binary, one set of capabilities, exposed differently by each IDE based on which languages it ships with.

What it integrates:

• Tool window — a dedicated tool window pinned to the side or bottom, hosting the chat with the workspace project.
• Editor selection and active file — same affordances as the VS Code extension: selected code is injected into the turn, the active editor is known.
• Inspection results — JetBrains’ inspections (the equivalent of VS Code diagnostics) feed into a built-in tool the model can call. Quick-fixes are a first-class concept and the model can preview them in chat.
• Diff viewer integration — proposed edits open in the IDE’s three-way diff viewer; accept, reject, or merge manually.
• Run configurations — the model can read your project’s run configurations and invoke them via the plugin’s RunConfiguration tool.
• Terminal — the IDE’s built-in terminal hosts Bash tool calls.
• VCS integration — the model knows about the project’s Git roots, current branch, and changelists; relevant changes are highlighted.

What it does not do: replace the CLI. The plugin shells out to the same claude binary; settings, MCP servers, hooks, and auth are shared.

Setup#

Prerequisites#

• A JetBrains IDE on a supported version line. Most JetBrains IDEs follow a quarterly release; the plugin targets the two latest major versions.
• The claude CLI installed and authenticated. See Installation and First Run.
• An open project (the plugin is project-scoped; without a project the experience is degraded to a basic chat).

Install#

In the IDE: Settings → Plugins → Marketplace, search “Claude Code”, install, restart the IDE when prompted.

Or via command line:

# IntelliJ-family ships an IDE-specific bin/ directory; the binary name varies:
#   idea, pycharm, webstorm, goland, etc.
idea installPlugins com.anthropic.claude-code

After install, a “Claude Code” tool window appears (typically docked right). Click it to open the panel.

First-run flow#

1. Open a project.
2. Click the Claude Code tool-window stripe.
3. The plugin checks claude auth status. If unauthenticated, it opens a built-in terminal tab and runs claude auth login; complete the browser flow.
4. The panel binds to the current project. Subsequent turns share state until cleared.

Settings#

Plugin settings live in Settings → Tools → Claude Code:

• Model — model identifier (e.g. claude-opus-4-7).
• Permission mode — default / accept-edits / plan / bypass.
• CLI path — auto-detected; override if claude lives somewhere unusual.
• Auto-open diff — open the diff viewer on proposed edits (default: on).
• Include inspections in context — feed inspection results into each turn (default: off; opt-in because IntelliJ inspections can be noisy).
• Send selection — auto-include the active editor selection (default: on).

Project-level overrides live in .idea/claudeCode.xml (committed to the project if you want it shared). User-level lives in the IDE config directory (~/Library/Application Support/JetBrains/<IDE><version>/options/ on macOS, ~/.config/JetBrains/<IDE><version>/options/ on Linux).

Keymap#

The default actions, all rebindable in Settings → Keymap → Plugins → Claude Code:

• Start Turn — submits the current input box; default Ctrl+Enter.
• Accept Edit — applies the proposed edit; default Cmd+Shift+A (macOS) / Ctrl+Shift+A (Linux/Windows).
• Reject Edit — discards the proposed edit; default Cmd+Shift+R / Ctrl+Shift+R.
• Focus Panel — toggles the tool window; default Cmd+Shift+C / Ctrl+Shift+C.
• Ask About Selection — opens the panel with the current selection as a quoted block; default unbound (worth binding).

Capabilities#

Inspection-driven fixes#

JetBrains IDEs ship hundreds of inspections — code style, possible bugs, performance issues, language-specific hazards. The plugin exposes a getInspections(scope) tool the model can invoke for the active file, the open files, or the whole project.

Phrasings the model handles well:

• “Fix the warnings IntelliJ is reporting on this file.”
• “What does the ‘Suspicious method call’ inspection on line 42 mean? Fix it if you agree.”
• “Run inspections on the whole module and list the top five most-frequent.”

The plugin can also apply quick-fixes the model proposes via the IDE’s own InspectionEngine, which keeps the fix consistent with how the IDE would do it manually.

Refactor integration#

The plugin exposes a subset of the IDE’s refactorings as tools:

• renameSymbol(file, line, column, newName) — invokes Rename Refactoring, which is safer than a model-driven text replacement because it understands references.
• extractMethod(file, range, name) — Extract Method, again using the IDE’s structural-refactoring engine.
• moveClass(class, targetPackage) — Move Class with reference updates.

These are conservative — the model invokes them when it knows the operation is well-modelled by the IDE’s refactoring infrastructure. For everything else, it falls back to Edit and Write.

Run configurations#

You: "Run the integration tests against the staging profile."

The plugin reads .idea/runConfigurations/*.xml, finds a configuration named IntegrationTests with the staging profile, and invokes it via the IDE’s run system. Output streams to the chat with a link to the IDE’s run window.

VCS context#

The plugin reports the project’s Git roots, current branch, ahead/behind status, and unstaged changes to the model on session start. The model doesn’t ask “what branch are we on?” — it already knows. Changelists (IntelliJ’s grouping of pending changes) are exposed as a tool too.

Notebooks and other specialised editors#

Jupyter notebook support (PyCharm Professional) integrates cell-level operations the same way as VS Code’s notebook editing. Database tool window (in IDEs with database support) integration is more limited — the model can read query results that are already in the IDE’s result panel, but doesn’t drive the database tool directly.

Configuration#

Where settings come from#

Precedence top-down:

1. .idea/claudeCode.xml in the project (if committed, shared with the team).
2. User-level IDE config (your personal defaults for this IDE).
3. Plugin defaults.

CLI-level Claude Code settings (~/.claude/settings.json, .claude/settings.json in the project root) still apply because the plugin shells out to claude.

Per-IDE quirks#

The same plugin runs on every IntelliJ-family IDE, but each IDE bundles different inspections, language servers, and tool windows. Practical implications:

• IntelliJ IDEA Ultimate — broadest inspection set; Spring, JPA, framework-specific inspections all surface to the model.
• PyCharm — type inference is via the IDE’s own engine; inspections include duck-typing and Pyright-style nullability.
• WebStorm — TypeScript inspections come from the bundled tsserver; the model gets the same diagnostics it would in VS Code.
• GoLand — gopls is the inspection source; the plugin pipes gopls’s diagnostics through getInspections.
• Android Studio — Android Lint inspections appear too. The model treats Android-specific issues (e.g. main-thread network call) as actionable.

Memory and CPU#

The IntelliJ Platform is heavier than VS Code. The plugin itself is cheap; the indexes the IDE maintains so the model has useful inspections are not. Two practical knobs:

• Increase IDE heap if you run Claude Code alongside heavy refactorings: Help → Change Memory Settings → Heap Size → 4096 MB (or higher).
• Reduce inspection scope in Settings → Editor → Inspections if context-inclusion is on and the per-turn payload is too large.

Shared MCP servers#

The plugin uses the same MCP config as the CLI. A ~/.claude/mcp.json or ~/.claude.json mcpServers block is picked up identically. There’s no JetBrains-specific MCP registry.

Failure modes#

The recurring failures with the JetBrains plugin:

• claude binary not on PATH from inside the IDE. Same root cause as the VS Code variant: GUI-launched apps on macOS don’t inherit shell PATH. Fix: set the CLI path explicitly in plugin settings, or add claude’s directory to /etc/paths.
• Inspections take a while on first index. Opening a new project triggers a full index build; the model’s getInspections returns empty during this phase. Wait for “Indexing” in the status bar to clear.
• Diff viewer collides with active merge. If you’re in the middle of a Git merge conflict resolution, the diff viewer is already in use. The plugin queues the proposed edit and notifies; resolve the merge first.
• Edits accepted but undo doesn’t include them. The plugin applies edits as a single command, so Cmd+Z undoes the entire batch. Surprising the first time; switch to Local History → Revert Selected Changes for granular rollback.
• Plugin freezes during long-running Bash tool calls. The IDE’s terminal tab is async, but the plugin’s chat view waits for the call to finish. A pnpm build that takes 5 minutes will leave the panel apparently unresponsive; it isn’t — it’s waiting. The status line shows the running tool.
• MCP servers fail to launch. Environment differences: the IDE’s env is not your shell’s env. Set mcpServers.*.env entries explicitly, or launch the IDE from a terminal that has the right env (idea . from the project directory) so it inherits.
• Hooks fire but with wrong PATH. Same root cause; set PATH explicitly in hook scripts.
• VCS context is stale after a branch switch. The plugin caches Git state per turn; switching branches mid-session means the next turn still thinks you’re on the old branch until the IDE’s vcs.log refreshes (usually a few seconds).

Security and permissions#

What the plugin gains access to#

When you run the plugin against a trusted project, Claude Code inherits the IDE’s process privileges:

• Read and write every file in the project.
• Run shell commands as your user.
• Reach any network endpoint reachable from your machine.
• Invoke the IDE’s refactoring engine — which can modify any file in the project.

The IDE itself is not a sandbox. The plugin is a thin layer over the CLI, which has full user privileges.

Trusted projects#

JetBrains IDEs ship a “trusted projects” model similar to VS Code. Untrusted projects:

• Build tools (Gradle, Maven, npm) run in restricted mode or are blocked outright.
• The Claude Code plugin disables write-capable tools (Edit, Write, Bash).
• MCP servers configured at the project level don’t load.

Don’t trust a project you haven’t reviewed for .idea/claudeCode.xml, .claude/settings.json, and CLAUDE.md. All three can change behaviour on session start.

Auth state is shared with the CLI#

The OAuth token is in the OS keychain; the plugin shares it with the terminal CLI. Logging out anywhere logs out everywhere.

Comparison: same product, two IDEs#

Functionally the model is the same on both. The IDE-specific affordances are about how much of the surrounding editor capability the model can lean on.

Permission rules and the bypass mode#

The four permission modes apply identically:

• default — prompts on every consequential tool call.
• accept-edits — auto-accepts file edits but prompts on Bash and write-capable MCP calls.
• plan — read-only.
• bypass — everything auto-approved.

Bypass mode inside the IDE is more tempting than in the terminal because the diff viewer cushions the cost of a bad edit (you can see what changed). Resist anyway — Bash and MCP write tools are not cushioned.

Related integrations#

• VS Code Extension
• Installation and First Run
• File Tools — Read, Edit, Write
• Settings and Configuration
• Permission Rules and Allowlists