GitHub Copilot with JetBrains IDEs

One plugin serves the entire JetBrains family. Install it in IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, RubyMine, PhpStorm, CLion, DataGrip, RustRover or Android Studio and you get the same Copilot — the same features, the same key bindings, the same preview flags.

That uniformity is the JetBrains story, and it cuts both ways. Learn it once and it transfers across every JetBrains IDE you use. But when something is in preview, it is in preview everywhere at once.

Which IDEs are covered

Two things worth extracting. The Community editions of IntelliJ IDEA and PyCharm are included, so Copilot does not require a paid JetBrains licence. And Android Studio is on the list — it is a JetBrains-platform IDE like the others, which is why it has no separate Copilot implementation.

Installation

The flow is the same in every IDE in the family.

1. Open your JetBrains IDE.
2. Go to Plugins settings.
3. Search the Marketplace for GitHub Copilot and click Install.
4. Click Restart IDE.
5. After restarting, go to Tools → GitHub Copilot → Login to GitHub.
6. In the sign-in dialog, click Copy and Open to copy the device code and open the activation page.
7. Paste the device code in the browser, click Continue, and authorise.

Installing from inside the IDE rather than downloading a plugin file has a practical benefit: the Marketplace only offers builds compatible with your IDE version, so the compatibility question resolves itself.

What is fully supported

The things you use hourly are not in preview:

• Code completion and chat
• Agent mode — and edit mode, which Visual Studio, Eclipse and Xcode do not have
• Checkpoints, for rolling a session back
• Copilot code review, in the editor
• MCP, for connecting external tools
• Workspace indexing and code referencing

That is a stronger position than JetBrains is usually given credit for. On the features that structure a working day, JetBrains and VS Code are close to equivalent.

What is in preview

The customisation layer, almost in its entirety:

Preview means subject to change rather than broken — these features work. What you should not do is build a team standard on one and assume it behaves identically to the VS Code version, because that is exactly what preview status does not guarantee.

Personal custom instructions

One place JetBrains is ahead: it is the only IDE family where GitHub documents support for personal custom instructions — preferences attached to your account rather than to a repository.

The useful distinction is scope. Repository instructions describe the project — its conventions, its test framework, its structure — and belong in version control where the whole team gets them. Personal instructions describe you — how much explanation you want, whether you prefer terse answers — and should not be checked in.

Slash commands

JetBrains has a distinctive set:

/compact deserves a mention regardless of origin. Long sessions degrade as the context window fills, and compacting is the documented way to keep one going without starting over.

Keyboard behaviour

These match VS Code apart from the separate pane, which is Alt+Enter here rather than Ctrl+Enter.

Rebinding is done in Settings → Keymap, searching for Copilot.

Agent mode and edit mode here

JetBrains is one of only two IDE families with both edit mode and agent mode fully supported — VS Code is the other. Visual Studio, Eclipse and Xcode have agent mode without edit mode, which makes the JetBrains position worth using deliberately.

The distinction is control. Edit mode changes files you nominate and stops there: no commands, no file creation you did not ask for, no iteration. Agent mode decides for itself which files to touch, runs commands, reads output and tries again.

The rule that holds up in practice is that scope decides the mode. If you can name the files, use edit mode. If naming them is the hard part, use agent mode.

Two boundaries specific to this platform are worth stating.

The build system is not a safe playground. Agent mode can run commands, and in a JetBrains project those commands are frequently Gradle or Maven tasks. A Gradle build can execute arbitrary code from the build script and its plugins. Read what the agent proposes to run — approval is the boundary, and it is only a boundary if you read it.

Checkpoints make experiments cheap, not free. Because JetBrains supports checkpoints, an agent session that goes wrong can be rolled back. That is a genuine safety net for exploration. It does not cover anything the agent did outside the workspace — a command that touched a database or a remote service is not undone by rolling back files.

Refactoring: use the IDE, not the model

