GitHub Copilot in JetBrains IDEs

JetBrains IDEs have full Copilot support, and it is not identical to VS Code’s.

That difference is the reason this is a separate lesson rather than a paragraph. Assuming parity is the most common source of frustration for JetBrains users reading Copilot material written for VS Code — a feature described confidently turns out to be somewhere else, in preview, or configured differently.

Before you start

• GitHub Copilot complete guide — the surfaces and customisation layer
• Copilot in VS Code — useful for comparison

The modes

Copilot Chat in JetBrains IDEs offers three modes, and choosing between them is most of using it well.

Agent mode — the default. The full agentic experience: Copilot works autonomously toward a task, proposing changes and iterating.

Ask mode — questions and assistance without making code changes. The right mode for understanding code, and for anything where you want an answer rather than an edit.

Plan mode — collaboration on the approach before implementation. Copilot analyses the request and produces a structured plan for your review.

Plan mode deserves emphasis because it addresses the biggest risk in agentic work directly. Correcting a plan costs a sentence; correcting six edited files costs a review. On any task where the approach is not obvious, planning first is the cheapest intervention available.

Copilot Edits, with Edit mode, allows controlled edits across multiple files from a single chat prompt — a middle ground between a single-file change and full agent autonomy.

Two ways to run it

A genuine architectural point, and one that is changing.

The GitHub Copilot plugin is the comprehensive and recommended option. Notably, the plugin is transitioning from its own local agent harness to Copilot CLI as the default agent harness — which means the agentic behaviour you get in JetBrains is converging on the behaviour documented in the CLI cluster.

That convergence is good news for anyone learning both: the permission model, custom agents, skills and hooks are increasingly the same machinery rather than two parallel implementations.

JetBrains AI Assistant can also host Copilot as a native agent through the Agent Client Protocol. With a valid Copilot subscription, Copilot appears in the AI Assistant agent picker automatically. This suits developers who prefer working inside AI Assistant’s panel, or who would rather not install an additional plugin.

The plugin is the fuller experience. The AI Assistant route is lower-friction if you already use it.

Availability

Copilot's JetBrains feature set differs from VS Code's, and several capabilities carry preview status. The plugin's agent harness is transitioning to Copilot CLI. Verify current support before depending on a specific capability. Confirm the current position in the Copilot in JetBrains IDEs.

Customisation support

The important table on this page, because this is where assumptions break.

