GitHub Copilot for IDEs: Complete Guide

GitHub Copilot for IDEs: Complete GuideCopilot IDE & Developer Workflow1Beginner → Intermediate/github-copilot/ide/

Almost everything written about GitHub Copilot assumes you are using VS Code. Most of it does not say so.

That is a problem, because Copilot is not one product with a consistent surface. It is a set of capabilities that reach each editor on a different schedule. Agent mode works in five editors. Edit mode works in two. Copilot code review works in four. Prompt files are fully supported in two, in preview in two, and absent from one. Follow a VS Code tutorial in Eclipse and roughly a third of it describes features you do not have.

This guide maps that unevenness precisely, using GitHub’s own published data, and then helps you decide what it means for the editor you actually work in.

Key takeaways

• Copilot’s feature set differs sharply by editor. VS Code is the only one where the whole thing is finished rather than partly in preview.
• The differences that bite are not the headline features — everyone has chat and agent mode — but context: workspace indexing, custom instruction scope, and how you reference files.
• Eclipse is considerably more capable than its reputation; Xcode is more capable than expected but has the narrowest context layer.
• Android Studio has no Copilot build of its own. It runs the JetBrains plugin, and inherits exactly the JetBrains feature set.
• Choosing an editor for Copilot alone is usually the wrong trade. Your language ecosystem matters more, and the gaps are mostly workable once you know where they are.

Why IDE choice matters here

For most tools, the editor is a preference. For Copilot it is a capability boundary, for a structural reason: Copilot is delivered as an extension, and an extension can only do what its host permits.

VS Code gives extensions deep access — the editor’s own APIs for inline suggestions, chat participants, terminal integration and workspace indexing were substantially shaped by Copilot’s requirements. Xcode’s extension model is far more restricted, which is why Copilot there cannot index a workspace the way it can elsewhere. JetBrains sits in between: a rich plugin API, but one Copilot has to adapt to rather than co-design.

So the practical question is not “does my editor support Copilot” — all the major ones do. It is which parts of the workflow you are about to read about actually exist in your editor.

How Copilot integrates with an IDE

Every integration does the same four jobs, and they fail in different ways:

1. Collect context. Open files, cursor position, project structure, and — where supported — a workspace index.
2. Send a request to GitHub’s service.
3. Render the response as ghost text, a chat message, or file edits.
4. Execute tools, in the agentic modes: running commands, reading files, calling MCP servers.

Steps 1 and 4 are where editors diverge. Step 1 determines how much Copilot knows; step 4 determines how much it can do. Steps 2 and 3 are broadly the same everywhere, which is why the feeling of using Copilot is similar in every editor and the results are not.

Why extensions, and why that constrains things

Copilot could have been built as a standalone application. It was not, and the reason explains most of what follows: an assistant that cannot see your open file, your cursor, your project structure and your terminal is guessing. All of that lives inside the editor, and the only way in is the editor’s extension API.

That makes Copilot’s capabilities a function of somebody else’s API surface:

• VS Code exposes inline completion, chat participants, terminal access, task running and workspace search to extensions. Copilot uses all of it.
• Visual Studio ships Copilot as a built-in component rather than a marketplace extension from 2022 17.10 onward, which is why it has deeper solution integration than a third-party plugin could achieve.
• JetBrains has a mature plugin API, but Copilot has to map onto JetBrains’ own model of projects, indices and inspections rather than the other way round.
• Eclipse and Xcode have the most constrained extension models, and their Copilot integrations are correspondingly narrower — though in different places, which is why Eclipse lacks code review while Xcode lacks indexing.

None of this is a criticism of the editors. It is the reason a feature can be “shipped” and still be absent from your editor for months, and why “when will X arrive in Y” rarely has a clean answer.

The four layers, per editor

Cluster 1 described Copilot as four layers of increasing autonomy. Here is how completely each editor implements them:

The conversational layer is the one place everybody is finished. It is also the layer that transfers best between editors, which is worth knowing if you work in more than one.

The full feature comparison

Every tracked Copilot feature, by IDE. Each cell states whether the feature is supported, in public preview, or not supported in that IDE.