This is the JetBrains-specific habit that saves the most time, and it runs against the instinct to ask Copilot for everything.

JetBrains refactorings — rename, extract method, change signature, move class, introduce parameter — are correct by construction. They work from the IDE’s resolved symbol graph, so a rename updates every genuine reference and nothing that merely shares a name. Copilot, asked to do the same thing, is doing a very well-informed text transformation.

For anything the IDE has a refactoring for, use the refactoring. Reserve Copilot for the transformations that require judgement rather than mechanism:

The productive pattern combines them: ask Copilot what the problem is, then use the IDE’s refactorings to make the change safely.

That prompt plays to both tools’ strengths, and the resulting change is one the IDE has verified rather than one you have to review line by line.

How JetBrains context differs

JetBrains IDEs maintain their own deep index of a project — symbols, references, inheritance hierarchies, framework configuration. That index is what powers “find usages” and refactoring, and it is considerably richer than a text search.

Copilot benefits indirectly. When the IDE understands your project structure, the context supplied to Copilot is better-formed than in an editor that sees a folder of files. This is most noticeable on large projects, where JetBrains’ model of modules and dependencies keeps the relevant material in view.

There is a second, less obvious benefit: the IDE checks Copilot’s work as you accept it. Inspections, type checking and unresolved-reference highlighting all run against generated code the moment it lands. A suggestion referencing a method that does not exist is flagged immediately rather than at compile time — a genuinely useful safety net that VS Code provides less consistently outside strongly typed setups.

Differences from VS Code, summarised

The absence of chat variables is the difference you feel most often. In VS Code you write #selection and know exactly what was attached; in JetBrains you select code and rely on the IDE passing it. Being explicit about scope in the prompt itself partly compensates:

A worked example: adding an endpoint

Concrete enough to follow, in a Spring Boot project, using the tools in the order that actually works.

Ask before writing. The IDE knows where things are; Copilot can tell you what the change touches.

Write the contract, let completion fill it in. Declare the controller method with its annotations, path, parameters and return type. Completion given a precise signature and a project full of similar endpoints produces a body that is usually close to right, because the surrounding code has already answered most of the open questions.

Let the inspections review it. Accept the suggestion and look at the gutter before anything else. An unresolved repository method, a nullability warning or an unused parameter shows up instantly. This is the JetBrains advantage and it costs you two seconds.

Generate tests against the existing ones. Open a comparable test class before asking, so the generated tests inherit its framework, fixtures and naming rather than a generic default.

Run them. In the IDE’s test runner, reading the results yourself.

Review the diff. In the Git tool window, before committing. Reading changed files in place invites you to see what you expected rather than what is there.

The pattern generalises: Copilot for the parts that need judgement about what to build, the IDE for the parts that need correctness about how it is built.

Writing instructions that survive preview status

Because custom instructions are in preview across the JetBrains family, the way you write them matters more than it does in VS Code. Instructions that describe verifiable facts about the project degrade gracefully; instructions that depend on subtle behavioural nuance do not.

A repository file that works well here:

# Copilot instructions

## Stack
- Kotlin 2.1, Spring Boot 3.4, Gradle with the Kotlin DSL.
- Tests are JUnit 5 with MockK. Do not use Mockito or JUnit 4.
- Persistence is Spring Data JPA. Do not write raw SQL.

## Conventions
- Constructor injection only. No field injection, no `@Autowired` on fields.
- Every public API type is a data class in `api/dto`. Entities never leave the
  service layer.
- Nullability is expressed in the type. Do not use `!!`.

## When generating tests
- One behaviour per test, named `methodName_condition_expectedResult`.
- Use the existing fixtures in `src/test/kotlin/fixtures` rather than building
  new objects inline.

Every line there is checkable. If Copilot ignores one, you notice immediately — a Mockito import or a !! stands out. Compare that with “write idiomatic Kotlin”, which is unfalsifiable and therefore useless as an instruction and invisible when it fails.

