2.1.1. Enabling Copilot Across Editors

💡 First Principle: Enabling Copilot is the same act everywhere — install the extension, then sign in with GitHub — because the GitHub identity, not the editor, is what grants access. The editor only hosts the experience.

Copilot ships as an extension (or built-in integration) for Visual Studio Code, Visual Studio, the JetBrains IDE family, Eclipse, Xcode, and Vim/Neovim, among others. The flow is consistent: add the Copilot extension from the editor's marketplace, then authorize it against your GitHub account. Once signed in, your plan determines which capabilities light up — inline suggestions are available broadly, while Chat and agentic modes depend on the editor and plan.

A common workplace scenario: a developer joins a team that has Copilot Business. They install the extension and sign in, but a teammate sees features they don't. The difference is usually organization policy (covered in 2.4) — the org admin controls which features are available, so two developers on the same plan can have different feature sets depending on enforced policy.

📝 Currency note: Feature parity across editors has moved quickly. The exam tests the concept — sign-in via GitHub identity, plan- and policy-gated features — rather than a per-editor feature grid that changes month to month.

⚠️ Exam Trap: Don't assume "supported editor" means "all features available." Inline completion is the broadly available baseline; Chat and agentic modes vary by editor and are further gated by organization policy.

Reflection Question: Two developers on the same Copilot Business plan, both signed in to VS Code, see different available features. What is the most likely cause, and where would you look to confirm it?