Feature	VS Code	Visual Studio	JetBrains	Eclipse	Xcode
Code completionInline ghost-text suggestions as you type.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	Yes — Supported in Xcode
Next edit suggestionsPredicts where your next edit belongs, not just what comes after the cursor.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
ChatConversational interface with your code as context.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	Yes — Supported in Xcode
Agent modeCopilot plans, edits across files and runs tools with your approval.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	Yes — Supported in Xcode
Edit modeA middle gear: multi-file edits you scope yourself, without the agent loop.	Yes — Supported in VS Code	No — Not supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
CheckpointsRoll a session back to an earlier state.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	Yes — Supported in Xcode
Copilot code reviewAI review comments on a diff or selection, inside the editor.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	Yes — Supported in Xcode
Custom instructionsPersistent project conventions prepended to Copilot's context.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
Prompt filesReusable prompt templates checked into the repository.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	No — Not supported in Eclipse	Preview — Preview in Xcode
Agent skillsFolders of instructions teaching an agent to perform a specific task.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
Custom agentsNamed agent configurations with their own tools and instructions.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Yes — Supported in Eclipse	Preview — Preview in Xcode
MCPModel Context Protocol servers, connecting Copilot to external tools.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	Yes — Supported in Xcode
Workspace indexingBuilds a searchable index so Copilot can reason across the project.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	No — Not supported in Xcode
Code referencingFlags suggestions matching public code, with the matching references.	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	No — Not supported in Xcode
VisionAttach an image — a mockup, a screenshot of an error — to a prompt.	Preview — Preview in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Yes — Supported in Eclipse	Preview — Preview in Xcode
BYOKBring your own model key instead of using Copilot's hosted models.	Preview — Preview in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
.NET Upgrade AgentAutomates upgrading a .NET project to a newer target framework.	No — Not supported in VS Code	Yes — Supported in Visual Studio	No — Not supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
Java Upgrade AgentAutomates upgrading a Java project's version and dependencies.	Preview — Preview in VS Code	No — Not supported in Visual Studio	No — Not supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode

Yes SupportedPreview Public preview, subject to changeNo Not supported

Captured from the latest release of each integration at the time of verification: VS Code 1.108.0, Visual Studio 18.6.0, JetBrains 1.5.66 (extension), Eclipse 0.14.0 (extension), Xcode 0.46.0 (extension). GitHub publishes its feature matrix as a public preview and changes it often — check the current matrix before relying on any single row.

Read that table by exception. Six rows are identical everywhere and tell you nothing: code completion, chat, agent mode, MCP, code referencing and workspace indexing are broadly present. The interesting rows are the ones where the editors disagree.

Only the features where IDEs actually differ. Each cell states whether the feature is supported, in public preview, or not supported in that IDE.

Feature	VS Code	Visual Studio	JetBrains	Eclipse	Xcode
Next edit suggestions	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
Edit mode	Yes — Supported in VS Code	No — Not supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
Checkpoints	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	Yes — Supported in Xcode
Copilot code review	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	No — Not supported in Eclipse	Yes — Supported in Xcode
Custom instructions	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
Prompt files	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	No — Not supported in Eclipse	Preview — Preview in Xcode
Agent skills	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
Custom agents	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Yes — Supported in Eclipse	Preview — Preview in Xcode
Workspace indexing	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	No — Not supported in Xcode
Code referencing	Yes — Supported in VS Code	Yes — Supported in Visual Studio	Yes — Supported in JetBrains	Yes — Supported in Eclipse	No — Not supported in Xcode
Vision	Preview — Preview in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Yes — Supported in Eclipse	Preview — Preview in Xcode
BYOK	Preview — Preview in VS Code	Yes — Supported in Visual Studio	Preview — Preview in JetBrains	Preview — Preview in Eclipse	Preview — Preview in Xcode
.NET Upgrade Agent	No — Not supported in VS Code	Yes — Supported in Visual Studio	No — Not supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode
Java Upgrade Agent	Preview — Preview in VS Code	No — Not supported in Visual Studio	No — Not supported in JetBrains	No — Not supported in Eclipse	No — Not supported in Xcode

Yes SupportedPreview Public preview, subject to changeNo Not supported

