GitHub Copilot with Eclipse

GitHub Copilot with EclipseCopilot IDE & Developer Workflow10Beginner → Intermediate/github-copilot/ide/eclipse/

Eclipse has a reputation as the editor where Copilot barely works. That is not what the feature matrix says. Agent mode, MCP, workspace indexing, code referencing and vision are all fully supported, and custom agents are supported here while they are still in preview in JetBrains — an inversion nobody expects.

What Eclipse genuinely lacks is the layer around the work: edit mode, checkpoints, and Copilot code review. That absence shapes how you should use it, and this lesson is mostly about that.

Copilot support

Eclipse

Verified August 20, 2026

Better supported than its reputation suggests — agent mode, MCP and custom agents all work — but the review and checkpoint layer is missing.

Installed via

Install the GitHub Copilot extension for Eclipse, then authenticate

Extension version tracked

0.14.0

Feature coverage

8 supported · 3 preview · 7 not supported

• Code completionSupported
• ChatSupported
• Agent modeSupported
• Custom instructionsPreview
• MCPSupported
• Copilot code reviewNot supported

Key takeaways

• Agent mode is supported. So are MCP, workspace indexing, code referencing and vision.
• Custom agents are fully supported — ahead of JetBrains, where they remain in preview.
• Missing: edit mode, checkpoints, Copilot code review, prompt files and agent skills.
• With no checkpoints, git is your undo. Commit before an agent session, not after.
• Chat reads only the repository-wide instructions file. Path-specific instructions apply to agent mode, not chat.
• Eclipse is the only IDE where GitHub documents an accept-next-word binding for inline suggestions.

Installation

What works

Worth stating plainly, because the reputation runs ahead of the facts:

That is a working environment. Agent mode with MCP and custom agents is a substantial capability, and two of those are ahead of JetBrains.

What is missing, and what it costs

No edit mode

VS Code and JetBrains have three modes: chat suggests, edit mode changes files you nominate, agent mode decides for itself. Eclipse has the first and the third.

That removes the middle setting — the one where you want files changed but do not want a command run or a file created you did not ask for. In Eclipse you either copy from chat yourself or hand over to an agent.

The workable approach is to constrain agent mode into behaving like edit mode:

Change only the two files I have named. Do not create files, do not run any commands, and do not modify tests. Show me the complete change to each file. If the change requires touching something else, stop and tell me instead of doing it.

No checkpoints

This is the most consequential absence. In VS Code and JetBrains, an agent session that goes wrong can be rolled back to a checkpoint. Eclipse has no such thing, so an agent session that makes a mess leaves the mess.

The discipline that replaces it is ordinary version control, applied more deliberately than usual:

• Commit before every agent session. A clean working tree before you start means git checkout . is a complete undo.
• Work on a branch. Discarding a branch is easier than unpicking commits.
• Keep sessions short. One task, review, commit. Long sessions accumulate changes you did not follow.
• Use Eclipse’s local history. It keeps prior versions of files independently of git, and it will save you when you were not on a clean tree.

No Copilot code review

Review moves to GitHub. Push the branch, open the pull request, and request Copilot review there. You lose the in-editor loop where issues surface before committing; you keep the review itself.

For a pre-push check, chat can do part of the job — with the limits stated honestly. It has no view of the diff, so you are asking about a file rather than about a change:

Review this class for correctness problems: unhandled null cases, resources not closed, exceptions swallowed, and concurrency assumptions that are not stated. Ignore style. You are looking at the whole file, not my changes — say if something you flag looks pre-existing.

Custom agents: the surprise

Custom agents — configurations that define a persona, its tools and its boundaries — are fully supported in Eclipse while remaining in public preview across the entire JetBrains family. If your team has invested in custom agents, Eclipse is a first-class place to use them.

Combined with MCP, that gives Eclipse a genuinely capable agent story: an agent with a defined role, connected to external tools, working over an indexed workspace. The features Eclipse lacks are the convenience layer, not the engine.

Custom instructions: read the scope carefully

Eclipse’s instruction support has a specific shape that catches people out.

Chat reads only the repository-wide file. Path-specific instructions — different guidance for different directories — apply to agent mode and are invisible to chat.

The practical consequence: if your project splits guidance across several path-specific files, Eclipse chat sees none of it. Anything that must reach chat belongs in the repository-wide .github/copilot-instructions.md.

Keyboard behaviour

Slash commands

GitHub’s chat cheat sheet documents no Eclipse-specific slash commands. That does not necessarily mean your build has none — type / in the chat box and see what it offers.

Practically, this pushes you towards writing full prompts rather than relying on shorthand, which is not a bad habit. A well-specified request outperforms /tests in any editor; Eclipse just removes the shortcut.

Write JUnit 5 tests for this class, matching the assertion style and fixtures in the test class I have open. Cover the boundary conditions and the failure paths. Every assertion must check a value that would differ if the code were wrong.

Java work in Eclipse

Eclipse remains a serious Java IDE, and most of what makes Copilot effective in Java applies here unchanged.