Personal instructions follow the opposite logic — they are about your working style, and nobody else needs to agree with them:

That last line earns its place. Plausible-but-nonexistent API methods are one of the more common failure modes, and asking for uncertainty to be stated is a cheap partial mitigation — though the IDE’s own unresolved-reference highlighting remains the reliable catch.

Working across several JetBrains IDEs

Plenty of developers run two or three: IntelliJ for the backend, WebStorm for the front end, DataGrip for the database. A few habits make that comfortable.

The plugin updates per IDE. Each installation carries its own plugin version. If a feature behaves differently in one IDE than another, compare plugin versions before concluding the IDEs differ — usually they do not.

Sign in everywhere. The device-code flow is per-IDE. A fresh IDE will need its own authentication even though the account is the same.

Repository instructions travel; personal ones may not. Repository instructions live in the repository, so any IDE opening that project reads them. Treat personal instructions as something to set up per installation rather than assuming they follow you.

Keymaps can drift. If you have customised Copilot bindings in one IDE, they are not automatically present in another unless you sync settings through JetBrains’ own settings synchronisation.

The per-IDE lessons

The plugin is identical everywhere, but what you do with it is not. Three JetBrains IDEs get their own lesson:

• IntelliJ IDEA — Java and Kotlin, Maven and Gradle, JUnit, and where IntelliJ’s analysis catches Copilot’s mistakes.
• PyCharm — interpreters and virtual environments as context, type hints, pytest, and framework work.
• Android Studio — what “supported through the JetBrains plugin” means in practice, and coexisting with Gemini.

For WebStorm, GoLand, Rider, RubyMine, PhpStorm and the rest, everything on this page applies unchanged — the differences are in the language ecosystem, not in Copilot.

Coexisting with JetBrains AI Assistant

JetBrains ships its own AI Assistant, and it can be installed alongside Copilot. Running both is legitimate but needs a decision, because two plugins offering inline completions in the same editor produce a confusing experience — grey text appearing from two sources with different accept keys.

The practical arrangement is to pick one for inline completion and disable the other’s, then use whichever suits each task for chat. JetBrains’ assistant is tied more tightly to IDE actions such as commit-message generation and refactoring suggestions; Copilot is stronger on agent workflows and integrates with the rest of the GitHub platform.

Security

Frequently asked questions

Do I need a paid JetBrains licence? No. IntelliJ IDEA Community and PyCharm Community are both on GitHub’s compatibility list. You need a Copilot subscription, not a JetBrains one.

Is it a different plugin for each IDE? No — one plugin, published by GitHub, compatible with the whole family. That is why Android Studio needs no separate implementation.

Why does sign-in seem to do nothing? The device-code flow needs you to paste a code into a web page and authorise there. Until that completes, the IDE stays unauthenticated with no error.

Does JetBrains have agent mode? Yes, fully supported — along with edit mode and checkpoints, which several other editors lack.

Why are custom instructions in preview here but supported in VS Code? Preview status is per-editor and reflects rollout, not capability. The feature works; its behaviour is not yet guaranteed stable.

Can I use #file like in VS Code? No. Chat variables and chat participants are VS Code features. Select the code you mean and state the scope in your prompt instead.

What are /chronicle and /compact? They belong to Copilot CLI sessions run inside JetBrains rather than to IDE chat. /compact is the documented way to keep a long session usable as context fills.

Should I turn off JetBrains’ own AI assistant? Not necessarily, but running two assistants that both offer inline completions produces confusing results. Pick one for completion and let the other cover what it does better.

Troubleshooting

Next steps

If you work in a specific JetBrains IDE, go to its lesson: IntelliJ IDEA, PyCharm or Android Studio.

For how JetBrains compares with the alternatives, see GitHub Copilot for IDEs. For the agent workflow in depth — most of which applies here, since JetBrains supports agent mode, edit mode and checkpoints — see Agent Mode in VS Code.