Captured from the latest release of each integration at the time of verification: VS Code 1.108.0, Visual Studio 18.6.0, JetBrains 1.5.66 (extension), Eclipse 0.14.0 (extension), Xcode 0.46.0 (extension). GitHub publishes its feature matrix as a public preview and changes it often — check the current matrix before relying on any single row.

That second table is the real story of this cluster. Every Cluster 2 lesson is, in effect, an explanation of one column of it.

What the differences actually mean

Context: the difference that matters most

Workspace indexing builds a searchable representation of your project so Copilot can find relevant code you have not opened. VS Code, Visual Studio, JetBrains and Eclipse all support it. Xcode does not.

That single row changes how you work. In IntelliJ you can ask “where is authentication handled” and get a useful answer. In Xcode, Copilot can only reason about what is open, so the same question produces a confident guess based on partial information. The mitigation is not a better prompt — it is opening the relevant files yourself.

Code referencing flags suggestions that match public code. Supported in VS Code, Visual Studio, JetBrains and Eclipse; not in Xcode. If your organisation cares about provenance, that is a real consideration for Apple development.

Edit mode: the missing middle gear

Chat suggests, agent mode acts. Edit mode sits between them: multi-file edits you scope yourself, without handing over the whole loop.

It exists in VS Code and JetBrains only. In Visual Studio, Eclipse and Xcode, the jump from chat to agent mode is a cliff — you go from copying snippets to supervising an autonomous agent, with nothing in between.

Checkpoints: how safely you can experiment

Checkpoints roll a session back to an earlier state. Supported in VS Code, Visual Studio, JetBrains and Xcode. Not supported in Eclipse.

This determines how freely you can let an agent try something. With checkpoints, an exploratory instruction is cheap — if it goes wrong, rewind. Without them, in Eclipse, your safety net is Git, so commit before you start an agent task.

Copilot code review

Available in VS Code, Visual Studio, JetBrains and Xcode. Not in Eclipse.

Eclipse users are not locked out of Copilot review entirely — it still runs on GitHub.com against a pull request. But the fast in-editor pass, where you review your own change before anyone sees it, is not available.

Customisation: where preview status bites

This is the cluster of rows where JetBrains and Xcode lag:

Note the inversion: Eclipse fully supports custom agents while JetBrains has them in preview, even though JetBrains leads Eclipse on almost everything else. Feature rollout is not a single ordered queue, and assuming it is will mislead you.

Custom instructions do not mean the same thing everywhere

Even where custom instructions are supported, which files are read differs. This is genuinely surprising and it is documented:

Two things worth extracting. JetBrains is the only family where GitHub documents personal instruction support. And in Eclipse, chat reads only the repository-wide file — path-specific instructions under .github/instructions/ apply to agent mode but not to chat, so a convention you scoped to one directory will be honoured by the agent and ignored in conversation.

Slash commands are not portable

Every editor has slash commands. Almost none of them are the same:

Only /explain, /fix and /tests are common to all four. GitHub’s chat cheat sheet documents no Eclipse-specific slash commands at all, which is why Eclipse has no column here — type / in your own chat box rather than trusting any published list.

Keyboard behaviour, and the Xcode trap

The rest, briefly:

• Cycling suggestions is Alt/Option with [ and ] everywhere — except Visual Studio, which uses Alt+, and Alt+.
• Eclipse is the only editor with a documented accept-next-word binding: Ctrl+→ (Command+→ on macOS).
• Toggling Copilot on and off has no default binding anywhere. Assign one.
• Vim and Neovim ship no default mappings at all; you bind everything yourself.

The keyboard shortcuts cheat sheet in Cluster 1 has every documented binding.

Model availability

Which models you can select is a plan feature, not an editor feature. Copilot Free and Copilot Student reach models only through auto model selection; Pro gets a selection; Pro+, Max, Business and Enterprise reach premium models. That is identical in every IDE, and the plans comparison covers it.

What is an editor feature is BYOK — bringing your own model key instead of using Copilot’s hosted models. It is fully supported in Visual Studio, and in preview in VS Code, JetBrains, Eclipse and Xcode. For an organisation that must host models under its own contract, that is a genuine reason to prefer Visual Studio today.

Where the gaps actually cost you

Feature tables invite a scoring mentality — count the ticks, pick the winner. That is the wrong way to read this one, because the rows are not equally important and their cost depends on how you work.