Declarations constrain the model. A fully specified method signature — return type, parameter types, throws clause — narrows completion far more than a comment describing the same thing. Write the contract, let completion fill the body.

Keep the build file open. pom.xml or build.gradle states which libraries exist and at which versions. Without it, suggestions reach for whatever is most common in training data, which is how a project on one HTTP client ends up with code for another.

Eclipse’s Problems view is your immediate review pass. Unresolved references, type errors and warnings appear as soon as a suggestion lands. Invented method names — the most common failure mode — are caught before you build.

Using only libraries already declared in the pom.xml I have open, implement this retry logic. If nothing suitable is present, say so and name what I would need to add rather than importing something that is not there.

Enterprise Java brings one extra consideration. A great deal of behaviour lives in configuration — application servers, deployment descriptors, framework annotations — and none of it is visible in the file you are looking at. When asking about runtime behaviour rather than syntax, open the configuration too, or you will get an answer about the code rather than about what actually happens.

Legacy codebases

Eclipse is disproportionately used on long-lived enterprise codebases, and that context changes what Copilot is good for.

The most valuable use is comprehension rather than generation. Code nobody has touched in years, written by people who have left, with conventions that were current a decade ago — explaining it is genuinely useful work and carries no risk, because nothing is being changed.

Explain what this class does, in terms of the business behaviour rather than the mechanics. Identify anything that looks like a workaround for a constraint that may no longer exist, and anything whose behaviour depends on the order in which methods are called. Do not propose changes.

The second use is risk assessment before a change: asking what could break, what depends on this, what assumptions the code is making. Both are questions where being told something plausible is still useful, because you verify it against the code afterwards.

Where to be careful: generation in old codebases inherits the surrounding style, and the surrounding style may be a decade out of date. A suggestion that matches its neighbours is not automatically what you want — it is simply consistent.

A working pattern for Eclipse

Given what is present and what is not, this sequence holds up:

Commit first. Clean tree before anything agentic. This is the checkpoint substitute and it is not optional.

Use chat for understanding. Explaining unfamiliar code, generating hypotheses, discussing an approach — none of which touches files, so none of which needs recovery.

Use completion for the writing. With the contract-first habit: signature, types and Javadoc first, body second.

Use agent mode for scoped, bounded work, with an explicit prompt about what it may not touch, and read every approval.

Review with Eclipse’s own tooling. Problems view, compiler warnings, the diff against HEAD. All of it works and none of it depends on Copilot.

Push and review on GitHub. Where Copilot code review is available.

The shape is the same as in any editor. What changes is that the safety net is git rather than checkpoints, and the review happens in the pull request rather than in the editor.

Choosing Eclipse deliberately

A short, honest framing, since the question sits behind most searches that land here.

Nobody should switch to Eclipse for Copilot. VS Code and JetBrains have the fuller feature set, and if the choice is genuinely open, that is where the tool is most complete.

But plenty of people do not have an open choice. Eclipse is the standard in a great many enterprise Java environments, it is what the toolchain assumes, and the plugins a team depends on may exist nowhere else. For those developers the useful question is not which IDE is best but whether Copilot is worth using in the one they have — and the answer is clearly yes. Completion, chat, agent mode, MCP and custom agents cover the substance of daily work.

Security

Troubleshooting

MCP in Eclipse

Worth a short section because it is supported here and is easy to overlook given what Eclipse lacks elsewhere.

MCP lets Copilot reach tools outside the editor — issue trackers, documentation systems, databases, internal services — through a server that exposes them. In Eclipse that combines with fully supported custom agents to give a capable setup: an agent with a defined role, connected to the systems your team actually uses, working over an indexed workspace.

The security consideration is the one that matters. An agent connected through MCP can act on whatever the server exposes, and the permissions belong to the server rather than to Copilot. Review what a server can do before connecting it, and remember that Eclipse has no checkpoints — an MCP-driven action outside your files is not something any rollback covers.

Frequently asked questions

Does Copilot really work in Eclipse? Yes — better than its reputation suggests. Completion, chat, agent mode, MCP, custom agents, indexing, code referencing and vision are all supported.

Is agent mode available? Yes, fully. Edit mode is what is missing.

How do I undo an agent session? With git. Commit before you start, then git checkout . if it goes wrong. Eclipse’s local history is the backup if you were not on a clean tree.

Why are my custom instructions being ignored? Most likely they are path-specific, and Eclipse chat reads only the repository-wide file. Agent mode does read path-specific instructions.

Are there slash commands? GitHub documents none for Eclipse. Type / in the chat box to see what your build offers, and otherwise write full prompts.

Can I use custom agents? Yes, and they are fully supported here while still in preview in JetBrains.

Where do I get Copilot code review? On GitHub, in the pull request. It is not available in the Eclipse editor.

Next steps

Xcode covers the other IDE with a distinctly narrower feature set, for entirely different reasons.

To compare Eclipse against the alternatives feature by feature, see the matrix in GitHub Copilot for IDEs. For agent-mode technique — most of which transfers, since Eclipse supports agent mode — see Agent Mode in VS Code.