Mechanism	JetBrains
Repository instructions (.github/copilot-instructions.md)	Supported
Path-specific instructions (.github/instructions/)	Supported
Personal custom instructions	Supported
Agent instructions (AGENTS.md and variants)	Supported for cloud agent work
Prompt files (.github/prompts/*.prompt.md)	Preview
Agent skills	Preview
Custom agents	Preview
MCP servers	Supported
Hooks	Not supported in the IDE
Copilot code review	Repository-wide and path-specific instructions

Two practical readings.

The always-on layer is solid. Repository and path-specific instructions work, which means the highest-value customisation — making Copilot fit your codebase — is fully available.

The newer mechanisms are preview or absent. Anything a team builds on prompt files, skills or hooks should be checked against JetBrains before it becomes load-bearing for JetBrains users.

Mixed-editor teams need the common denominator

A team where some people use VS Code and some use JetBrains should build its shared configuration on what both support well: repository instructions and path-specific instructions.

Those live in the repository, are reviewed like code, and apply everywhere. A workflow built on prompt files works for half the team and silently does nothing for the other half — and the half it does nothing for will not get an error, they will just get worse results.

Where a capability genuinely needs to work for everyone, check the matrix before committing to it.

Model selection

JetBrains exposes model switching and reasoning-depth adjustment from the chat panel, without leaving it.

The trade-off is the same as everywhere: a more capable model reasons better across a complex multi-file change and is slower; a faster one suits iterative work where you are in the loop. Adjusting reasoning depth is the finer-grained version of the same choice.

As on every surface, availability depends on plan and organisation policy, and specific model names age too quickly to be worth memorising.

MCP in JetBrains

MCP is supported, which matters because it is one of the newer mechanisms that is not preview here.

The practical effect is that an agent in a JetBrains IDE can reach external tools and data — the GitHub MCP server for issues and pull requests, a documentation server, an observability integration — on the same footing as VS Code.

The same two configuration decisions apply as everywhere:

Prefer read-only. The GitHub MCP server supports a read-only mode that disables write tools entirely. For reading issues and pull requests, which is most of the value, that is sufficient.

Connect deliberately. Each server is capability and attack surface together. See MCP + GitHub for the trust model.

A worked task

The shape that plays to JetBrains’ strengths: a change where the IDE handles the mechanical part and Copilot handles the judgement.

The task. A service class has grown to handle both order validation and payment dispatch. Split it.

1. Ask mode first. “Explain what OrderService currently does, and which methods belong to validation versus payment.” No edits — you are establishing the boundary.

2. Check the answer against the IDE. Use the structure view and usage search. This takes a minute and confirms or corrects the proposed split.

3. Plan mode for the change. “Split OrderService into OrderValidator and PaymentDispatcher, keeping the existing public interface intact.” Read the plan.

4. Let the IDE do the extraction. Extract class, move members, rename — all deterministic, complete, and instant. This is the part Copilot should not be doing.

5. Agent mode for the leftovers. Updating tests, adjusting the call sites the refactoring could not infer, adding the new classes’ documentation.

6. Run the tests. Then review the diff.

Step 4 is the point of the example. A large mechanical refactor is exactly what JetBrains does perfectly and an agent does approximately — and using the agent for it produces a slower, less complete result that you then have to verify. The division of labour is the skill.

Working well in JetBrains

Habits that matter more than configuration.

Use Ask mode when you want an answer. Agent mode’s default-to-action is helpful when you want a change and unhelpful when you wanted to understand something first.

Use Plan mode for anything non-obvious. The structured plan is a review artefact, and reviewing it is the cheapest correction point in the interaction.

Attach context explicitly. The IDE contributes the open file and selection; anything else — the caller, the interface, the test — is worth attaching. This is the same lesson as every other surface and it is the highest-leverage habit on all of them.

Lean on the IDE’s own analysis. JetBrains IDEs have unusually strong static analysis and refactoring tools. For a rename across a project, the built-in refactoring is deterministic, complete and instant — an agent doing the same work is slower and less certain. Use Copilot for what the IDE cannot do, not for what it does perfectly.

That last point is worth dwelling on: the best JetBrains Copilot workflow uses less of Copilot than the equivalent VS Code one, because more of the mechanical work is already handled well.

Context, and what the IDE contributes

JetBrains IDEs maintain a rich model of your project — a symbol index, type information, usage graphs, framework awareness. Some of that reaches Copilot and some does not, and knowing roughly which is useful.

Reliably contributed: the open file, your selection, and the immediate surroundings of the cursor.

Contributed by you: files you attach, and anything you paste. Deterministic, and the lever you control.

Available to agent surfaces: files the agent searches for and reads during a task. Powerful and non-deterministic — it may not find what you had in mind.

Not directly contributed: the IDE’s own analysis results. Copilot does not see the inspection warnings, the call hierarchy or the type resolution the IDE has already computed; it reads the code and draws its own conclusions.

That last point has a practical consequence worth acting on. When you already know something the IDE told you — that a method has eleven callers, that a type is nullable here, that an inspection is flagging a specific line — say it. You are supplying information the model cannot otherwise obtain, and it is usually the information that determines the right answer.

Where JetBrains is strongest

Being concrete about the fit.

Understanding unfamiliar code, using Ask mode alongside the IDE’s navigation. Jump to a definition, ask what it does, follow the usages — the combination is better than either alone.

Multi-step reasoning tasks, which the chat-centric workflow suits: describe a goal, let Copilot plan, iterate conversationally.

Test generation, where the IDE knows the test framework and the layout conventions of your project and Copilot writes the cases themselves.

Language-specific idiom, particularly in Kotlin, Java and Python where the IDE’s own type information sharpens what the model produces and its inspections catch what the model gets wrong.

Where it is weaker than the terminal or a dedicated agent surface: anything where the context is command output rather than code. A failing Docker build or a Terraform plan is better handled in Copilot CLI, where the output is already present.

Completions and inline work

Less discussed than the agentic features and still the highest-frequency interaction.

Inline suggestions in JetBrains behave as they do elsewhere: they draw on the current file and related context the IDE supplies, and they are best at completing something you have started. The IDE’s type information makes them noticeably better in strongly-typed languages than the same feature in a weaker-typed setting — the model has more to work from.

Two habits improve them.

Write the signature and the doc comment first. A function with a name, parameter types and a sentence describing what it does gives the completion enough to produce a real body. An empty function body gives it a name to guess from.

Accept partially. Where the integration supports accepting a word or a line rather than the whole suggestion, that is often the right granularity — the first line is usually right and the last three are a guess about your intent.

The verification cost is low because the unit is small, which is why completions remain the least controversial Copilot feature: you read it, you accept or you do not, and a wrong one is obvious immediately.

Team configuration that travels

The practical conclusion from the support matrix, stated as a recommendation.

Put these in the repository, where every JetBrains and VS Code user gets them:

• .github/copilot-instructions.md — conventions, constraints, the things not inferable from code
• .github/instructions/*.instructions.md — rules that differ by area
• AGENTS.md — where you also use agent surfaces

Treat these as enhancements, not foundations, until you have confirmed your team’s coverage:

• Prompt files, agent skills, custom agents — preview in JetBrains
• Hooks — not available in the IDE

Review instruction files like code. They change how every contributor’s tooling behaves, which makes them a shared artefact rather than a personal setting, and a CODEOWNERS entry is reasonable.

The test for whether a piece of configuration belongs in the repository: would a new team member using a different editor be worse off without it? If yes, it belongs in the repository and should be built on mechanisms that work in both.

Debugging the setup

Instructions not applying. Check the exact path, and confirm the repository root is what the IDE thinks it is — a monorepo opened at a subdirectory may not see .github/ at the level you expect.

A feature is missing. Preview status or organisation policy. On JetBrains, preview status accounts for more of these than on VS Code.

Agent behaviour differs from a colleague’s. Check whether you are on the plugin or the AI Assistant integration, and whether the plugin is using the CLI harness. These are genuinely different code paths.

Answers ignore project context. Attach the files. IDE-supplied context is the open editor, not the project.

Copilot code review from JetBrains

One surface-specific detail worth knowing: Copilot code review in JetBrains reads both repository-wide and path-specific instructions — which is better coverage than some other IDEs, where only repository-wide instructions apply.

That matters if your team relies on path-specific review criteria. Review instructions that say “database migrations must include a rollback plan” only shape review where path-specific instructions are read, and the surfaces differ.

The review itself happens on the pull request regardless of which editor produced the code, so this is about the IDE-side review experience rather than about the pull request one. See the code review cluster for the full picture, including the security consequence of review instructions being read from the branch under review.

Common mistakes

Assuming VS Code parity. The single most common source of confusion, and the reason for the table above.

Using agent mode for questions. Ask mode exists and does not edit your files.

Skipping plan mode on complex work. The plan is the cheapest place to catch a wrong approach.

Using Copilot for refactorings the IDE does deterministically. Slower and less reliable than the built-in tool.

Building team workflows on preview features. Check what the whole team can actually use.

Not knowing which integration you are running. The plugin and the AI Assistant route behave differently, and so do old and new plugin versions during the harness transition.

Not telling it what the IDE already told you. Inspection results, call counts and type information are things you can see and it cannot.

The harness transition, and why it matters

Worth understanding rather than treating as an implementation detail, because it changes what you should learn.

Historically the JetBrains plugin ran its own local agent harness — its own implementation of the plan-act-observe loop, its own permission handling, its own tool set. VS Code had a different one. The two behaved differently in ways that were nobody’s fault and hard to reason about.

The plugin transitioning to Copilot CLI as the default agent harness collapses that difference. The practical consequences:

What you learn about the CLI applies in the IDE. The permission model, custom agents, skills and the approval flow are the same machinery. The CLI cluster becomes relevant reading for JetBrains users rather than a separate topic.

Behaviour converges across surfaces. An agent doing the same task in the terminal and in the IDE increasingly does it the same way, which makes team practice easier to describe.

Version differences matter during the transition. A colleague on an older plugin may be running the old harness, which is one explanation for “it behaves differently for me”. Checking plugin versions is a reasonable first step when agent behaviour differs between people.

The general lesson for this pillar: the surfaces are converging on shared machinery. Investing in understanding the repository-level configuration — instructions, skills, agents, hooks — is durable in a way that investing in one editor’s particular implementation is not.

Mental model

JetBrains gives Copilot a strong IDE to work inside — deterministic refactoring, real type information, good navigation. The productive division is Copilot for what requires judgement, and the IDE for what it already does exactly.

What you learned

• JetBrains Copilot Chat has agent, ask and plan modes; the default is agent
• Plan mode makes the approach reviewable before any file changes
• Copilot Edits allows controlled multi-file changes from one prompt
• The plugin is transitioning to Copilot CLI as its agent harness
• Copilot is also available inside JetBrains AI Assistant via the Agent Client Protocol
• Repository and path-specific instructions are fully supported; several newer mechanisms are preview
• Mixed-editor teams should build shared configuration on instructions, which work everywhere
• Model and reasoning-depth selection are available from the chat panel
• Use the IDE’s own refactoring where it is deterministic; use Copilot where judgement is required

Exercise

Use a disposable project in a JetBrains IDE.

1. Ask the same question in Ask mode and in agent mode. Predict: does agent mode edit files you did not want changed?

2. Give a multi-step task in Plan mode. Read the plan. Predict: would you have caught a wrong approach before any edits?

3. Add .github/copilot-instructions.md with a specific convention and test whether it applies.

4. Add a path-specific instruction file for one directory. Predict: does it apply outside that directory?

5. Try a project-wide rename with the IDE’s refactoring, then ask Copilot to do the same on a fresh copy. Compare completeness and time.

6. Check which of prompt files, skills and custom agents are available in your version. Predict: does the answer match the VS Code documentation you may have read?

7. Delete the project.

Related lessons

Copilot in VS CodeThe other major IDE, and the fuller feature set.

Copilot agent modeThe agentic surface, across editors.

Custom instructionsThe layer that works everywhere.

GitHub Copilot CLIIncreasingly the harness underneath the plugin.