A missing feature you never use costs nothing. Agent skills are absent from Eclipse and Xcode. If you have never written one, that row is noise. Most developers have never written one.

A missing context feature costs you constantly. Xcode’s lack of workspace indexing is a small row and a large daily difference, because it affects every question you ask about code you do not currently have open. This is the row to weigh heaviest.

A missing safety feature changes your habits, not your capability. Eclipse has no checkpoints. You can still do everything — you just commit before letting an agent run, instead of relying on rewind. That is a workflow adjustment, not a limitation.

A preview feature is usable but not dependable. Custom instructions are in preview across JetBrains, Eclipse and Xcode. They work. What you should not do is build a team standard that assumes they behave identically to VS Code’s, because preview means the behaviour can change.

Ranked by how much they actually affect day-to-day work, in our view:

1. Workspace indexing — determines whether Copilot can find anything you have not opened.
2. Custom instruction scope — determines whether your conventions are applied consistently.
3. Agent mode and MCP — determine the ceiling on what you can delegate.
4. Checkpoints — determine how freely you can experiment.
5. Edit mode — a convenience with a workable substitute.
6. Prompt files, agent skills, custom agents — high value once you invest in them, irrelevant until you do.

Custom instructions: the difference nobody checks

Every editor here reads .github/copilot-instructions.md, which makes it easy to assume instructions behave identically everywhere. They do not, and the failure mode is silence — an instruction that is not read produces no error, just output that ignores a rule you believed was in force.

Three differences are worth committing to memory.

Personal instructions exist in one family only. JetBrains is the only IDE where GitHub documents support for instructions attached to your account rather than to a repository. If you have written personal preferences and moved to another editor, they stopped applying and nothing told you.

Eclipse chat reads only the repository-wide file. Path-specific instructions — different guidance for src/api than for src/ui — apply to Eclipse agent mode and are invisible to Eclipse chat. A team that has split guidance across several path-specific files has, without realising it, given Eclipse chat nothing.

Agent files are not universal. AGENTS.md, CLAUDE.md and GEMINI.md are read by VS Code, JetBrains and Xcode in agent mode. Visual Studio does not list them, and Eclipse does not read them at all. Anything essential belongs in the repository-wide instructions file, which every editor here reads.

The practical rule for a mixed-editor team is to treat .github/copilot-instructions.md as the only file guaranteed to reach everyone, and to use the others as enhancements rather than as the place a rule lives.

There is a second-order point about how to write them. Because support varies and several implementations are in preview, instructions should describe things you could verify from the output. “Tests are JUnit 5, never JUnit 4” is checkable at a glance. “Write clean, idiomatic code” is unfalsifiable, consumes context, and gives you no way to notice that it was ignored.

Team considerations

Everything above is written for an individual. Teams have two extra problems.

Mixed-editor teams get inconsistent Copilot behaviour. A convention enforced by path-specific instructions applies in VS Code chat and JetBrains chat, but not in Eclipse chat. If half your team is in Eclipse, that is a real divergence, and the fix is to put anything essential in the repository-wide .github/copilot-instructions.md file, which every editor reads.

Review expectations should not assume in-editor review. Copilot code review is unavailable in Eclipse. If your process says “run Copilot review before opening a PR”, Eclipse users cannot comply in the editor — they need the GitHub.com path instead. Better to write the process around the pull request, where it works for everyone.

Security and privacy considerations

The plan-level controls — content exclusion, organisation policy, audit logs — are the same regardless of editor, and are covered in Cluster 1. Three editor-specific points are worth making here.

Version compatibility

GitHub recommends running the latest stable IDE and Copilot extension, and the feature matrix is captured against the latest release of each. That advice is less generic than it sounds: several rows in the table above changed status within recent extension releases, so an editor a few versions behind genuinely has a different feature set.

The matrix was verified against these versions:

Android Studio

Android Studio deserves its own note, because the obvious assumption is wrong in a specific way.

There is no Android Studio build of Copilot. Support comes through the JetBrains plugin — Android Studio is built on the IntelliJ Platform, GitHub lists it among JetBrains-compatible IDEs, and the JetBrains Marketplace lists it in the plugin’s own compatible-products set.

The practical consequences:

• Feature support is exactly the JetBrains column of the table above, including everything still in preview there.
• Installation is the JetBrains plugin flow, done from inside Android Studio.
• GitHub does not track Android Studio as a separate column in its matrix, so there is no Android-Studio-specific support statement to cite.
• Android Studio ships Gemini as its first-party assistant. Copilot runs alongside it, which means two different products can both offer something called “Agent Mode” in the same window.

GitHub Copilot with Android Studio covers this properly, including the version-compatibility question.

Neovim

Worth stating plainly because it is often glossed over: Neovim supports code completion only. No chat, no agent mode, no MCP, no custom instructions, and no default key mappings.

That is a legitimate way to use Copilot, and it is also not the product most Copilot writing describes. If you are evaluating Copilot’s agentic capabilities from Neovim, you are evaluating an autocomplete.

Each editor in one paragraph

Before the recommendations, the shortest honest summary of each.

VS Code is the reference implementation and the only editor where the whole product is finished. Every feature is supported rather than in preview, chat participants and chat variables exist nowhere else, and edit mode gives you a gear between conversation and full autonomy. If a Copilot tutorial does not say which editor it assumes, it assumes this one.

Visual Studio is the .NET environment and is closer to VS Code on features than most people expect — it actually leads on two, with full BYOK and vision support where VS Code has both in preview. It is the only editor with the .NET Upgrade Agent. It has no edit mode, and its context syntax is solution- and file-based rather than the #file variables VS Code uses.

JetBrains gives you one plugin across the whole family and full support for the things you use hourly — completion, chat, agent mode, edit mode, checkpoints, MCP, code review. What lags is the customisation layer, where custom instructions, prompt files, custom agents and agent skills are all still in preview. It is also the only family documented as supporting personal custom instructions.

Eclipse is the biggest surprise in the table. Agent mode, MCP, workspace indexing, code referencing and vision are all supported, and custom agents are fully supported where JetBrains has them in preview. The real gaps are Copilot code review, checkpoints, edit mode, prompt files and agent skills — and the fact that chat reads only the repository-wide instructions file.

Xcode supports more than its reputation suggests: agent mode, checkpoints, code review and MCP all work. Its limitation is context rather than capability — no workspace indexing and no code referencing — plus a Tab key that behaves differently from every other editor.

Android Studio is the JetBrains column with a different name on the window.

Working across more than one editor

Plenty of developers use two: VS Code for web and tooling, IntelliJ or Xcode for the main application. Three things make that easier.

Your repository-level configuration is portable. A .github/copilot-instructions.md file is read by every editor that supports custom instructions at all, so conventions you write once apply everywhere. That is the highest-value thing you can set up if you switch editors regularly.

Your muscle memory is mostly portable, with two exceptions. Tab and Esc are universal. Cycling is Alt/Option plus a bracket everywhere except Visual Studio. Xcode’s first-line-only Tab is the one that will genuinely catch you.

Your prompt habits transfer completely. Nothing about specifying a contract, stating constraints or reviewing a diff is editor-specific. That is worth remembering when a feature you rely on turns out to be missing: the discipline from Best Practices is what carries across, not the feature list.

What is the same everywhere

The differences are the interesting part, so it is worth being explicit about how much is not different. Five things hold in every editor on this page.

Code completion works the same way. Grey text appears as you type; Tab accepts it, Esc dismisses it. The only real variation is Xcode, where Tab accepts the first line and Option+Tab accepts the whole suggestion.

The context principle is universal. What you have open shapes what you get. Editors with workspace indexing soften this; none removes it. Explicitly provided context outweighs indexed context everywhere.

Contracts beat prompts. A precise signature, type or interface constrains a suggestion more effectively than a paragraph of English, in every language and every editor. This is the single most transferable habit in the cluster.

Approval is the boundary in agent mode. Wherever agent mode exists, the prompt asking whether to run a command is the security control. Instructions in a prompt are guidance; the approval is enforcement.

Review does not transfer to the tool. Reading what you accepted, running the code, and reviewing your own diff are your steps in every editor. Nothing on the support matrix changes that.

If you learn Copilot properly in one editor, most of what you know moves with you. What does not move is a short, specific list — which is exactly what the rest of this cluster documents.

Common misconceptions

“Copilot is the same everywhere.” The most consequential one, and the reason this page exists.

“JetBrains support is second-class.” Not for daily work — completion, chat, agent mode, edit mode and checkpoints are all fully supported. It is the customisation layer that lags.

“Eclipse only does autocomplete.” Outdated by a wide margin. Eclipse supports agent mode, MCP and custom agents today.

“Xcode barely supports Copilot.” Also outdated. Agent mode, checkpoints and code review all work; the real constraint is that it cannot index your workspace.

“Android Studio has its own Copilot integration.” It does not. It runs the JetBrains plugin.

“Preview means broken.” Preview means subject to change and not covered by the same guarantees. Several preview features are perfectly usable — just do not build a team process on one without a fallback.

Choosing an IDE

These are recommendations, not measurements. The tables above are the verified part; what follows is judgement, with the reasoning shown so you can disagree with it.

The honest summary

For most developers, do not switch editors for Copilot. Your language ecosystem, your team’s tooling and your own fluency matter more than a handful of preview flags. The gaps in JetBrains, Eclipse and Xcode are all workable once you know they exist — which is the entire point of this cluster.

The exception is if agentic development is genuinely your priority. Then the distance between VS Code and everything else is real and currently large.

How to use the rest of this cluster

Three reasonable reading paths, depending on why you are here.

You work in one editor and want to get better at it. Read your editor’s lesson, then the capstone. The IDE lessons assume Cluster 1’s concepts and spend their words on what is different rather than re-explaining agent mode. Lesson 25 then puts everything into one continuous workflow.

You are choosing an editor. You have already read the part that matters — the comparison tables above. Skim the one-paragraph summaries for the two or three editors on your shortlist, and only go deeper on the ones that survive.

You maintain tooling or standards for a team. Read this page, the team considerations above, and then the lessons for whichever editors your team actually uses. The custom-instruction differences are the ones that will generate support questions.

Every IDE lesson follows the same shape, so they are comparable: what Copilot supports there, how to install it, what is genuinely different about that editor, a worked example in that editor’s primary language, the known gaps, and troubleshooting. That structure is deliberate — the point of a cluster organised by editor is that you can hold two of them side by side.

What this cluster covers

Twelve lessons, organised by editor rather than by feature:

If you have not done Cluster 1, start with GitHub Copilot: The Complete Guide — this cluster assumes you know what agent mode is and are asking where it works.

Frequently asked questions

Which IDE has the best GitHub Copilot support? VS Code, by a clear margin — it is the only editor where every tracked feature is supported rather than partly in preview, and it receives new features first.

Does Copilot work the same in every IDE? No. Chat and agent mode exist nearly everywhere, but edit mode, checkpoints, code review, prompt files, agent skills, custom agents and workspace indexing all vary, and the slash commands and key bindings differ too.

Is Copilot in JetBrains as good as in VS Code? For completion and chat, effectively yes. For customisation it lags — custom instructions, prompt files, custom agents and agent skills are all in preview there while fully supported in VS Code.

Can I use Copilot in Android Studio? Yes, through the JetBrains plugin. There is no separate Android Studio build, and the feature set is the JetBrains one.

Does Copilot work in Eclipse? Yes, and better than most people expect: agent mode, MCP, custom agents and vision are all supported. Copilot code review, checkpoints, prompt files, edit mode and agent skills are not.

Should I switch IDEs to get better Copilot support? Usually not. Language ecosystem and personal fluency outweigh feature flags. The exception is if agentic workflows are your main interest, where VS Code’s lead is currently substantial.

Why is a feature “supported” in one editor and “preview” in another? Because each integration is a separate piece of software with its own release cycle, built against a different extension API. Preview means GitHub considers the behaviour subject to change rather than broken — most preview features work fine, they simply are not yet a stable contract you should build a team process around.

Does my Copilot plan change what my editor can do? Not for the feature rows on this page, which are editor capabilities. Your plan determines model access, included AI credits, and whether you get the cloud agent and third-party agents. The two axes are independent, and the plans comparison covers the second one.

Next steps

Go straight to your editor’s lesson from the table above, or start with GitHub Copilot with Visual Studio Code — even if you work elsewhere, it is the clearest picture of what Copilot looks like when everything is switched on.